On Sun, 09 Nov 2003 05:10:37 -0500, Tim Cook <z99### [at] bellsouthnet> wrote:

> I was right by way of accident in wording my formula;

By accident? No, I don't believe that.

Regards
        Stephen

Post a reply to this message

Warp wrote:

> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>> What exactly do you understand by a "proof"?
> 
>   Mathematical proof. Should be unambiguous and checkable by anyone.
> 
Then please check my proof in the other posting(s). 
It should be easy to follow. For convenience, I copy-and-paste 
it here again: 

A: VRand_On_Sphere(): surface vectors. 

The vector is rotated by a random amount around the Y axis, so it 
is sufficient to prove that the probability for the vector being 
in a certain latitude range is equal to the area covered by it 
(divided by 4pi, of course). 

The area size on a sphere between latitudes theta1 and theta2 
is (where theta is not really the latitude but measured downwards from 
the pole): 

which is


The probability for the vector to be inside that area is: 

where y=2*rand(Stream)-1, i.e. uniformly distributed, so 

(because y = r * cos(theta) and r=1 here). 

Now, the probability per area can be calculated as: 

...which is just what we expect and independent of theta1 and theta2. 

- q.e.d. 

So, it works for the sphere surface vectors. 

B: VRand_In_Sphere(), full sphere. 

For the full sphere, there is not much difference, just the 
radius is chosen to be randomly distributed using 
pow(rand(Stream),1/3)). 
I don't believe that this is right until someone (me?) proves 
it to be right - ;)

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> B: VRand_In_Sphere(), full sphere.
> 
> For the full sphere, there is not much difference, just the
> radius is chosen to be randomly distributed using
> pow(rand(Stream),1/3)).
> I don't believe that this is right until someone (me?) proves
> it to be right - ;)
> 
As shown last time, we already have a function for the uniform 
distribution on a sphere surface. For the VRand_In_Sphere() function, 
it is therefore sufficient to prove that the radius calculation 
(i.e. vector length) is correct. 

For that purpose, it must be shown that the probability for the 
vector being of a certain length range is equal to the volume 
enclosed by that radius range (divided by 4*pi/3, of course). 

The sphere volume between radii r1 and r2 (r2>r1) is: 
  V = 4*pi/3 * (r2^3 - r1^3)

The vector length l is calculated as l=a^(1/3) with a=rand(Stream), 
hence l^3 is uniformly distributed in the range 0..1. 

The probability for the vector to end in the volume V (i.e. radius 
range r1..r2) is: 
  P(vector in V) = P(r1 <= l < r2) = P(r1^3 <= l^3 < r2^3) = 
and as l^3=a:
  = P(r1^3 <= a < r2^3) = r2^3 - r1^3

Hence, the quotient (probability per volume) is: 
  P/V = 3/(4*Pi)
...which is what we want. 

- q.e.d. 

So, it works; VRand_In_Sphere() is uniformly distributed in the sphere. 

Any doubts or problems?

Wolfgang

Post a reply to this message

I vote for 'not worth'.
I'm pretty much convinced that the proposed distribution are even, but I 
agree with your arguments. And I would also add that it is better to 
have a clearly even distribution in the include file rather than a 
distribution that is very clever but not so clear, even if it's faster.

JC


Rune wrote:

> 
>>I suggest to replace the original rand.inc macros by these macros.
> 
> 
> Even if the distribution of these functions are indeed even, it should
> still be considered that some scenes made using the current macros may
> be designed to depend on their exact output, not just the distribution.
> (Just like some scenes were made to depend on the old noise_generator
> before it was changed in POV-Ray 3.5.) This means that if new macros
> with different output are introduced, backward compatible alternative
> macros must be provided as well. This however, doesn't necessarily
> prevent some users from being confused when their scenes suddenly look
> different, if they're not aware of the new macros that have replaced the
> old ones.
> 
> Now the question is: Is the 9% speed increase worth the hassle with the
> backwards compatibility issue? I'm not for or against, I just want to
> make sure that the issue is being considered.
> 
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision:  http://runevision.com **updated Sep 28**
> POV-Ray Ring: http://webring.povray.co.uk
> 
>

Post a reply to this message

"JC (Exether)" <no### [at] spamfr> wrote:
> And I would also add that it is better to 
> have a clearly even distribution in the include file rather than a 
> distribution that is very clever but not so clear, even if it's faster.

  IMHO that's irrelevant.
  The main features should be speed and ease of use. Algorithmic complexity
is irrelevant.

-- 
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

Oh boy, what a long thread ...

I've not looked at this thread for a while and I am astonished
about the many responses (and strange sidetracks ...). Next time
when I post such a thing I will provide a proof together with it,
but here it seems unneccessary now as Wolfgang did it (thanks for
that).

Because the usage of such a macro should not depend on its inner
workings, I think it is bad (or at least questionable) programming
style to rely on the specific algorithm used for the implementation.
(Remember: the macro is supposed to deliver *random* points, so
even a truly random hardware generator that never repeats the same
(long) sequence should be accepted!)
If this dependence is required, the macro should be *copied* to the
scene: this will prevent these special scenes from breaking while
leaving room for improvements for the majority of the other scenes.
(BTW: calling a copied macro is *much* faster than calling an
included macro, when it is used very often.)
Refraining from such improvements sounds to me a little bit like
"don't improve the accuracy of POV-Ray's geometric calculations,
my scene depends on the rounding errors". (O.K., don't take this
argument toooo seriously: I wrote "to me" and "a little bit" :-)

