 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e4a9fe0@news.povray.org>, Warp <war### [at] tag povrayorg>
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
|
|
| |
| |
|
|
|
|
| |
|
|
