POV-Ray : Newsgroups : povray.documentation.inbuilt : (seed) could use a better explanation Server Time: 19 Oct 2019 09:32:49 GMT
  (seed) could use a better explanation (Message 1 to 10 of 16)  
Goto Latest 10 Messages Next 6 Messages >>>
From: Kenneth
Subject: (seed) could use a better explanation
Date: 7 Oct 2005 19:45:00
Message: <web.4346cfc1e586756ca0ad5af90@news.povray.org>
I'm somewhat new to these newsgroups, so please excuse me if this topic has
been covered in depth before.

The description of SEED in the POV docs still has me scratching my head
about some things.  I USE it, all the time, but I don't really understand
what exactly it does. Perhaps this question belongs elsewhere in the
newsgroups, but a better explanation in the docs could ease the pain!

My questions are these:
1) For each and every individual number that is placed into SEED (------),
does POV create an entirely NEW and DIFFERENT psuedo-random stream of
numbers for RAND to choose from?

OR

2) When invoking SEED, does POV first create ONE SINGLE LONG psuedo random
stream of numbers (the "random" values of which depend on the host computer
and OS it's running on)? And does the individual number then placed into
SEED simply choose a different LOCATION within this single long stream, for
RAND to start with?


Post a reply to this message

From: Warp
Subject: Re: (seed) could use a better explanation
Date: 7 Oct 2005 20:26:02
Message: <4346d9d9@news.povray.org>
Kenneth <kdw### [at] earthlinknet> wrote:
> 2) When invoking SEED, does POV first create ONE SINGLE LONG psuedo random
> stream of numbers (the "random" values of which depend on the host computer
> and OS it's running on)? And does the individual number then placed into
> SEED simply choose a different LOCATION within this single long stream, for
> RAND to start with?

  Although povray does not create a concrete stream of numbers, that
explanation is technically correct (except that the values do not depend
on the platform).

  One could say that POV-Ray uses a fixed list of 2^32 pseudorandom numbers,
and seed() simply chooses where to start reading numbers from this list.
One could think of it as a starting index (eg. like "start reading numbers
from position 100 forward in the list).

  Naturally POV-Ray doesn't have this list of numbers stored in memory
(it would require prohibitive amounts of memory) but the items in the list
are created on the fly with a simple (yet cryptographically rather good)
formula as needed.

  As mentioned, that formula is platform-independent, so you will always
get the same numbers in all platforms.

  However, these are rather low-level details of the implementation of
the random number generator. You certainly don't need to know this in
order to use them.

-- 
                                                          - Warp


Post a reply to this message

From: Kenneth
Subject: Re: (seed) could use a better explanation
Date: 7 Oct 2005 22:30:00
Message: <web.4346f5e06c2f1bf6844fe410@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:


>
>   One could say that POV-Ray uses a fixed list of 2^32 pseudorandom numbers,
> and seed() simply chooses where to start reading numbers from this list.
> One could think of it as a starting index (eg. like "start reading numbers
> from position 100 forward in the list).

Thanks!  That clears up all my questions. (And would be a good addition to
the POV docs!)


>   However, these are rather low-level details of the implementation of
> the random number generator. You certainly don't need to know this in
> order to use them.

Actually, I think there *might* arise situations where the knowledge of how
SEED works could prevent confusion in the visual apprearance of a scene.

Let's see if I can phrase this correctly:  Say you choose SEED(432) to
initialize your first random number process. Then the first "random" number
that RAND chooses from that will be, let us say, .36547 (not really, that's
just a guess.) And the next "random" number that RAND chooses will be, let
us say, .85645.  Fine and dandy, so far. NOW, if you then, without
thinking, choose to initialize a new SEED as SEED (433) -- i.e., only one
integer number away from your first SEED value-- then the very first
"random" number that this new SEED's RAND function will choose will be, lo
and behold, .85645---the very same "random" number that the FIRST SEED's
2nd RAND  function returned!  Am I making sense? I can think of an example
(untried) where this might look odd: Create an orderly row of 20 simple
objects, each randomly colored using my 1st SEED value.  Then create a 2nd
row of 20 objects, right behind the first and lined up with it, but
randomly colored using my 2nd  SEED value.  The visual appearance would be
that the "random" colors for each row would be *almost* the same, offset by
only ONE color!

At least, that's my conceptual understanding of what would happen.

If my thinking is correct, this is wholly different behavior than if SEED
created completely *new and different* random number streams for each and
every number that was placed into it.


Post a reply to this message

From: Kenneth
Subject: Re: (seed) could use a better explanation
Date: 8 Oct 2005 00:35:00
Message: <web.434712de6c2f1bfb24699ca0@news.povray.org>
"Kenneth" <kdw### [at] earthlinknet> wrote:

>
> Actually, I think there *might* arise situations where the knowledge of how
> SEED works could prevent confusion in the visual apprearance of a scene.
>

I decided to run my own code example, as outlined above, and the results do
NOT agree with my concept of it. Which leaves me at a loss as to what's
going on. The colors in both rows of objects look completely different,
i.e., no near-repetition of colors. Is my code wrong, or is my concept
wrong?

Here's my code, ready to run. (No lights needed.) The lower row of objects
is colored using the 1st SEED value, and the higer row with the 2nd SEED
value:

------------

global_settings {assumed_gamma 1.8}

camera {
  perspective
  location  <10, 30, -30>
  look_at <10, 2, 0>
  right     x*image_width/image_height  // aspect ratio
  angle 35
       }


#declare shape =
object{
        cylinder{<0,0,0>, <0,3,0>, .2}
      }


// using 1st SEED value...
#declare S1 = seed (470);
#declare index = 1;
#while (index <= 20)
object {shape
        texture{
                pigment {color rgb <rand(S1),.5,.5>}
                finish{
                        ambient 1
                        diffuse 0
                      }
               }
        translate <index,0,0>
       }

#declare index = index + 1;
#end


// using 2nd SEED value...
#declare S1 = seed (471);
#declare index = 1;
#while (index <= 20)
object {shape
           texture{
                pigment{color rgb <rand(S1), .5,.5>}
                finish{
                        ambient 1
                        diffuse 0
                      }
                  }
         translate <index,0,4>
       }

#declare index = index + 1;
#end


Post a reply to this message

From: Kenneth
Subject: Re: (seed) could use a better explanation
Date: 8 Oct 2005 01:25:01
Message: <web.43471f9d6c2f1bf782eee3d0@news.povray.org>
"Kenneth" <kdw### [at] earthlinknet> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
>

> I decided to run my own code example, as outlined above, and the results do
> NOT agree with my concept of it. Which leaves me at a loss as to what's
> going on.

Not to beat this poor horse into the ground, but I've just made a "major new
discovery!" New for ME, anyway. It is this:

THE VALUE PLACED INTO SEED CAN BE A FLOATING-POINT NUMBER, NOT JUST AN
INTEGER.

I never thought of doing that, or that it COULD be done. Which would explain
why my own code isn't doing what I thought it would.

I have to say I've never come across this bit of info anywhere in the POV
docs, NOR on any of the tutorial websites I've been to. Perhaps it should
have been a "no brainer," considering that POV always works with
floats...but here's the basis for my misconception:

1) POV's description of SEED makes no mention of that..which by itself is
probably understandable (if a bit non-informative).
2) POV's description of RAND, however--found directly above SEED in the
docs,--says: "rand(I)  Returns the next psuedo-random number from the
stream specified by the positive integer I."  POSITIVE INTEGER I.  Hmm.....


