In article <3e4ac5d2@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   What I claimed was that eventually one of the streams will start giving
> the same numbers as the other streams gave to start with. And also the
> other way around.

Ok, I understand. Yes, that will happen.


>   This means that if you use two streams to position objects, it may
> happen that after a certain time one type of objects begins to appear
> in the exact same places as the other type of objects started to
> appear at the beginning.

Right. But that won't happen for any number of objects you are likely to 
hit.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Warp wrote:
> 
> John VanSickle <evi### [at] hotmailcom> wrote:
> > #while(sA!=sB)
> 
>   Are you completely sure that the same number will not appear twice
> in the stream without looping back to the beginning?

#local rsA=seed(0);
#local rsB=seed(rand(rsA));
#if(rand(rsA)=rand(rsB))
  #debug "Yes, I am sure.\n"
#else
  #debug "No, I am not sure.\n"
#end

Regards,
John

Post a reply to this message

"Vadim Sytnikov" <syt### [at] rucom> wrote:
> BTW, in the same vein... Can't remember who (Knuth? Deikstra? Wirth?) said
> that, but I liked it very much:
>
> "Anyone who considers arithmetic means of producing random numbers is, of
> course, in a state of sin."

Google helped, as always... It was John von Neumann.

(and the exact quote is "Anyone who considers arithmetical methods of
producing random digits is, of course, in a state of sin").

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Right. But that won't happen for any number of objects you are likely to 
> hit.

  It depends a lot on your initial seed values. If you are very unlucky,
the second number you get from stream 1 will be the same as the first
number you got from stream 2, and it will then begin to give the same
numbers from that point forward.
  Of course in theory the chance of this happening is 1/(2^32), that is,
extremely unlikely, but possible. :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christopher James Huff wrote:
> In article <3e4ac5d2@news.povray.org>, Warp <war### [at] tagpovrayorg> 
> wrote:
> 
> 
>>  What I claimed was that eventually one of the streams will start giving
>>the same numbers as the other streams gave to start with. And also the
>>other way around.
> 
> 
> Ok, I understand. Yes, that will happen.

The problem being, as I understand it, that there is only one sequence 
of random numbers in POV (if m follows n in one run, m will always 
follow n), as stated earlier.
Could this not be easily worked around by the following:
Where you want two sequences that are ordered differently, use four 
random sequences with the seeds a1, a2, b1 and b2. To get a random 
number for your first sequence add the two 'a' seqences modulo 2^32, 
likewise for the second sequence add the two 'b' seqences modulo 2^32.
This would probably introduce more problems than it solves for some 
purposes, leading to even less randomness in the low bits, and to some 
values never being visited and others being visited disproportionately 
frequently.

Alternately you could implement your own PNG in POV-SDL.

Post a reply to this message

Edward Coffey <eco### [at] alphalinkcomau> wrote:
> This would probably introduce more problems than it solves for some 
> purposes, leading to even less randomness in the low bits

  When dealing with random number generators, it's a very common principle,
that trying to make a good RNG better by adding more clutter to it usually
makes it a lot worse. (The natural way of thinking that "a more complicated
function will probably lead to a more complicated result" is usually quite
false when dealing with RNGs. Usually when trying to make the function
"more complicated" you end up with an extremely poor RNG.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> Edward Coffey <eco### [at] alphalinkcomau> wrote:
> 
>>This would probably introduce more problems than it solves for some 
>>purposes, leading to even less randomness in the low bits
> 
> 
>   When dealing with random number generators, it's a very common principle,
> that trying to make a good RNG better by adding more clutter to it usually
> makes it a lot worse. (The natural way of thinking that "a more complicated
> function will probably lead to a more complicated result" is usually quite
> false when dealing with RNGs. Usually when trying to make the function
> "more complicated" you end up with an extremely poor RNG.)

Oh, absolutely, I wasn't trying to make a better PRNG, indeed I stated 
that it would be worse for many situations. The only benefit it provides 
is providing different sequences, so if the number 1929474638 follows 
92928 in one sequence, the same will not necessarily occur in another. 
Obviously if you need really good psuedo-random numbers in POV there are 
far better options if you're prepared to put in a little effort.

Post a reply to this message