 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Weyer <wey### [at] informatik uni-freiburgde> wrote:
> which returned 0. Now if you think this over, that means that it
> is a full period generator.
If this is so, then it means that there's actually just one single
fixed stream of pseudo-random numbers in POV-Ray, and with seed() you
just tell where to start taking numbers from this stream.
(On implication of this is that if you have two streams generated
with different seed() values, they will both eventually start to give
the same numbers as the other.)
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote:
> (On implication of this is that if you have two streams generated
> with different seed() values, they will both eventually start to give
> the same numbers as the other.)
AFAIK, preventing such behaviuor was never a desing goal of multiple RNG
streams in POV-Ray... They are there simply to protect scenes that rely on
RNG in placing/scattering objects etc.
On the other hand, the implication you point out may easily become of
importance for other scenes... IMHO one possible solution is to use the
RANDMAR generator I mentioned in my other post; it was specially designed to
provide users with ~32k independent streams.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e4a67f6@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> If this is so, then it means that there's actually just one single
> fixed stream of pseudo-random numbers in POV-Ray, and with seed() you
> just tell where to start taking numbers from this stream.
Correct.
> (On implication of this is that if you have two streams generated
> with different seed() values, they will both eventually start to give
> the same numbers as the other.)
Not correct. They will both repeat, and repeat the same sequence, but if
they are initialized with different seeds, they will always have
different numbers at any moment. Assuming you pull random numbers from
each at an equal rate, anyway.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlinknet> wrote:
>
> > (On implication of this is that if you have two streams generated
> > with different seed() values, they will both eventually start to give
> > the same numbers as the other.)
>
> Not correct. They will both repeat, and repeat the same sequence, but if
> they are initialized with different seeds, they will always have
> different numbers at any moment. Assuming you pull random numbers from
> each at an equal rate, anyway.
I think the notion of "any moment" is not particularly applicable here...
Imagine a scene similar to one generated with Chris Colefax's City
Generator. The implication that Warp (probably; me -- certainly) meant is
that is if you, say, use different streams *and* different seeds for each
block, you may still end up with very similar blocks since the sub-sequences
your RNGs generate may still overlap.
To be even more specific: think about blocks with scattered trees. If your
streams' sub-sequences overlap, you may end up with many *equally* (not even
"similarly") shaped and located trees in different blocks. Hope you got the
idea...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Vadim Sytnikov" <syt### [at] rucom> wrote in message
news:3e4a7ee8$1@news.povray.org...
> To be even more specific: think about blocks with scattered trees. If your
> streams' sub-sequences overlap, you may end up with many *equally* (not even
> "similarly") shaped and located trees in different blocks. Hope you got the
> idea...
True - however the sheer length of the stream would make this unlikely. Also,
consider:
#declare R1 = seed(3245);
#declare R2 = seed(7342);
#while(true)
#declare A1 = rand(R1);
#declare A2 = rand(R2);
#declare A3 = rand(R2);
.....
#end
Because R2 is hit twice, but R1 only once, A1 and A2 will never show the same
sequence (afaik).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e4a82f0$1@news.povray.org...
<snip>
Meanwhile, I'm still looking for my 3 numbers in a row.
Here's the code (and a clue;)....
#declare Found = false;
#declare Seed1 = 0;
#declare Count = 1;
#declare Searching = true;
#while(Searching)
#declare Rand1 = seed(Seed1);
#declare Val = rand(Rand1)*235;
#if(int(Val) = 234)
#declare Val = rand(Rand1)*235;
#if(int(Val) = 85)
#debug concat(str(Count,0,0),": B: ",str(int(Val),0,0), "\n")
#declare Count = Count + 1;
#declare Val = rand(Rand1)*235;
#if(int(Val) = 81)
#debug concat("C: ",str(int(Val),0,0), "\n")
#debug concat("\n", "Seed = ",str(Seed1,0,0),"\n")
#declare Searching = false;
#end
#end
#end
#declare Seed1 = Seed1 + 1;
#end
--
#macro A(V,B,C,R)#while(B-256)#if(V-128/B>=0)sphere{0,.5translate<C-4R-1,9>
pigment{rgb<1-C/8R/2C/8>}}#local V=V-128/B;#end#local B=B*2;#local C=C+1;#
end#end A(234,1,0,2)A(85,1,0,1)A(81,1,0,0)light_source{-5 1}//Tom Melly
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> wrote:
>
> True - however the sheer length of the stream would make this unlikely.
Well, I would say, completely impossible things are all around! :-)
In the Knuth's Vol2 I metnioned the author gives a very educative account of
his early experience with designing RGNs. By then, he was young enough :-)
to try to invent the best (no less!) RNG in the world. So he came up with an
utterly sophisticated, if not cryptic, scheme.
Guess what? His RNG repeated itself on step 18! (IIRC; in either case, the
number was around 20...). That taught him... many important things. :-)
Which I hope I have absorbed while reading his excellent books.
BTW, in this respect, Knuth was not alone. One of IBM's RNGs (shipped as
part of FORTRAN libraries for 360's, I believe) appeared to produce series
that, if interpreted as 3D coordinates, would form points all lying on just
several planes in 3D space.
So... :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vadim Sytnikov <syt### [at] rucom> wrote:
> BTW, in this respect, Knuth was not alone. One of IBM's RNGs (shipped as
> part of FORTRAN libraries for 360's, I believe) appeared to produce series
> that, if interpreted as 3D coordinates, would form points all lying on just
> several planes in 3D space.
In the man page of rand() in some Unix variant (don't remember which)
there was a note that the lowest bit of the number returned by rand() should
not be used because it alternates between 0 and 1 in successive calls.
Makes one wonder if it wouldn't be better to fix the problem instead
of documenting it... :)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e4a7ee8$1@news.povray.org>,
"Vadim Sytnikov" <syt### [at] rucom> wrote:
> I think the notion of "any moment" is not particularly applicable here...
That was a bit vague, I was in a hurry. I meant that if you took two
streams with different seeds (which internally are different positions
on one stream), and keep taking random numbers from both, you will never
reach a point where both produce the same sequence.
The random number generator POV uses is not that great, for example: a
given number can only occur once in the sequence. It is sufficient for
most uses, though, and fast and simple.
> To be even more specific: think about blocks with scattered trees. If your
> streams' sub-sequences overlap, you may end up with many *equally* (not even
> "similarly") shaped and located trees in different blocks. Hope you got the
> idea...
Actually, because of the way tree algorithms work, a little difference
can produce an entirely different tree, even if the random stream is
almost the same. They are often quite chaotic. But I get what you
mean...it is possible, but the period is large enough to make it
unlikely.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Vadim Sytnikov" <syt### [at] rucom> wrote:
>
> Well, I would say, completely impossible things are all around! :-)
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."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