Post a reply to this message

From: Kenneth
Subject: Re: (seed) could use a better explanation
Date: 8 Oct 2005 02:20:00
Message: <web.43472ba46c2f1bf1b45c0860@news.povray.org>
"Kenneth" <kdw### [at] earthlinknet> wrote:

> ...I've just made a "major new
> discovery!" New for ME, anyway. It is this:
>
> THE VALUE PLACED INTO SEED CAN BE A FLOATING-POINT NUMBER, NOT JUST AN
> INTEGER.
>

Hello again, everyone!!!!   : - )

Well....... OOPS (he says, with egg on his face), I see now--and should have
seen earlier, sorry-- that although SEED can accept a floating-point
number, it simply truncates the fractional part and only uses the integer.
I.e., seed(432.9574635) becomes simply seed(432)

SO..... EVERYONE FORGET THAT LAST POST, OK?  OK?  (heh heh)

And now I'm back to being quite perplexed. Referring to my post before the
last one (!), again I ask: Is my code wrong, or is my concept wrong?

Ken


Post a reply to this message

From: Warp
Subject: Re: (seed) could use a better explanation
Date: 8 Oct 2005 05:36:18
Message: <43475ad2@news.povray.org>
Kenneth <kdw### [at] earthlinknet> wrote:
> Let's see if I can phrase this correctly:  Say you choose SEED(432) to
> initialize your first random number process. Then the first "random" number
> that RAND chooses from that will be, let us say, .36547 (not really, that's
> just a guess.) And the next "random" number that RAND chooses will be, let
> us say, .85645.  Fine and dandy, so far. NOW, if you then, without
> thinking, choose to initialize a new SEED as SEED (433) -- i.e., only one
> integer number away from your first SEED value-- then the very first
> "random" number that this new SEED's RAND function will choose will be, lo
> and behold, .85645---the very same "random" number that the FIRST SEED's
> 2nd RAND  function returned!  Am I making sense?

  It's logical to come to that conclusion from my explanation, but it
