 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d9434b1@news.povray.org>, Warp <war### [at] tag povrayorg>
wrote:
> Then it's a rather poor random number generator, I must say.
> In a good random number generator, any combination of two numbers (including
> the same number twice) should be about equally probable.
> Of course this is a very difficult issue.
I don't think this alone makes it so bad, its other characteristics seem
fair. Not great, but not horrible. It is an extremely simple algorithm,
I posted the code earlier in this thread.
If you want a really good generator, the Mersene Twister might be
suitable...I've heard good things about it, and wrote an implementation
of it that seems to work fine.
> I wonder if an approach like the drand48() function would be better.
What approach would that be?
--
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 <chr### [at] maccom> wrote:
>> I wonder if an approach like the drand48() function would be better.
> What approach would that be?
From the drand48 man page:
Functions drand48() and erand48() return non-negative
double-precision floating-point values uniformly distributed
over the interval [0.0, 1.0].
[snip]
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 a and the addend value c are 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.
[snip]
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 .
--
#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:
> represented with a double precision variable, with a perfect random
> number generator any one of those values would be equally likely,
<g>
But then, for perfect random number generator, wouldn't we need to
plug a fresh cup of really hot tea into the USB port and use the
non-standard C function getbrownian() and somehow cast the
resulting vector as a double? Alas, I understand getbrownian()
isn't directly supported on all the platforms that POV-Ray is
compiled for, (or any of them, in fact) so this might somewhat
hurt portability.
</g>
--
@C[$F];
The Silver Tome :: http://www.silvertome.com
"You may sing to my cat if you like..."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 27 Sep 2002 20:11:30 -0400, Charles Fusner <cfu### [at] enternet>
wrote:
>But then, for perfect random number generator, wouldn't we need to
>plug a fresh cup of really hot tea into the USB port and use the
>non-standard C function getbrownian() and somehow cast the
>resulting vector as a double?
The problem with this approach is that the second law of
thermodynamics will kick in, which means that in animations, later
frames will have lower dispersion in their random sequences. This will
also result in pretty interesting vertical gradient patterns in
radiosity pictures due to the random number generator cooling down
during the long render.
<follow-ups set>
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27 Sep 2002 11:54:18 -0400, Warp <war### [at] tagpovrayorg> wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
>>> I wonder if an approach like the drand48() function would be better.
>
>> What approach would that be?
>
> From the drand48 man page:
>
> Functions drand48() and erand48() return non-negative
> double-precision floating-point values uniformly distributed
> over the interval [0.0, 1.0].
...
some time ago I played with PRNG's...
'worst-case' simulation or something.
25000 spheres were 'randomly' positioned.
'incr-seeds' means that for every sphere different initial seeds
were used (little bigger than for the previous sphere).
for every sphere position six (pseudo) random number generator
states (or seeds) were needed.
now, if spheres are not placed uniformly, it means that seed
values correlate with the output of the generator
(bad thing for a PRNG).
'one-seeding' means that for all of the 25000 sphere positions
only six seeds were used (and I mean six in TOTAL).
if spheres are not placed uniformly (in both -1 and -2 jpg),
it means that the PRNG plainly sucks.
I made patch for povray 3.5 which allows using GSL's RNG's
by defining env var POVRAY_USE_GSL and then wanted generator
in GSL_RNG_TYPE. if POVRAY_USE_GSL is not defined, SHA-512 is used.
of every PRNG in GSL v1.2, only mt19937 was 'okay' in my *humble*
opinion. YMMV.
(GSL+SHA-512 patch not available for public as for now)
scene file source
http://iki.fi/safari/prng/rnd_sphere2.pov
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-rand48-1.jpg
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-rand48-2.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-rand48-1.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-rand48-2.jpg
compare to a 'better' PRNG
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-sha-512-1.jpg
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-sha-512-2.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-sha-512-1.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-sha-512-2.jpg
and with povray 3.5's official PRNG
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-orig-1.jpg
http://iki.fi/safari/prng/incr-seeds/rnd_sphere2-orig-2.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-orig-1.jpg
http://iki.fi/safari/prng/one-seeding/rnd_sphere2-orig-2.jpg
interesting, it's almost like rand48.
usually povray's PRNG is sufficient, but sometimes I get
artefacts in photon shooting (not evenly placed or something)...
and, of course, when using this kind of scene file :)
(yes, SHA1 would probably give same kind of results than SHA-512,
but that's another story)
--
Safari - y7p### [at] sneakemailcomgovinvalid
"Talk is cheap. Show me the code." - Linus Torvalds
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
