I've played around with some "animations" where I am really testing out a
parameter space (fractals: camera position; hetero_mf's: parmeters).

I set up a #declare RRR=seed(frame_number);

Then I go using a whole bunch of rand(RRR)'s.  I can then set up a hundred
or thousand frame animation, go to sleep, and come back and use the
interesting images as the basis for further exploration. 

Problem is, a couple times when I was printing out the random values, I
noticed that every nth one were decreasing monotonically.  I don't remember
if it were the 7th or 17th one (hence a stupid bug report).

Q: is this expected behavior or already known?
Q: is anyone interested in taking the time to research this for me?


I've worked around it with some crazy formulas like:
#declare
RRR=seed(1200*abs(sin(frame_number/11.11))+550*abs(cos(frame_number/13.333)));

Post a reply to this message

Greg M. Johnson wrote:
> I've played around with some "animations" where I am really testing
> out a parameter space (fractals: camera position; hetero_mf's:
> parmeters).
>
> I set up a #declare RRR=seed(frame_number);

> Problem is, a couple times when I was printing out the random values,
> I noticed that every nth one were decreasing monotonically.

Every nth what? This must be every nth random stream, not every nth value 
within the same random stream.

The random streams are not random from each other. Only the numbers within a 
random stream are random from each other.

> Q: is this expected behavior or already known?

Yes.

When you use #declare RRR=seed(frame_number); then each stream will relate 
to the other streams in a predictable non-random manner.

Rune
-- 
http://runevision.com

Post a reply to this message

Greg M. Johnson wrote:
> I've worked around it with some crazy formulas like:
> #declare
> RRR=seed(1200*abs(sin(frame_number/11.11))+550*abs(cos(frame_number/13.333)));

I use

#declare rsA=seed(Frame);
#declare rsB=seed(floor(12345*rand(rsA)));

And use rsB as the primary seed for things.

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> #declare rsA=seed(Frame);
> #declare rsB=seed(floor(12345*rand(rsA)));

> And use rsB as the primary seed for things.

  Knowing how the random number generator used by povray works (it's pretty
simple, actually), I'm quite convinced that method doesn't actually add
any more "randomness" than simply using rsA as the seed. It simply
produces different results, that's all.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

> John VanSickle <evi### [at] hotmailcom> wrote:
>> #declare rsA=seed(Frame);
>> #declare rsB=seed(floor(12345*rand(rsA)));
> 
>> And use rsB as the primary seed for things.
> 
>   Knowing how the random number generator used by povray works (it's
>   pretty
> simple, actually), I'm quite convinced that method doesn't actually add
> any more "randomness" than simply using rsA as the seed. It simply
> produces different results, that's all.
> 

If the phenomenon I observed is valid, then it could be helpful to have an
less-predictable value by setting the seed based on something that varies
wildly as a function of frame_number: I was using cos & sin.

Post a reply to this message

"Greg M. Johnson" <pte### [at] thecommononethatstartswithYcom> wrote in 
message news:46f0778a@news.povray.org...
> Warp wrote:
>
>> John VanSickle <evi### [at] hotmailcom> wrote:
>>> #declare rsA=seed(Frame);
>>> #declare rsB=seed(floor(12345*rand(rsA)));
>>
>>> And use rsB as the primary seed for things.
>>
>>   Knowing how the random number generator used by povray works (it's
>>   pretty
>> simple, actually), I'm quite convinced that method doesn't actually add
>> any more "randomness" than simply using rsA as the seed. It simply
>> produces different results, that's all.
>>
>
> If the phenomenon I observed is valid, then it could be helpful to have an
> less-predictable value by setting the seed based on something that varies
> wildly as a function of frame_number: I was using cos & sin.

I would probably guess that you don't necessarily need increased randomness 
(or unpredicitability), just that the mode and value-step in the frame/seed 
sequence does shift to a harder pattern for the eye/brain to see.  Which 
John's trick might do without actually increasing "randomness".  In the 
absence of knowledge of the algorithm, experiment.  :-)

Brian

Post a reply to this message

Greg M. Johnson <pte### [at] thecommononethatstartswithycom> wrote:
> If the phenomenon I observed is valid, then it could be helpful to have an
> less-predictable value by setting the seed based on something that varies
> wildly as a function of frame_number: I was using cos & sin.

  What do you mean by "less predictable"?

  From any value returned by the random number generator it's possible
to predict the next values. POV-Ray's RNG uses a very simple algorithm.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

> Greg M. Johnson <pte### [at] thecommononethatstartswithycom> wrote:
>> If the phenomenon I observed is valid, then it could be helpful to have
>> an less-predictable value by setting the seed based on something that
>> varies wildly as a function of frame_number: I was using cos & sin.
> 
>   What do you mean by "less predictable"?
> 
>   From any value returned by the random number generator it's possible
> to predict the next values. POV-Ray's RNG uses a very simple algorithm.
> 


Okay.  To restate, say I do this:

#declare RRR=seed(frame_number);
#declare a01=rand(RRR);
#declare a02=rand(RRR);
#declare a03=rand(RRR);
#declare a04=rand(RRR);
#declare a05=rand(RRR);
#declare a06=rand(RRR);
#declare a07=rand(RRR);
#declare a08=rand(RRR);
#declare a09=rand(RRR);
#declare a10=rand(RRR);
...
#declare an=rand(RRR);


Then for some n, n<20, if I then go plot out the values of an as a function
of frame_number when rendered, one of those values would be a straight
line. One but surely not all. 

That's not exactly predictable but it's entirely non random.

Post a reply to this message

Greg M. Johnson wrote:
> Okay.  To restate, say I do this:
>
> #declare RRR=seed(frame_number);
> #declare a01=rand(RRR);
> #declare a02=rand(RRR);
> #declare a03=rand(RRR);
> #declare a04=rand(RRR);
> #declare a05=rand(RRR);
> #declare a06=rand(RRR);
> #declare a07=rand(RRR);
> #declare a08=rand(RRR);
> #declare a09=rand(RRR);
> #declare a10=rand(RRR);
> ...
> #declare an=rand(RRR);
>
>
> Then for some n, n<20, if I then go plot out the values of an [in one 
> curve for each n]
> as a function of frame_number when rendered, one of those values
> [one of those *curves* not values - a value can't be a line] would be a 
> straight line.
> One but surely not all.

After trying to make sense of this sentence I think I understand what you 
mean and I'd say it's correct.

> That's not exactly predictable but it's entirely non random.

I think that Warp just meant something along the lines that no sequence 
generated by a computer is *really* non-predictable. I don't see how that's 
relevant for this discussion though.

I think the conclusion is that what you have found is not a bug, and you can 
get the behavior you want either by using workarounds with sin and cos as 
you have done, or by writing a large number of random numbers to a file 
(using a single random stream) and then reading the first of these numbers 
in your first frame, the second in the second and so on. Then you can 
multiply the numbers in this random sequence and use them as new seeds.

Rune
-- 
http://runevision.com

Post a reply to this message

Greg M. Johnson <pte### [at] thecommononethatstartswithycom> wrote:
> Then for some n, n<20, if I then go plot out the values of an as a function
> of frame_number when rendered, one of those values would be a straight
> line. One but surely not all. 

  Sorry, I didn't understand that.

-- 
                                                          - Warp

Post a reply to this message