doesn't work like that.
  You see, I said "you can think of it as an index", but it's not a
linear index. The seed value is closely related to the random number
generation itself, which means that the relation between a seed value
and the value returned by rand() is pseudorandom as well.

  Ok, I'm not even sure myself that that explanation was understanble (or
even correct, for that matter).
  What I mean is that the order in which rand() pops numbers from the list
is not the same order as seed() "indexes" that list. The "index" jumps
pseudorandomly over the "list" of numbers. This means that if you use
seed(100), pop a number with rand() and then another, that next number
might well correspond to something like what seed(5033921) will make
rand() to return at first.

  The seed value (which is a 32-bit integer) jumps pseudorandomly over
its entire value space (ie. between 0 and 2^32-1) and the value returned
by rand() is simply calculated from this seed value.
  The formula which modifies the seed value is just so incredibly ingenuous
that it will really go through all 2^32 possible values in a pseudorandom
order before starting over.

> If my thinking is correct, this is wholly different behavior than if SEED
> created completely *new and different* random number streams for each and
> every number that was placed into it.

  From the point of view of the user it is almost as good as if seed()
created completely new random streams for every different value of seed()
because there's very seldom any overlapping. In some rare cases you might
encounter that one rand() starts repeating the same values as another rand()
using a different seed, but that happens very rarely.
  After all, you have 2^32 possible start points to start from (and it's
very hard to find start points which are close together).

-- 
                                                          - Warp


Post a reply to this message

From: Kenneth
Subject: Re: (seed) could use a better explanation
Date: 10 Oct 2005 18:35:00
Message: <web.434ab1456c2f1bf952c9f5e0@news.povray.org>
> WARP wrote....

>   ...From the point of view of the user it is almost as good as if seed()
> created completely new random streams for every different value of seed()
> because there's very seldom any overlapping.
>                                                           - Warp

FASCINATING!  POV's cryptographic scheme is quite amazing. It sure does
"stir the soup" of random numbers!  THANKS for taking the time to go into
this in such detail; I've never seen it so well-explained. Bottom line:  I
no longer need to worry about the exact value placed into SEED.  Happy days!

Ken


Post a reply to this message

From: Ken Hutson
Subject: Re: (seed) could use a better explanation
Date: 11 Oct 2005 00:09:55
Message: <434b02d3@news.povray.org>
Kenneth,
There is some intresting reading on pseudo-random number generation at 
www.wikipedia.org
Kenneth Hutson


Post a reply to this message

From: Kenneth
Subject: Re: (seed) could use a better explanation
Date: 11 Oct 2005 06:50:01
Message: <web.434b5fe16c2f1bf914d4b080@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:

>   The formula which modifies the seed value is just so incredibly ingenious
> that it will really go through all 2^32 possible values in a pseudorandom
> order before starting over.
>

>                                                           - Warp

BTW, I understand now why the complex technical workings of SEED would
probably be inappropriate for inclusion in the POV docs. That's a lot of
information, most (all?) of which would be needed to do it justice. I do
think, though, that a few of the general concepts could be touched on, if
only for general interest.

The RAND and SEED definitions still seem a bit ....obtuse?...in their
present form, at least to me.  But rather than whine and complain, I think
I'll try my own hand at coming up with some meatier explanations. If  I
manage to do so, I'll post them for vetting.

Thanks again!

Ken


Post a reply to this message

Goto Latest 10 Messages Next 6 Messages >>>

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.