 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How many numbers are in the rand stream before it repeats itself, or is this a
meaningless question?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Repitition is inherent in randomness.
"Tom Melly" <tom### [at] tomandlu couk> wrote in message
news:3e492ce1@news.povray.org...
> How many numbers are in the rand stream before it repeats itself, or is
this a
> meaningless question?
>
> --
> #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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Harold" <bai### [at] 3dculturecom> wrote in message
news:3e493171$1@news.povray.org...
> Repitition is inherent in randomness.
but isn't it a pseudo random string? - i.e. the repitition is predictable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
> How many numbers are in the rand stream before it repeats itself, or is this a
> meaningless question?
Test 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e493e0c@news.povray.org...
> Test it?
I sort of am (I'm trying to get a specific sequence of numbers from a random
stream - don't ask).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom & Lu Melly" <all### [at] tomandlucouk> wrote
>
> I sort of am (I'm trying to get a specific sequence of numbers from a
random
> stream - don't ask).
>
Wh.........
*realises he's just been told not to ask*
John
--
Run Fast
Run Free
Run Linux
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
>
> How many numbers are in the rand stream before it repeats itself, or
> is this a meaningless question?
#declare rsA=seed(0);
#declare rsB=seed(0);
#local sA=0;#local sB=-1;
#local cR=0;
#while(sA!=sB)
#local sA=rand(rsA);
#local sB=rand(rsB);
#local sB=rand(rsB);
#local cR=cR+1;
#end
#debug concat("Seed repeats after ",str(cR,0,0)," repetitions.\n"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> wrote:
> How many numbers are in the rand stream before it repeats itself, or is
this a
> meaningless question?
I assume we're talking about pseudo random numbers generators here, right?
The number you are talking about is known as the period of a generator and
is one of its most important properties... The two best generators that I
know are RANDMAR (with period 2^144; I use this one in my projects), and
R250 (with period 10^250, i.e. 1e251).
BTW, the "before it repeats itself" actually applies to the sub-sequences,
and not to individual numbers... RNGs' internals make it possible for many
different numbers to follow any given number. For instance, the following
sequence is easily possible with many RNGs:
1 2 3 4 2 9
Notice that 2 is first followed by 3, and then by 9. But if the period of
this generator is 6 :-), then 9 will be followed by 1 -- it is here that the
actual repetition takes place.
...
Oh well, I just figured out that that's p.g, so you probably meant POV-Ray
streams. Sorry for an off-topic post. Follow-ups to p.programming.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"John VanSickle" <evi### [at] hotmailcom> wrote in message
news:3E4### [at] hotmailcom...
> #debug concat("Seed repeats after ",str(cR,0,0)," repetitions.\n"
I'll take your word for it ;) Many thanks...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
Naturally this might be so, but if the random number generator is made
even with the slightest quality, the same number can repeat many times
in the stream before it loops over.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mark Wagner" <mar### [at] gtenet> wrote in message
news:pan### [at] gtenet...
> On Tue, 11 Feb 2003 12:03:28 -0500, Tom Melly quoth:
>
> > How many numbers are in the rand stream before it repeats itself, or is
> > this a meaningless question?
>
> 4.29 billion (2^32, to be exact).
Many thanks (so I shouldn't have given up at 500000 then? ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3e497ebc@news.povray.org...
> 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?
> Naturally this might be so, but if the random number generator is made
> even with the slightest quality, the same number can repeat many times
> in the stream before it loops over.
Once I'd worked out what the code did, the same thought occured - is there
something in the way the stream is generated that makes that impossible? For
example, that a particular number is always followed by another fixed number?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
> Once I'd worked out what the code did, the same thought occured - is there
> something in the way the stream is generated that makes that impossible? For
> example, that a particular number is always followed by another fixed number?
This depends a lot on how the random number generator is implemented.
There are (good) random number generators where the period is a lot larger
than the value range (eg. you get numbers between 0 and 2^64-1 from it, but
it gives you for example 2^256 numbers before starting over, which of course
means that the same number appears in the stream several times).
As I don't have any idea what kind of algorithm pov's generator uses,
I can't say how it works there. Very simple generators start repeating
over immediately when the same number which has appeared before appears
again.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
>> How many numbers are in the rand stream before it repeats itself, or is
>> this a meaningless question?
> 4.29 billion (2^32, to be exact).
Do you have any concrete proof or demonstration of this?
--
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 wrote:
> Tom Melly <tom### [at] tomandlucouk> wrote:
>> Once I'd worked out what the code did, the same thought occured - is
>> there something in the way the stream is generated that makes that
>> impossible? For example, that a particular number is always followed by
>> another fixed number?
>
<snip>
> As I don't have any idea what kind of algorithm pov's generator uses,
> I can't say how it works there. Very simple generators start repeating
> over immediately when the same number which has appeared before appears
> again.
>
I found following in POV's express.cpp
static DBL stream_rand(int stream)
{
next_rand[stream] = next_rand[stream] * 1812433253L + 12345L;
return((DBL)(next_rand[stream] & 0xFFFFFFFFUL) / 0xFFFFFFFFUL);
}
An iterated random generator like this obiously cannot have a longer period
than 2^sizeof(int).
- Micha
--
POV-Ray Objects Collection: http://objects.povworld.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>How many numbers are in the rand stream before it repeats itself
>
>>4.29 billion (2^32, to be exact).
>
> Do you have any concrete proof or demonstration of this?
There is such proof. From the source (texture.cpp, don't know why there):
static unsigned long int next_rand = 1;
int POV_RAND()
{
next_rand = next_rand * 1812433253L + 12345L;
return((int)(next_rand >> 16) & RNDMASK);
}
I turned this into a program for testing the period as follows:
#include <iostream.h>
void main() {
static unsigned long int next_rand = 1;
static unsigned long int count = 0;
do {
next_rand = next_rand * 1812433253L + 12345L;
count++;
} while (next_rand!=1);
cout << count;
}
which returned 0. Now if you think this over, that means that it
is a full period generator.
--
max_trace_level 256media{absorption.02}camera{location<1,.3,1.7>}sphere{0
.8pigment{color.6}interior{media{emission<2,2,-2>absorption 2}}hollow}#macro
p(f,n)plane{n f-1finish{reflection<f,1f>}}#end p(1y)p(1z-x)p(-1,-z)p(1x-y)
// Mark Weyer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There is such proof. From the source (texture.cpp, don't know why there):
From Micha Reiser's post I conclude that I might have looked in the
wrong place. The generator is the same, however.
--
max_trace_level 256media{absorption.02}camera{location<1,.3,1.7>}sphere{0
.8pigment{color.6}interior{media{emission<2,2,-2>absorption 2}}hollow}#macro
p(f,n)plane{n f-1finish{reflection<f,1f>}}#end p(1y)p(1z-x)p(-1,-z)p(1x-y)
// Mark Weyer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Weyer <wey### [at] informatikuni-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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
