On 13 Jul 2000 16:10:38 -0400, CreeD wrote:
>So anyway.  RantRant.  Why do the randomized X points in my SOR shift back
>and forth irregularly, but never seem to leave a certain boundary no matter
>what kind of number I plug in after seed()?

Because that's not what seed() does.  Seed just gives you a different 
starting point in the list of pseudorandom numbers that rand() spits out.
Rand() always *always* returns a number between 0 and 1.  How can we rewrite
the part of the documentation that says "The numbers are uniformly 
distributed, and have values between 0.0 and 1.0, inclusively" to make
this simpler?  

It seems to me that the only thing a non-programmer would have trouble 
understanding in the definitions of seed() and rand() is the notion that
a stream is the same as a generator, as used in the paragraph that states

   Multiple random generators are very useful in situations where you use 
   rand() to place a group of objects, and then decide to use rand() in 
   another location earlier in the file to set some colors or place another 
   group of objects. Without separate rand() streams, all of your objects 
   would move when you added more calls to rand(). This is very annoying. 

Here's the best I can do at explaining rand() and seed() in a way that's 
different (but not better) than that in the manual:

Seed creates a new pseudorandom number generator.  This generator will always
provide the same sequence of numbers in the same order each time you parse the
scene file.  All the seed affects is the specific sequence of numbers returned.
It does not affect their randomness, their range, or their distribution.

Rand gives you the next number from a particular generator (created by the
Seed function.)  All numbers returned are between 0 and 1.  If you want some
other range of numbers, multiply, divide, add, or subtract until the range is 
what you need.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <01bfed07$27644560$1a1ba1d0@mk>, "CreeD" <meshe@nqi.net> 
wrote:

> You're probably right, but really, if you can be EXACTLY as clear with
> fewer and easier words, why wouldn't you? You make it sound like this was
> written by programmers, for programmers. It's not. I should be able to
> learn with 0 previous programming experience from the windows help file.  

Actually, this keyword is something called a "function". It is a 
programming feature, so it is quite logical to use programming 
terminology to describe it. It "returns" a value, meaning, the name of 
the rand function followed by a random number stream is the same as the 
next pseudo-random number from that stream. It can *not* be described as 
precisely with fewer and more common words, the special terminology is 
used to convey the exact meaning. If you refuse to learn the 
terminology, don't complain about not being able to understand it. Doing 
so is like insisting that everyone use your native language, no matter 
how awkward it makes things.


> So anyway.  RantRant.  Why do the randomized X points in my SOR shift 
> back and forth irregularly, but never seem to leave a certain 
> boundary no matter what kind of number I plug in after seed()?

Because the rand() function always returns a value between 0 and 1. The 
seed value is irrelevant, it only specifies the stream of numbers, and 
does not affect the range.

The numbers are not truely random, they are "pseudo random". This means 
that given the same starting conditions, rand() will always produce the 
same sequence of numbers. This sequence of numbers is called a "stream", 
and is initialized by the "seed()" function, which returns the stream. A 
stream produced by calling seed() with a certain number will always 
produce the same sequence of pseudo-random numbers.
The rand() function always returns values in the range 0-1. Always. The 
seed for the stream passed to it has no effect on this, changing it will 
only give a different sequence of pseudo random numbers.

Your points shift back and forth irregularly because they depend on the 
value returned by rand(). They never leave a certain range because 
rand() never leaves a certain range. The number you plug into seed() 
doesn't affect this range, because it is not supposed to.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Thanks to both who replied.

Chris -
Sorry to sound overly whiny about the documentation.  Please don't take my
comments on it personally if you had a hand in creating it.  I don't have
any particular aversion to programming terms, and I'm sure I'll pick them
up over time (or be forced to actively seek to learn them).  

	Still, I feel that the latter bit of writing that you insist is only
'different, but not better' than the documentation -IS- better.  If the
documentation is being done well, it balances 
A.The need to get the point across clearly and concisely and 
B: The writer's need to sleep.
	
	I'm not a dumb guy.  The way you explained in your most recent post got
through and the way it was explained in the documentation didn't.  That
tells me one is better than the other, even if I couldn't absolutely prove
it (or even put out a halfway decent argument as to why).  
 
  To answer your question -
