









 
 




 
 


I'm wondering about the documentation for rand(...).
It has stated for a long time that the values that rand produces are "between
0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
actually hits those exact values. (Some of my code would actually have a problem
if that happened; but I've never encountered such a problem... which is why I
now ignore the 'inclusivity.')
On a whim, I ran some tests (with different seed(...) values) 10,000,000 tries
each time. But I haven't yet seen a 1.0 or a 0.0 occur.
#declare S = seed(17);
#for(i,1,10000000)
#declare R = rand(S);
#if(R = 0.0  R = 1.0)
#debug concat("\n","rand = ",str(R,1,6),"\n")
#else
#end
#end
Unless there *is* a oneinagazillion chance of it happening (uh, like the
decay of a proton, for example), I think the docs should say, "between 0.0 and
1.0, exclusive."
(BTW, I tried to find the rand() entry in the online wiki, just to see if the
info there has changed since the latest(?) POVincluded documentation, but I
didn't know where to look.)
Post a reply to this message


 
 




 
 


Le 180717 Ã 06:27, Kenneth a Ã©critÂ :
> I'm wondering about the documentation for rand(...).
>
> It has stated for a long time that the values that rand produces are "between
> 0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
> actually hits those exact values. (Some of my code would actually have a problem
> if that happened; but I've never encountered such a problem... which is why I
> now ignore the 'inclusivity.')
>
> On a whim, I ran some tests (with different seed(...) values) 10,000,000 tries
> each time. But I haven't yet seen a 1.0 or a 0.0 occur.
>
> #declare S = seed(17);
> #for(i,1,10000000)
> #declare R = rand(S);
> #if(R = 0.0  R = 1.0)
> #debug concat("\n","rand = ",str(R,1,6),"\n")
> #else
> #end
> #end
>
> Unless there *is* a oneinagazillion chance of it happening (uh, like the
> decay of a proton, for example), I think the docs should say, "between 0.0 and
> 1.0, exclusive."
>
> (BTW, I tried to find the rand() entry in the online wiki, just to see if the
> info there has changed since the latest(?) POVincluded documentation, but I
> didn't know where to look.)
>
>
All values are equally possible, including 0 and 1. The mantissa for a
float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
a 0 and the same of getting a 1. Very small but not zero chance.
Post a reply to this message


 
 




 
 


Alain <kua### [at] videotronca> wrote:
> Le 180717 Ã 06:27, Kenneth a Ã©critÂ :
> > I'm wondering about the documentation for rand(...).
> All values are equally possible, including 0 and 1. The mantissa for a
> float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
> a 0 and the same of getting a 1. Very small but not zero chance.
So then maybe round to the nearest Q decimal place to "compress" the range and
increase the likelihood of getting a 1 or a 0.
See this post in an old thread:
http://news.povray.org/povray.newusers/message/%3C51fb4924%241%40news.povray.org%3E/#%3C51fb4924%241%40news.povray.org%
3E
Post a reply to this message


 
 




 
 


Am 17.07.2018 um 12:27 schrieb Kenneth:
> I'm wondering about the documentation for rand(...).
>
> It has stated for a long time that the values that rand produces are "between
> 0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
> actually hits those exact values. (Some of my code would actually have a problem
> if that happened; but I've never encountered such a problem... which is why I
> now ignore the 'inclusivity.')
>
> On a whim, I ran some tests (with different seed(...) values) 10,000,000 tries
> each time. But I haven't yet seen a 1.0 or a 0.0 occur.
Theoretically and without too detailed analysis(*), the random number
generator should be able to generate 2^32 (approx. 4 [short] billion)
different results, including both 0.0 and 1.0. So unless you did your
experiment with 200 different seeds, you're still far from the threshold
where you could expect /any/ particular result value crop up for sure.
(*The floatingpoint random number generator is based on an integer
Linear Congruential Generator; there is some chance the configuration
parameters of that LCG cause it to disfavour result values 0.0 and/or
1.0. However, without detailed analysis, the same could be said for any
other of the 2^32 possible result values.)
Post a reply to this message


 
 




 
 


"Bald Eagle" <cre### [at] netscapenet> wrote:
> Alain <kua### [at] videotronca> wrote:
>
> > All values are equally possible, including 0 and 1. The mantissa for a
> > float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
> > a 0 and the same of getting a 1. Very small but not zero chance.
>
> So then maybe round to the nearest Q decimal place to "compress" the range and
> increase the likelihood of getting a 1 or a 0.
>
Compressing the range is an interesting concept, that I wasn't aware of. I'll
give some thought to the formula presented there. But I would suspect that
POVRay's internal rounding would be *either* 'round up' OR 'round down', but
not both (?) In other words, a 1.0 (but never a 0.0), OR a 0.0 (but never a
1.0).
Post a reply to this message


 
 




 
 


clipka <ano### [at] anonymousorg> wrote:
> Am 17.07.2018 um 12:27 schrieb Kenneth:
> > I'm wondering about the documentation for rand(...).
> >
> > It has stated for a long time that the values that rand produces are "between
> > 0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
> > actually hits those exact values. (Some of my code would actually have a problem
> > if that happened; but I've never encountered such a problem... which is why I
> > now ignore the 'inclusivity.')
> >
> > On a whim, I ran some tests (with different seed(...) values) 10,000,000 tries
> > each time. But I haven't yet seen a 1.0 or a 0.0 occur.
>
> Theoretically and without too detailed analysis(*), the random number
> generator should be able to generate 2^32 (approx. 4 [short] billion)
> different results, including both 0.0 and 1.0. So unless you did your
> experiment with 200 different seeds, you're still far from the threshold
> where you could expect /any/ particular result value crop up for sure.
>
> (*The floatingpoint random number generator is based on an integer
> Linear Congruential Generator; there is some chance the configuration
> parameters of that LCG cause it to disfavour result values 0.0 and/or
> 1.0. However, without detailed analysis, the same could be said for any
> other of the 2^32 possible result values.)
I always thought the interval of the numbers geanrated with the rand function of
povray was between 0 (included) and 1 (excluded). That scheme would be more
relevant. Imagine you want a random integer between 0 and 4 to easily take
something in an array with an index made randomly (to avoid a switch for
example).
//Code
#declare CollectionOfThings = array[5]
#declare RandomGen = seed(789456);
#declare Thing = CollectionOfThings[int(5 * rand(RandomGen) ];
Here the index will be strictly between 0 and 5 (excluded), with a random number
between 0.0 and 0.2 (excluded) , you get an index of 0 , with a random number
between 0.2 and 0.4 (excluded) you get an index of 1 for the array, etc..
//
For a random System that generate number between 0 and 1 , both included , the
above code has a bug. From 0.8 to 1.0 (excluded) you get an index of 4 and
there's still a chance of getting an index of 5 (almost null I admit it) and a
segfault. So you might think replacing the problematic code with:
#declare Thing = CollectionOfThings[int(4 * rand(RandomGen) )]
But here you have almost no chance of getting an index of 4. ;)
Post a reply to this message


 
 




 
 


clipka <ano### [at] anonymousorg> wrote:
>
> Theoretically and without too detailed analysis(*), the random number
> generator should be able to generate 2^32 (approx. 4 [short] billion)
> different results, including both 0.0 and 1.0. So unless you did your
> experiment with 200 different seeds, you're still far from the threshold
> where you could expect /any/ particular result value crop up for sure.
>
I do see your point (and Alain's): Let's say I write some code where I naively
*expect* a rand() value of 0.0 or 1.0 to pop up every now and then (well, with a
1in4billion chance, assuming *equal* probability.) But those are distinct,
specific values it would be like expecting the exact value of .4729418830...
to pop up now and again. Which is highly unlikely (but still possible.)
But there's a practical aspect to consider, when writing a typical scene using
rand() if my own experience is any indication:
Let's say I want to make 10,000,000 stars in the sky. My own current way of
doing this (simplified) would be...
union{
#for(i,1,10000000)
sphere{0,1 scale 100*rand(R)
translate ...
}
#end
texture{...}
}
.... and I would ignore the *remote* possibility of rand() being 0.0, and thus
scale being <0.0,0.0,0.0>, which would trigger an error. Yet this *seems* to be
the behavior of rand(), in a practical sense, so I always feel safe in ignoring
that possibility.
But to be extrasafe, the code *should* be something like this...
....
sphere{0,1 scale 100*(rand(R) + "some tiny positive value")
....
.... even though rand() 'never' hits exactly 0.0, in my experience.
Post a reply to this message


 
 




 
 


On 07/17/2018 06:27 AM, Kenneth wrote:
> (BTW, I tried to find the rand() entry in the online wiki, just to see if the
> info there has changed since the latest(?) POVincluded documentation, but I
> didn't know where to look.)
most of the time i look here first:
http://wiki.povray.org/content/Reference:Keywords
Post a reply to this message


 
 




 
 


Am 17.07.2018 um 22:11 schrieb Kenneth:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> Alain <kua### [at] videotronca> wrote:
>>
>>> All values are equally possible, including 0 and 1. The mantissa for a
>>> float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
>>> a 0 and the same of getting a 1. Very small but not zero chance.
>>
>> So then maybe round to the nearest Q decimal place to "compress" the range and
>> increase the likelihood of getting a 1 or a 0.
>>
>
> Compressing the range is an interesting concept, that I wasn't aware of. I'll
> give some thought to the formula presented there. But I would suspect that
> POVRay's internal rounding would be *either* 'round up' OR 'round down', but
> not both (?) In other words, a 1.0 (but never a 0.0), OR a 0.0 (but never a
> 1.0).
While that's indeed the way most floatingpoint random number generators
work  usually giving you a number ranging from 0.0 inclusive to 1.0
exclusive  POVRay's SDL random number generator is designed to be
inclusive both fenceposts.
Post a reply to this message


 
 




 
 


Jim Holsenback <ash### [at] nospamcom> wrote:
> On 07/17/2018 06:27 AM, Kenneth wrote:
> > (BTW, I tried to find the rand() entry in the online wiki, just to see if the
> > info there has changed since the latest(?) POVincluded documentation, but I
> > didn't know where to look.)
>
> most of the time i look here first:
> http://wiki.povray.org/content/Reference:Keywords
Well, that's strange (and it does indeed have info on "rand"). But I originally
looked at a different "keywords" page...
http://wiki.povray.org/content/Reference:Keywords
Clicking on "rand" there brings up no actual information, just the word itself.
:(
The wiki page that I usually look at first, as a general starting place, is...
http://wiki.povray.org/content/Documentation:Contents
... and I see now that it does indeed have the correct link to "identifiers and
keywords" but that link is located in the first paragraph of the page, which I
didn't originally notice :O I think a better place for that link would be in
the lefthand column of the page (with the other entries there), rather than in
the body of the page. And perhaps there's some confusing redundancy of 'keyword'
pages in the wiki?
Post a reply to this message


 
 




 

