 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlink net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e4a9fe0@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> 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... :)
Maybe there was some other constraint that kept them from doing
so...performance, etc. Or maybe they just didn't know anything about
PRNG's.
In any case, I never use rand(). I occasionally use random(). From the
manpage:
The random() function uses a non-linear additive feedback random
number generator employing a default table of size 31 long
integers to return successive pseudo-random numbers in the range
from 0 to (2**31)-1. The period of this random number generator
is very large, approximately 16*((2**31)-1).
The random() and srandom() functions have (almost) the same
calling sequence and initialization properties as the rand(3) and
srand(3) functions. The difference is that rand(3) produces a
much less random sequence -- in fact, the low dozen bits generated
by rand go through a cyclic pattern. All the bits generated by
random() are usable. For example, `random()&01' will produce a
random binary value.
It is pretty simple to create a wrapper class for it. Usually I use a
Mersenne Twister class I wrote. (Meaning of course that I wrote the
class, much of the code is very close to the original implementation by
Makoto Matsumoto and Takuji Nishimura.)
This is the random number generator I used in Sapphire.
--
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:
> In any case, I never use rand(). I occasionally use random().
If what you need are random floating point numbers, then drand48() should
do the job.
DESCRIPTION
This family of functions generates pseudo-random numbers
using the well-known linear congruential algorithm and 48-
bit integer arithmetic.
Functions drand48() and erand48() return non-negative
double-precision floating-point values uniformly distributed
over the interval [0.0, 1.0].
Functions lrand48() and nrand48() return non-negative long
integers uniformly distributed over the interval [0, 2**31].
Functions mrand48() and jrand48() return signed long
integers uniformly distributed over the interval [-2**31 , 2
**31 ].
Functions srand48(), seed48(), and lcong48() are initializa-
tion entry points, one of which should be invoked before
either drand48(), lrand48(), or mrand48() is called.
(Although it is not recommended practice, constant default
initializer values will be supplied automatically if
drand48(), lrand48(), or mrand48() is called without a prior
call to an initialization entry point.) Functions erand48(),
nrand48(), and jrand48() do not require an initialization
entry point to be called first.
All the routines work by generating a sequence of 48-bit
integer values, Xi , according to the linear congruential
formula
X n+1= (aX n+c) mod m n>=0.
The parameter m = 2**48; hence 48-bit integer arithmetic is
performed. Unless lcong48() has been invoked, the multiplier
value aand the addend value care given by
a = 5DEECE66D16 = 2736731631558
c = B16 = 138 .
The value returned by any of the functions drand48(),
erand48(), lrand48(), nrand48(), mrand48(), or jrand48() is
computed by first generating the next 48-bit Xi in the
sequence. Then the appropriate number of bits, according to
the type of data item to be returned, are copied from the
high-order (leftmost) bits of Xi and transformed into the
returned value.
The functions drand48(), lrand48(), and mrand48() store the
last 48-bit Xi generated in an internal buffer. Xi must be
initialized prior to being invoked. The functions erand48(),
nrand48(), and jrand48() require the calling program to pro-
vide storage for the successive Xi values in the array
specified as an argument when the functions are invoked.
These routines do not have to be initialized; the calling
program must place the desired initial value of Xi into the
array and pass it as an argument. By using different argu-
ments, functions erand48(), nrand48(), and jrand48() allow
separate modules of a large program to generate several
independent streams of pseudo-random numbers, that is, the
sequence of numbers in each stream will not depend upon how
many times the routines have been called to generate numbers
for the other streams.
The initializer function srand48() sets the high-order 32
bits of Xi to the 32 bits contained in its argument. The
low-order 16 bits of Xi are set to the arbitrary value
330E16 .
The initializer function seed48() sets the value of Xi to
the 48-bit value specified in the argument array. In addi-
tion, the previous value of Xi is copied into a 48-bit
internal buffer, used only by seed48(), and a pointer to
this buffer is the value returned by seed48(). This returned
pointer, which can just be ignored if not needed, is useful
if a program is to be restarted from a given point at some
future time - use the pointer to get at and store the last
Xi value, and then use this value to reinitialize using
seed48() when the program is restarted.
The initialization function lcong48() allows the user to
specify the initial Xi the multiplier value a, and the
addend value c. Argument array elements param[0-2] specify
Xi, param[3-5] specify the multiplier a, and param[6] speci-
fies the 16-bit addend c. After lcong48() has been called, a
subsequent call to either srand48() or seed48() will restore
the ``standard'' multiplier and addend values, a and c,
specified above.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> 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.
That's not even what I claimed.
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.
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.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