So I now suggest to use the new macros in rand.inc, but leave
the old macros as comment (or renamed to ..._Old).
Or: leave the old macros and include my macros with the suffix
"_New" or as comment ...

   Sputnik

Post a reply to this message

news:3fb30aa5$1@news.povray.org...
> Oh boy, what a long thread ...

> Because the usage of such a macro should not depend on its inner
> workings, I think it is bad (or at least questionable) programming
> style to rely on the specific algorithm used for the implementation.
> (Remember: the macro is supposed to deliver *random* points, so
> even a truly random hardware generator that never repeats the same
> (long) sequence should be accepted!)

<snip>

I think you're missing the point - when using rand in a scene I will often throw
various seeds at it until I get a distribution I like. This distrib will be
random - I'm not aiming for a particular numeric sequence - but in the interests
of a nice image some random sequences will produce better results.

Take a look at:

http://www.tomandlu.co.uk/webres/raytracing/gallery/pics/tmsummer.jpg
and
http://www.tomandlu.co.uk/webres/raytracing/gallery/pics/tmwinter.jpg

the branch distrib is undeniably random, but a different sequence will not
produce the same aesthetic effect. Now in this case I'm using plain rand + my
own algorithms, but if the supplied macros are to be taken seriously, then they
have to produce consistent results. Bug fixing is one thing, but (fairly)
arbitary changes every time a speed-increase is found is another. Much better
IMHO to provide improved macros with different names (or some sort of version
directive as suggested by others).

Post a reply to this message

O.K., now I see this point.

So my macros are good if speed is important, but
"backward compatibility" isn't (if the particular
sequence doesn't matter; and in new scenes);
otherwise the current macros will be neccessary.
Copying is better than including (in the case of
these macros): a copied macro is faster; the scene
is protected from changes in the include file.

   Sputnik

Post a reply to this message

#macro EvenSpherePoint(pos, rad, sd)
    #local irad = sqrt(min(rand(sd),0);
    #local long = rand(sd)*2*pi;
    #local hemi = select(rand(sd)-0.5, -1, 1)
    #local azim = pow(rand(sd), x)*pi*0.5;
    #local dir = <cos(azim)*cos(long), hemi*sin(azim), cos(azim)*sin(long)>;
    #local pnt = pos+dir*irad*rad;
    pnt
#end

What should x be in order to get a truly even distribution (or at least
something close)?

I set up an Excel spreadsheet comparing cos(x*2/pi) to 1-(x*x)^n
for -1<=x<=1 in steps of 0.01 and 0.002.  I calculated the sum of the
differences between the functions, essentially looking of a value of n where
the integrals of these functions were identical.  Excel came up with
0.875969064, or 1/(pi-2).  x in the phi function is double that.

"Wolfgang Wieser" <wwi### [at] gmxde> wrote in message
news:3fae530a@news.povray.org...
> Wolfgang Wieser wrote:
> > B: VRand_In_Sphere(), full sphere.
> >
> > For the full sphere, there is not much difference, just the
> > radius is chosen to be randomly distributed using
> > pow(rand(Stream),1/3)).
> > I don't believe that this is right until someone (me?) proves
> > it to be right - ;)
> >
> As shown last time, we already have a function for the uniform
> distribution on a sphere surface. For the VRand_In_Sphere() function,
> it is therefore sufficient to prove that the radius calculation
> (i.e. vector length) is correct.
>
> For that purpose, it must be shown that the probability for the
> vector being of a certain length range is equal to the volume
> enclosed by that radius range (divided by 4*pi/3, of course).
>
> The sphere volume between radii r1 and r2 (r2>r1) is:
>   V = 4*pi/3 * (r2^3 - r1^3)
>
> The vector length l is calculated as l=a^(1/3) with a=rand(Stream),
> hence l^3 is uniformly distributed in the range 0..1.
>
> The probability for the vector to end in the volume V (i.e. radius
> range r1..r2) is:
>   P(vector in V) = P(r1 <= l < r2) = P(r1^3 <= l^3 < r2^3) =
> and as l^3=a:
>   = P(r1^3 <= a < r2^3) = r2^3 - r1^3
>
> Hence, the quotient (probability per volume) is:
>   P/V = 3/(4*Pi)
> ...which is what we want.
>
> - q.e.d.
>
> So, it works; VRand_In_Sphere() is uniformly distributed in the sphere.
>
> Any doubts or problems?
>
> Wolfgang
>

Post a reply to this message

What are you trying to do? Your messages don't seem to have much to do 
with the ones they reply to. And what advantages do your versions have? 
We already have two simpler versions that are tested and pretty well 
proven to give the correct distribution.

Plus I see several errors in your code, even after syntax is corrected 
enough for the macros to parse...for example, "min(rand(sd),0)" is 
always 0. Using max() doesn't make any more sense...it would have no 
effect. "pow(rand(sd), x)" is meaningless...raising a random number to a 
power of < 1, 0, 0>? Fixing the parentheses and semicolons, removing the 
min(), and substituting 2 for x gave something that didn't even come 
close to an even spherical distribution, with either of your macros.

-- 
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