if I were writing it, I'd say that seed exists only for the user to provide
POV with his own truly random starting point, and from that point POV
always extracts a random number between 0 and 1 <italics> regardless of the
seed number </italics>. 
	 Then I'd point out  (as you did), that to get random numbers larger than
1 requires addition or multiplication of the number POV returns.  I'd also
stress (as you did) that with identical conditions, the number produced is
always the same. 
	
Maybe these three points hit home immediately for everyone else but me -
shrug.

Post a reply to this message

If you want a truly random number that you want to save once you get a result
you like, you could try something like this...

#declare MySeedValue = tick_count;

#declare MySeed = seed(MySeedValue)

#declare MyRandom = rand(MySeed)

#fopen MyFile "c:\MyFile.txt" write
#write (MyFile,MySeedValue)
#fclose MyFile

That way, you can then look at MyFile so see the seed value you have used, then
to repeat the code exactly change so that...

#declare MySeedValue = 15000;

or whatever the value in MyFile was.

tick_count assumes you have MegaPov, of course.

MJL

Post a reply to this message

> If you want a truly random number that you want to save once you get a
result
> you like, you could try something like this...
> 
> #declare MySeedValue = tick_count;
> 
> #declare MySeed = seed(MySeedValue)
> 
> #declare MyRandom = rand(MySeed)
> 
> #fopen MyFile "c:\MyFile.txt" write
> #write (MyFile,MySeedValue)
> #fclose MyFile
> 
> That way, you can then look at MyFile so see the seed value you have
used, then
> to repeat the code exactly change so that...
> 
> #declare MySeedValue = 15000;
> 
> or whatever the value in MyFile was.
> 
> tick_count assumes you have MegaPov, of course.

That's a very useful tip .. I wasn't aware of #write. 
So far I've got a random vase generator that works pretty well.
If I can get it to write the seeds I used I can render the ones I like at a
decent resolution, although 5-6 minutes is bearable as it is at 512x384...
anyway, thanks much.

Post a reply to this message

Don't forget that POV will not place anything in between it's output unless you
tell it so. eg the numbers 12, 18, and 5 will appear as 12185 in your output
unless you do something like this...

#write (SeedValue1," ",SeedValue2," ")

etc. which will put spaces between them. You get the picture. Stick with the
pov manual, and constantly look it up. It really is handy. Within weeks, it'll
become your most used help file, I guarantee.

MJL

MJL

CreeD wrote:

> > If you want a truly random number that you want to save once you get a
> result
> > you like, you could try something like this...
> >
> > #declare MySeedValue = tick_count;
> >
> > #declare MySeed = seed(MySeedValue)
> >
> > #declare MyRandom = rand(MySeed)
> >
> > #fopen MyFile "c:\MyFile.txt" write
> > #write (MyFile,MySeedValue)
> > #fclose MyFile
> >
> > That way, you can then look at MyFile so see the seed value you have
> used, then
> > to repeat the code exactly change so that...
> >
> > #declare MySeedValue = 15000;
> >
> > or whatever the value in MyFile was.
> >
> > tick_count assumes you have MegaPov, of course.
>
> That's a very useful tip .. I wasn't aware of #write.
> So far I've got a random vase generator that works pretty well.
> If I can get it to write the seeds I used I can render the ones I like at a
> decent resolution, although 5-6 minutes is bearable as it is at 512x384...
> anyway, thanks much.

Post a reply to this message

Oops, I meant...

#write (MyFile,SeedValue1," ",SeedValue2," ")

sorry.

MJL

Mark James Lewin wrote:

> Don't forget that POV will not place anything in between it's output unless you
> tell it so. eg the numbers 12, 18, and 5 will appear as 12185 in your output
> unless you do something like this...
>
> #write (SeedValue1," ",SeedValue2," ")
>
> etc. which will put spaces between them. You get the picture. Stick with the
> pov manual, and constantly look it up. It really is handy. Within weeks, it'll
> become your most used help file, I guarantee.
>
> MJL
>
> MJL
>
> CreeD wrote:
>
> > > If you want a truly random number that you want to save once you get a
> > result
> > > you like, you could try something like this...
> > >
> > > #declare MySeedValue = tick_count;
> > >
> > > #declare MySeed = seed(MySeedValue)
> > >
> > > #declare MyRandom = rand(MySeed)
> > >
> > > #fopen MyFile "c:\MyFile.txt" write
> > > #write (MyFile,MySeedValue)
> > > #fclose MyFile
> > >
> > > That way, you can then look at MyFile so see the seed value you have
> > used, then
> > > to repeat the code exactly change so that...
> > >
> > > #declare MySeedValue = 15000;
> > >
> > > or whatever the value in MyFile was.
> > >
> > > tick_count assumes you have MegaPov, of course.
> >
> > That's a very useful tip .. I wasn't aware of #write.
> > So far I've got a random vase generator that works pretty well.
> > If I can get it to write the seeds I used I can render the ones I like at a
> > decent resolution, although 5-6 minutes is bearable as it is at 512x384...
> > anyway, thanks much.

Post a reply to this message

In article <01bfed13$18efe640$1a1ba1d0@mk>, "CreeD" <meshe@nqi.net> 
wrote:

> Sorry to sound overly whiny about the documentation.  Please don't 
> take my comments on it personally if you had a hand in creating it.  

Don't worry, I wasn't taking it personally...and this portion of the 
documentation probably existed long before I had ever heard of POV.


> I don't have any particular aversion to programming terms, and I'm 
> sure I'll pick them up over time (or be forced to actively seek to 
> learn them).  
> 
> 	Still, I feel that the latter bit of writing that you insist is only
> 'different, but not better' than the documentation -IS- better.  If the
> documentation is being done well, it balances 
> A.The need to get the point across clearly and concisely and 
> B: The writer's need to sleep.

Actually, I thought my description was repetitive, a bit imprecise in 
areas, as well as very long-winded, and highly redundant in areas(almost 
as redundant as the adjectives I am using to describe it in this 
sentence). :-)
If I really wanted to explain this at such a basic level, I would draw 
pictures and make an HTML document...and if this was done for the whole 
manual...

Anyway...when you are looking for this kind of information, and you know 
the terminology, this kind of long-winded explanation is a burden, not a 
help. Imagine having to wade through pages of useless information to 
find one little piece of information ("The numbers are uniformly 
distributed, and have values between 0.0  and 1.0, inclusively.", for 
example). My bit of writing might have been better for a dedicated 
tutorial, but this is a basic language reference.

For the people who need help understanding this type of thing, there is 
all the information you need on these newsgroups, in sample scenes, or 
on the web. You just have to listen, and try to understand the 
terminology...most of it is quite logical once you understand *why* a 
term is used. It isn't some magical capability you are born with or need 
to study books to learn. (Though books can help...unfortunately, I can't 
afford many. :-( )

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

"Mark James Lewin" <m_j### [at] yahoocomau> wrote in message
news:396EAF98.82C6834B@yahoo.com.au...
| Oops, I meant...
|
| #write (MyFile,SeedValue1," ",SeedValue2," ")
|
| sorry.

Spaces won't work (I don't think so anyway), you need commas inside those quotes.  The
way POV will
use #read when you are wanting the data back from the file is to delimit (separate)
based on the
commas.  You still need to use those commas you already show there though to separate
the
parameters too.

Bob

Post a reply to this message

I know (I ran into the trouble of non delimited input files when I first started using
POV). But pov
can _write_ spaces, and if you are just generating rands until you get one (or
several) you like,
copy...paste, is easier that #fopen...#read...#fclose. Spaces will let you know when
one number ends
and the next begins.

MJL

Bob Hughes wrote:

> "Mark James Lewin" <m_j### [at] yahoocomau> wrote in message
news:396EAF98.82C6834B@yahoo.com.au...
> | Oops, I meant...
> |
> | #write (MyFile,SeedValue1," ",SeedValue2," ")
> |
> | sorry.
>
> Spaces won't work (I don't think so anyway), you need commas inside those quotes. 
The way POV will
> use #read when you are wanting the data back from the file is to delimit (separate)
based on the
> commas.  You still need to use those commas you already show there though to
separate the
> parameters too.
>
> Bob

Post a reply to this message