Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #144155 > unrolled thread

quick & easy random dir vector, how?

Back to article view | Back to comp.lang.c

Contents

  quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-30 13:47 -0700
    Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-05-30 13:56 -0700
      Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 02:08 +0100
        Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 00:51 -0700
        Re: quick & easy random dir vector, how? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-05-31 02:12 -0700
          Re: quick & easy random dir vector, how? Eli the Bearded <*@eli.users.panix.com> - 2019-05-31 19:27 +0000
            Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 12:49 -0700
              Re: quick & easy random dir vector, how? Eli the Bearded <*@eli.users.panix.com> - 2019-05-31 20:36 +0000
                Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 14:00 -0700
                  Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 14:19 -0700
        Re: quick & easy random dir vector, how? mark.bluemel@gmail.com - 2019-05-31 03:56 -0700
          Re: quick & easy random dir vector, how? queequeg@trust.no1 (Queequeg) - 2019-05-31 11:57 +0000
          Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 15:22 +0100
            Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 07:42 -0700
              Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 08:25 -0700
        Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-05-31 05:20 -0700
          Re: quick & easy random dir vector, how? Bart <bc@freeuk.com> - 2019-05-31 13:39 +0100
            Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 15:51 +0100
            Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-03 08:26 -0400
          Re: quick & easy random dir vector, how? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-05-31 05:54 -0700
            Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-05-31 06:15 -0700
              Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 06:23 -0700
              Re: quick & easy random dir vector, how? David Brown <david.brown@hesbynett.no> - 2019-05-31 16:12 +0200
                Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-05-31 08:14 -0700
                  Re: quick & easy random dir vector, how? David Brown <david.brown@hesbynett.no> - 2019-05-31 18:18 +0200
                  Rick should killfile everybody. (Was: quick & easy random dir vector, how?) gazelle@shell.xmission.com (Kenny McCormack) - 2019-05-31 17:39 +0000
                    Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-05-31 10:55 -0700
                      Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?) Bart <bc@freeuk.com> - 2019-05-31 22:33 +0100
                        Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?) Keith Thompson <kst-u@mib.org> - 2019-05-31 16:26 -0700
                          Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?) gazelle@shell.xmission.com (Kenny McCormack) - 2019-05-31 23:29 +0000
                        Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?) gazelle@shell.xmission.com (Kenny McCormack) - 2019-05-31 23:28 +0000
                  Re: quick & easy random dir vector, how? waterwitch86@gmail.com - 2019-06-09 03:47 -0700
              Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 15:43 +0100
                Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-05-31 08:13 -0700
                  Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 22:49 +0100
              Re: quick & easy random dir vector, how? Richard Damon <Richard@Damon-Family.org> - 2019-05-31 23:01 -0400
                Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-01 04:10 -0700
                  Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-01 13:47 +0100
                    Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-01 12:04 -0700
                      Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-01 12:35 -0700
                        Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-01 12:53 -0700
                      Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-01 14:52 -0700
                        Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-01 15:04 -0700
                          Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-01 15:41 -0700
              Re: quick & easy random dir vector, how? Anton Shepelev <anton.txt@gmail.com> - 2019-06-01 15:30 +0300
                Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-03 05:30 -0700
                  Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-03 05:39 -0700
                    Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-03 15:17 +0100
                      Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-03 07:32 -0700
                        Re: quick & easy random dir vector, how? David Brown <david.brown@hesbynett.no> - 2019-06-03 18:09 +0200
                        Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-03 21:14 +0100
                          Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-03 13:18 -0700
                            Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-03 22:42 +0100
                              Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-03 16:21 -0700
                        Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-03 15:40 -0700
                          Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-04 05:19 -0700
                            Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-04 16:31 +0100
                              Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-04 11:48 -0400
                                Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-04 21:09 -0700
                                  Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-04 21:11 -0700
                                Re: quick & easy random dir vector, how? jadill33@gmail.com - 2019-06-05 12:41 -0700
                                  Re: quick & easy random dir vector, how? jadill33@gmail.com - 2019-06-05 12:46 -0700
                                  Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-05 13:53 -0700
                                    Re: quick & easy random dir vector, how? Eli the Bearded <*@eli.users.panix.com> - 2019-06-05 21:45 +0000
                                      Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-05 23:06 -0700
                                        Re: quick & easy random dir vector, how? Eli the Bearded <*@eli.users.panix.com> - 2019-06-06 06:47 +0000
                                          Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-06 18:32 -0700
                                            Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-06 18:44 -0700
                              Re: quick & easy random dir vector, how? richard@cogsci.ed.ac.uk (Richard Tobin) - 2019-06-05 13:43 +0000
                                Re: quick & easy random dir vector, how? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-05 07:24 -0700
                                  Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-05 13:29 -0700
                                Re: quick & easy random dir vector, how? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-05 08:05 -0700
                            Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 19:01 -0700
                            Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-06 22:57 -0400
                          Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-06 09:14 -0400
                            Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-06 08:10 -0700
                            Re: quick & easy random dir vector, how? "F. Russell" <fr@random.info> - 2019-06-06 16:17 +0000
                              Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-06 20:18 -0400
                                Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-06 23:22 -0700
                                  Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-07 07:15 -0700
                                Re: quick & easy random dir vector, how? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-07 00:41 -0700
                            Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-09 13:57 -0700
                              Re: quick & easy random dir vector, how? Richard Damon <Richard@Damon-Family.org> - 2019-06-10 08:18 -0400
                                Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-10 08:49 -0400
                                  Re: quick & easy random dir vector, how? Richard Damon <Richard@Damon-Family.org> - 2019-06-10 20:59 -0400
                                    Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-10 18:27 -0700
                                Rick is a Marine!!! (Was: quick & easy random dir vector, how?) gazelle@shell.xmission.com (Kenny McCormack) - 2019-06-10 13:53 +0000
                                  Re: Rick is a Marine!!! (Was: quick & easy random dir vector, how?) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-10 09:14 -0700
                              Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-10 07:24 -0700
              Re: quick & easy random dir vector, how? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-03 08:30 -0400
            Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 06:21 -0700
              Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 06:26 -0700
                Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 06:33 -0700
                  Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 07:00 -0700
                    Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 07:14 -0700
                      Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 10:15 -0700
                        Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 10:40 -0700
                          Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 14:01 -0700
              Re: quick & easy random dir vector, how? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-05-31 07:07 -0700
                Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 07:15 -0700
    Re: quick & easy random dir vector, how? Anton Shepelev <anton.txt@gmail.com> - 2019-06-01 00:40 +0300
      Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-05-31 14:54 -0700
      Re: quick & easy random dir vector, how? Clifford Heath <no.spam@please.net> - 2019-06-02 23:00 +1000
        Re: quick & easy random dir vector, how? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-03 00:00 -0700
          Re: quick & easy random dir vector, how? Clifford Heath <no.spam@please.net> - 2019-06-03 17:33 +1000
            Re: quick & easy random dir vector, how? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-03 00:55 -0700
            Re: quick & easy random dir vector, how? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-04 10:00 -0700
    Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-01 18:34 -0700
      Re: quick & easy random dir vector, how? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-02 03:13 +0100
        Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-01 21:47 -0700
      Re: quick & easy random dir vector, how? Anton Shepelev <anton.txt@gmail.com> - 2019-06-02 13:16 +0300
        Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-02 05:38 -0700
          Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-02 05:54 -0700
            Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-02 06:08 -0700
              Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-02 06:24 -0700
                Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-02 06:34 -0700
                Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-02 06:43 -0700
                  Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-02 07:06 -0700
                    Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-02 13:12 -0700
                Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-02 06:58 -0700
                  Re: quick & easy random dir vector, how? gazelle@shell.xmission.com (Kenny McCormack) - 2019-06-02 14:08 +0000
                  Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-02 21:56 -0700
                    Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-02 21:56 -0700
                    Re: quick & easy random dir vector, how? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-06-03 02:47 -0700
                      Re: quick & easy random dir vector, how? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-06-07 01:32 -0700
    Re: quick & easy random dir vector, how? "F. Russell" <frussell@random.info> - 2019-06-03 12:33 +0000
      Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-03 07:36 -0700
        Re: quick & easy random dir vector, how? "F. Russell" <frussell@random.info> - 2019-06-03 14:46 +0000
          Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-03 08:13 -0700
        Re: quick & easy random dir vector, how? fir <profesor.fir@gmail.com> - 2019-06-03 07:51 -0700

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#144494

On Tuesday, June 4, 2019 at 11:46:16 AM UTC-4, Rick C. Hodgin wrote:
> On 6/4/2019 11:31 AM, Ben Bacarisse wrote:
> >> By choosing a random point around the unit circle on the ZX, XY,
> >> YZ planes I obtain three angles which give me three points.  Each
> >> of those points is at a random location around the unit circle in
> >> its plane.  It would address all of the points in the set of points
> >> that are the unit sphere's surface.
> > 
> > The points your posted code picks are not all on the sphere.  You need
> > to normalise these vectors too, and the result is very much not a
> > uniform distribution.  You are correct that every point on the sphere
> > (AKA direction) has non-zero probability (i.e. could be picked) but
> > there are much simpler ways to do that (and with less bias).
> 
> I have no doubts that you and James are correct, and that my beliefs
> here are wrong, but I have a hard time visualizing it through words.
> 
> If there's a graphic or video I can see it may help.
> 
> > In spherical polar coordinates, only two angles are needed to specify a
> > point on the unit sphere, so the third one is odd.  Taking the sin of
> > each is even odder.  What method are you thinking of to combine the
> > three uniformly chosen angle into a point on the sphere?
> 
> To obtain independent X, Y, Z values on their planes.  Each unit
> circle will project a random point uniformly around resulting in
> a random point on the unit sphere when projected.
> 
> >> I'd have to see how it would be skewed visually to wrap my mind
> >> around it.
> > 
> > You have a method in mind, but I don't know what it is.  I can show you
> > the distribution you get taking the sin of the three angles, but I don't
> > think that's really what you mean.  If you post an actual algorithm, I
> > can show the distribution.
> 
> It's probably wrong.  I can't visualize it so it's hard for me to
> work in those terms.

Maybe you can visualize it if you take graph paper, create a circle
and square with the same radius (make it large on graph paper), then for
mini square on the graph paper on the border of the square, draw a straight
line from that point to the center of the sphere using a ruler.  Start
from the middle where the square and the circle intersect and move towards
the corner.

You should notice (if you make the circle and square large enough) that as
your samples along the square approach the corners, the angles between
lines intersecting the circle between points on the interior circle get
smaller (closer together) than when starting where the square and circle
intersect.

That clustering effect means that samples of your uniformly distributed
random variables along the three cartesian axes outside the sphere
introduce bias into the distribution of direction vectors, which means that
this method will not create a random but not uniform distribution of
direction vectors.

Does that help?

Best regards,
John D.

[toc] | [prev] | [next] | [standalone]

#144495

On Wednesday, June 5, 2019 at 3:42:05 PM UTC-4, jadi...@gmail.com wrote:
> On Tuesday, June 4, 2019 at 11:46:16 AM UTC-4, Rick C. Hodgin wrote:
> > On 6/4/2019 11:31 AM, Ben Bacarisse wrote:
> > >> By choosing a random point around the unit circle on the ZX, XY,
> > >> YZ planes I obtain three angles which give me three points.  Each
> > >> of those points is at a random location around the unit circle in
> > >> its plane.  It would address all of the points in the set of points
> > >> that are the unit sphere's surface.
> > > 
> > > The points your posted code picks are not all on the sphere.  You need
> > > to normalise these vectors too, and the result is very much not a
> > > uniform distribution.  You are correct that every point on the sphere
> > > (AKA direction) has non-zero probability (i.e. could be picked) but
> > > there are much simpler ways to do that (and with less bias).
> > 
> > I have no doubts that you and James are correct, and that my beliefs
> > here are wrong, but I have a hard time visualizing it through words.
> > 
> > If there's a graphic or video I can see it may help.
> > 
> > > In spherical polar coordinates, only two angles are needed to specify a
> > > point on the unit sphere, so the third one is odd.  Taking the sin of
> > > each is even odder.  What method are you thinking of to combine the
> > > three uniformly chosen angle into a point on the sphere?
> > 
> > To obtain independent X, Y, Z values on their planes.  Each unit
> > circle will project a random point uniformly around resulting in
> > a random point on the unit sphere when projected.
> > 
> > >> I'd have to see how it would be skewed visually to wrap my mind
> > >> around it.
> > > 
> > > You have a method in mind, but I don't know what it is.  I can show you
> > > the distribution you get taking the sin of the three angles, but I don't
> > > think that's really what you mean.  If you post an actual algorithm, I
> > > can show the distribution.
> > 
> > It's probably wrong.  I can't visualize it so it's hard for me to
> > work in those terms.
> 
> Maybe you can visualize it if you take graph paper, create a circle
> and square with the same radius (make it large on graph paper), then for
> mini square on the graph paper on the border of the square, draw a straight
> line from that point to the center of the sphere using a ruler.  Start
> from the middle where the square and the circle intersect and move towards
> the corner.
> 
> You should notice (if you make the circle and square large enough) that as
> your samples along the square approach the corners, the angles between
> lines intersecting the circle between points on the interior circle get
> smaller (closer together) than when starting where the square and circle
> intersect.
> 
> That clustering effect means that samples of your uniformly distributed
> random variables along the three cartesian axes outside the sphere
> introduce bias into the distribution of direction vectors, which means that
> this method will not create a random but not uniform distribution of
> direction vectors.

Should read "this method will create a random but not uniform distribution
of direction vectors".

> Does that help?

[toc] | [prev] | [next] | [standalone]

#144500

On 6/5/2019 12:41 PM, jadill33@gmail.com wrote:
> On Tuesday, June 4, 2019 at 11:46:16 AM UTC-4, Rick C. Hodgin wrote:
>> On 6/4/2019 11:31 AM, Ben Bacarisse wrote:
>>>> By choosing a random point around the unit circle on the ZX, XY,
>>>> YZ planes I obtain three angles which give me three points.  Each
>>>> of those points is at a random location around the unit circle in
>>>> its plane.  It would address all of the points in the set of points
>>>> that are the unit sphere's surface.
>>>
>>> The points your posted code picks are not all on the sphere.  You need
>>> to normalise these vectors too, and the result is very much not a
>>> uniform distribution.  You are correct that every point on the sphere
>>> (AKA direction) has non-zero probability (i.e. could be picked) but
>>> there are much simpler ways to do that (and with less bias).
>>
>> I have no doubts that you and James are correct, and that my beliefs
>> here are wrong, but I have a hard time visualizing it through words.
>>
>> If there's a graphic or video I can see it may help.
>>
>>> In spherical polar coordinates, only two angles are needed to specify a
>>> point on the unit sphere, so the third one is odd.  Taking the sin of
>>> each is even odder.  What method are you thinking of to combine the
>>> three uniformly chosen angle into a point on the sphere?
>>
>> To obtain independent X, Y, Z values on their planes.  Each unit
>> circle will project a random point uniformly around resulting in
>> a random point on the unit sphere when projected.
>>
>>>> I'd have to see how it would be skewed visually to wrap my mind
>>>> around it.
>>>
>>> You have a method in mind, but I don't know what it is.  I can show you
>>> the distribution you get taking the sin of the three angles, but I don't
>>> think that's really what you mean.  If you post an actual algorithm, I
>>> can show the distribution.
>>
>> It's probably wrong.  I can't visualize it so it's hard for me to
>> work in those terms.
> 
> Maybe you can visualize it if you take graph paper, create a circle
> and square with the same radius (make it large on graph paper), then for
> mini square on the graph paper on the border of the square, draw a straight
> line from that point to the center of the sphere using a ruler.  Start
> from the middle where the square and the circle intersect and move towards
> the corner.
> 
> You should notice (if you make the circle and square large enough) that as
> your samples along the square approach the corners, 

Agreed.

For what its worth, for Rick: Here is an interactive vector field based 
DLA algorihtm I created that uses a parametric square for the particle 
launching points. My Javascript should work on many browsers, here is a 
link:

http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test

Let it run for a little while, and you should see the bias form wrt the 
growth tending to go to the corners of the square first. This happens in 
the cube as well. For what its worth, one can dynamically add new DLA 
seed points by clicking on the screen.

Does that help Rick?



> the angles between
> lines intersecting the circle between points on the interior circle get
> smaller (closer together) than when starting where the square and circle
> intersect.
> 
> That clustering effect means that samples of your uniformly distributed
> random variables along the three cartesian axes outside the sphere
> introduce bias into the distribution of direction vectors, which means that
> this method will not create a random but not uniform distribution of
> direction vectors.
> 
> Does that help?

[toc] | [prev] | [next] | [standalone]

#144502

In comp.lang.c,
Chris M. Thomasson <invalid_chris_thomasson_invalid@invalid.com> wrote:
> For what its worth, for Rick: Here is an interactive vector field based 
> DLA algorihtm I created that uses a parametric square for the particle 
> launching points. My Javascript should work on many browsers, here is a 
> link:
> 
> http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test
> 
> Let it run for a little while, and you should see the bias form wrt the 
> growth tending to go to the corners of the square first. This happens in 
> the cube as well. For what its worth, one can dynamically add new DLA 
> seed points by clicking on the screen.
> 
> Does that help Rick?

I'm not Rick, but it confirms the bias I suspected when people first
mentioned that here. Also, it's a really pretty demo. Thanks for doing
that.

Elijah
------
did not expect the tree-like design to emerge

[toc] | [prev] | [next] | [standalone]

#144515

On 6/5/2019 2:45 PM, Eli the Bearded wrote:
> In comp.lang.c,
> Chris M. Thomasson <invalid_chris_thomasson_invalid@invalid.com> wrote:
>> For what its worth, for Rick: Here is an interactive vector field based
>> DLA algorihtm I created that uses a parametric square for the particle
>> launching points. My Javascript should work on many browsers, here is a
>> link:
>>
>> http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test
>>
>> Let it run for a little while, and you should see the bias form wrt the
>> growth tending to go to the corners of the square first. This happens in
>> the cube as well. For what its worth, one can dynamically add new DLA
>> seed points by clicking on the screen.
>>
>> Does that help Rick?
> 
> I'm not Rick, but it confirms the bias I suspected when people first
> mentioned that here. Also, it's a really pretty demo. Thanks for doing
> that.

Ahhhh. Thank you very much for taking the time to give my experimental 
code a go Elijah. I really do appreciate it. Imvvho, it sure does seem 
to expose the bias quite nicely. The dynamic non-intersecting tree, 
without adding any artificial points, grows to the biased directions, so 
to speak. Try to click some points to attract the particles away from 
the corners... It is fun, well to me at least... ;^)

[snip sig]
> did not expect the tree-like design to emerge
> 

Well, this can be a lot more ordered. The code as-is shows the corners 
of the parametric square basically stealing particles from the middle of 
the lines connecting them. The DLA growth _really_ shows this off. I 
agree with you. Thanks again. :^)

Now, this can go in 3d, this is bound to z-axis 0 prevent the vectors 
from going in 3d, it is like a slice of a higher-dimensional object... 
The following vector field core code of mine can extend into Nd actually...:

http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test/ct_field.js


I have some 3d renderings up on the Facebook. Are you a member of that 
thing?

[toc] | [prev] | [next] | [standalone]

#144516

In comp.lang.c,
Chris M. Thomasson <invalid_chris_thomasson_invalid@invalid.com> wrote:
[quoting me]
>> did not expect the tree-like design to emerge
> Well, this can be a lot more ordered. The code as-is shows the corners 
> of the parametric square basically stealing particles from the middle of 
> the lines connecting them. The DLA growth _really_ shows this off. I 
> agree with you. Thanks again. :^)

I tinkered with the code a bit, changing parameters. When you call
build_walkers() with a huge number of walkers at once (say, n=500), you
see curves form, like pairs of parenthesis on the diagonals. 

I think regular insertions of single "walkers" rather than batches would
probably be more interesting, but didn't feel like modifing javascript
that much.

Elijah
------
but thinking about doing some more personal graphics programming now

[toc] | [prev] | [next] | [standalone]

#144557

On 6/5/2019 11:47 PM, Eli the Bearded wrote:
> In comp.lang.c,
> Chris M. Thomasson <invalid_chris_thomasson_invalid@invalid.com> wrote:
> [quoting me]
>>> did not expect the tree-like design to emerge
>> Well, this can be a lot more ordered. The code as-is shows the corners
>> of the parametric square basically stealing particles from the middle of
>> the lines connecting them. The DLA growth _really_ shows this off. I
>> agree with you. Thanks again. :^)
> 
> I tinkered with the code a bit, changing parameters. When you call
> build_walkers() with a huge number of walkers at once (say, n=500), you
> see curves form, like pairs of parenthesis on the diagonals.
> 
> I think regular insertions of single "walkers" rather than batches would
> probably be more interesting, but didn't feel like modifing javascript
> that much.

Humm... A single "walker", or "particle" at a time, if you will. 
Humm... I can see that as being more interesting. I am working on a 3d 
version. This DLA is different than the average bear... There is no 
random walk. Each "walker" is directed to the target wrt the vector 
field as a whole. Here is some older work of mine. Imagine each line as 
a DLA walkers "path":

http://funwithfractals.atspace.cc/ct_gfield_test/ct_3dgfield_anime_test/

Also, here is a 2d to 3d DLA experiment:

https://youtu.be/AJlgxwdtHp4

A multi-layered thing, that creates a 3d grid environment.



> 
> Elijah
> ------
> but thinking about doing some more personal graphics programming now
> 

Nice! I am looking forward to your mathematical visualizations.

[toc] | [prev] | [next] | [standalone]

#144558

On 6/6/2019 6:32 PM, Chris M. Thomasson wrote:
> On 6/5/2019 11:47 PM, Eli the Bearded wrote:
>> In comp.lang.c,
>> Chris M. Thomasson <invalid_chris_thomasson_invalid@invalid.com> wrote:
[...]
>> Elijah
>> ------
>> but thinking about doing some more personal graphics programming now
>>
> 
> Nice! I am looking forward to your mathematical visualizations.

In time.... If you don't mind post a rendering of your personal work... 
Well, I would love to take a look at it. :^)

[toc] | [prev] | [next] | [standalone]

#144473

In article <87r2891i5d.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:

>> I will say this with regard to my solution... as I see it, I'm
>> trying to get random values on the surface of a sphere.
>
>That's easy.  Pick x, y and z in [-1, 1] and normalise.  You don't get a
>uniform distribution though.

Pick x, y and z in [-1, 1].  If they're outside the unit sphere, try
again until they are inside - this will take 2 x 3 / pi attempts
average.  You now have a point with uniform distribution within the
unit sphere.  Normalize to get a point on the surface.

Apologies if this has already been suggested - I haven't read the
whole thread.  And it's not particularly efficient.

-- Richard

[toc] | [prev] | [next] | [standalone]

#144480

On Wednesday, 5 June 2019 14:45:08 UTC+1, Richard Tobin  wrote:
> In article <87r2891i5d.fsf@bsb.me.uk>,
> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
> 
> >> I will say this with regard to my solution... as I see it, I'm
> >> trying to get random values on the surface of a sphere.
> >
> >That's easy.  Pick x, y and z in [-1, 1] and normalise.  You don't get a
> >uniform distribution though.
> 
> Pick x, y and z in [-1, 1].  If they're outside the unit sphere, try
> again until they are inside - this will take 2 x 3 / pi attempts
> average.  You now have a point with uniform distribution within the
> unit sphere.  Normalize to get a point on the surface.
> 
> Apologies if this has already been suggested - I haven't read the
> whole thread.  And it's not particularly efficient.
> 
I suggested it. The method works steadily less and less well as you
add dimensions. But for 3 dimensions it's still very much OK, depending
on how fast your uniform() random number function is relative to 
your asin() for correcting elevation bunching, which is the other
obvious method.

 

[toc] | [prev] | [next] | [standalone]

#144498

W dniu środa, 5 czerwca 2019 16:24:54 UTC+2 użytkownik Malcolm McLean napisał:
> On Wednesday, 5 June 2019 14:45:08 UTC+1, Richard Tobin  wrote:
> > In article <87r2891i5d.fsf@bsb.me.uk>,
> > Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
> > 
> > >> I will say this with regard to my solution... as I see it, I'm
> > >> trying to get random values on the surface of a sphere.
> > >
> > >That's easy.  Pick x, y and z in [-1, 1] and normalise.  You don't get a
> > >uniform distribution though.
> > 
> > Pick x, y and z in [-1, 1].  If they're outside the unit sphere, try
> > again until they are inside - this will take 2 x 3 / pi attempts
> > average.  You now have a point with uniform distribution within the
> > unit sphere.  Normalize to get a point on the surface.
> > 
> > Apologies if this has already been suggested - I haven't read the
> > whole thread.  And it's not particularly efficient.
> > 
> I suggested it. The method works steadily less and less well as you
> add dimensions. But for 3 dimensions it's still very much OK, depending
> on how fast your uniform() random number function is relative to 
> your asin() for correcting elevation bunching, which is the other
> obvious method.

honestly this was not helpful (at least in not strict merithorical sense) as thsi method along with thiose by angler angles
i meant as thiose default ones and asked something better then that

this one from gsl-library gives 90 ns per 1M so its best from thiose mentioned
(i not not drawed it to se if its accurate (*alright checked its ok))


float3 GiveRandomDir3d_5()
{
   float3 dir;
   float length_sqare;

   do
   {
     dir.x = -1.0 + 2.0*RandFloatTill1();
     dir.y = -1.0 + 2.0*RandFloatTill1();

     length_sqare = dir.x*dir.x + dir.y*dir.y ;
   }
   while( length_sqare>1.0 );


   dir.z = -1.0 + 2.0 * length_sqare;

   float b = 2.0 * sqrt (1.0 - length_sqare);

   dir.x*=b;
   dir.y*=b;

   return dir;

}

possibly that one form math forum, i mean

inline float3 GiveRandomDir3d_4()
{
   float3 dir;

   float a = 360.*RandFloatBelow1()*degree360;
   float z = -1.0 + 2.0*RandFloatTill1();

   float s = sqrt(1.- z*z);

   dir.x = s * cos(a);
   dir.y = s * sin(a);
   dir.z = z;

   return dir;
}

would be faster if used tables for sin cos, without this its deadly slow though (300 ms per 1 M)

[toc] | [prev] | [next] | [standalone]

#144484

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

> In article <87r2891i5d.fsf@bsb.me.uk>,
> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>
>>> I will say this with regard to my solution... as I see it, I'm
>>> trying to get random values on the surface of a sphere.
>>
>> That's easy.  Pick x, y and z in [-1, 1] and normalise.  You don't get a
>> uniform distribution though.
>
> Pick x, y and z in [-1, 1].  If they're outside the unit sphere, try
> again until they are inside - this will take 2 x 3 / pi attempts
> average.  You now have a point with uniform distribution within the
> unit sphere.  Normalize to get a point on the surface.

Slight refinement, assuming a 64-bit integer RNG is used:  generate
one 64-bit random number, divide into three 21-bit values mapped to
the range [-1048575,1048575] (discarding samples that would produce
the value -1048576), testing x*x + y*y + z*z <= 1048575*1048575.
When the test passes normalize appropriately.

> Apologies if this has already been suggested - I haven't read the
> whole thread.  And it's not particularly efficient.

But probably more efficient than a "more direct" method using trig
functions, especially since the rejection tests can be done using
integer-only calculations.

[toc] | [prev] | [next] | [standalone]

#144447

On Tuesday, June 4, 2019 at 8:20:06 AM UTC-4, Rick C. Hodgin wrote:
> On Monday, June 3, 2019 at 6:40:46 PM UTC-4, James Kuyper wrote:
> > On Monday, June 3, 2019 at 10:32:32 AM UTC-4, Rick C. Hodgin wrote:
> > > Use that function for each angle.  You have three angles to work
> > > with on a sphere, one on the XY plane, one on the XZ plane, and
> > > one on the YZ plane:
> > > 
> > >     double x = get_random_value();
> > >     double y = get_random_value();
> > >     double z = get_random_value();
> > > 
> > > These all exist somewhere between -1.0 and 1.0, and were projected
> > > evenly by choosing an angle around the circle to obtain the coord-
> > > inate to use for each axes.
> > 
> > What you're referring to are not angles - they are conventionally
> > called direction cosines, being equal to the cosine of the
> > corresponding angle. You're onto something by considering them,
> > but the direction cosines are not independent of each other: they
> > have a constraint that x^2+y^2+z^2 == 1.0. For a spherically
> > symmetric distribution of directions, the direction cosine for
> > the x axis, considered on it's own, would have a distribution
> > proportional to sqrt(1-x^2), which x = sin(theta) will produce;
> 
> This is where you lose me.  I don't know enough about what you're
> saying to know what questions to ask here.  Is there a video or
> animated GIF example or something you can point me to so I can
> see what you're talking about?

I don't know of any, sorry.

...
> I'd have to see how it would be skewed visually to wrap my mind
> around it.

The easiest way to visualize the skewing would be to generate a scatter
plot of a large number of latitude/longitude pairs using an equal-area
projection. Any non-uniformity will show up in a tendency of those
points to cluster together in some regions, and to avoid other regions.

I have a preference for cylindrical equal-area projections, which have
the following projection formulas:

    u = R*(longitude - center_longitude)*cos(standard_latitude);
    v = R*sin(latitude)/cos(standard_latitude);

u and v are the coordinates of the projected map. longitude and latitude
are in radians. center_longitude is the longitude that will be projected
onto the v axis - for convenience, set it to 0.0. standard_latitude and
-standard_latitude are the two latitudes where the mapping is exactly
conformal, and where the scale in the u direction is exactly the same as
the scale in the v direction. R is a scaling factor - if you set it to
the radius of the Earth, then any region on the surface of the earth
will get mapped to an region in the projection that has the same area.
You should choose value for R that makes the projection a good fit to
your display screen - which will probably be a smaller value. :-)

In particular, I like the Behrmann projection
<https://en.wikipedia.org/wiki/Behrmann_projection>, where
standard_latitude is pi/6.0 radians (=30 degrees), which means that it
is projected to a location exactly halfway between the equator and the
poles. As a result, a large fraction of the entire map is almost
conformal. But that's not very important in this context - the only
thing that matters is that the map projection is equal-area.

Given how confused you were by my previous explanation, I doubt that you
have the mathematical background needed to understand why your method
produces an uneven distribution. However, you should at least be able to
look at this scatter plot and confirm that it is significantly uneven.

I also like azimuthal equal-area projections, but the formulas are a bit
more complicated, and they make less efficient use of rectangular
display screens.

[toc] | [prev] | [next] | [standalone]

#144560

On Tuesday, June 4, 2019 at 8:20:06 AM UTC-4, Rick C. Hodgin wrote:
> On Monday, June 3, 2019 at 6:40:46 PM UTC-4, James Kuyper wrote:
> > On Monday, June 3, 2019 at 10:32:32 AM UTC-4, Rick C. Hodgin wrote:
> > > Use that function for each angle.  You have three angles to work
> > > with on a sphere, one on the XY plane, one on the XZ plane, and
> > > one on the YZ plane:
> > > 
> > >     double x = get_random_value();
> > >     double y = get_random_value();
> > >     double z = get_random_value();
> > > 
> > > These all exist somewhere between -1.0 and 1.0, and were projected
> > > evenly by choosing an angle around the circle to obtain the coord-
> > > inate to use for each axes.
> > 
> > What you're referring to are not angles - they are conventionally
> > called direction cosines, being equal to the cosine of the
> > corresponding angle. You're onto something by considering them,
> > but the direction cosines are not independent of each other: they
> > have a constraint that x^2+y^2+z^2 == 1.0. For a spherically
> > symmetric distribution of directions, the direction cosine for
> > the x axis, considered on it's own, would have a distribution
> > proportional to sqrt(1-x^2), which x = sin(theta) will produce;
> 
> This is where you lose me.  I don't know enough about what you're
> saying to know what questions to ask here.  Is there a video or
> animated GIF example or something you can point me to so I can
> see what you're talking about?

Here's a simple program to demonstrate the bias present in both of your
suggestions.
Note: drand48() is declared in <stdlib.h> if I compile with
-D_XOPEN_SOURCE. If you don't have access to drand48(), you can replace
it with any other function that returns random floating point numbers
uniformly distributed over the range (0.0, 1.0).

You can choose any values you want for COLS and ROWS. Having ROWS
approximately equal to COLS*4.0/(3.0*PI) makes this approximately a
Behrmann projection, but all that matters is that it be an equal area
projection, and it will be that for any values of COLS and ROWS.

As I recall, you insist on using C90, so you'll have to convert my //
comments into /* */ comments.

===================================================
#include <errno.h>
#include <math.h>
#include <stdio.h>
#include <stdlib.h>

#define COLS 360	// longitude resolution: 1 degree
#define ROWS 152	// Approximately COLS*4.0/(3.0*pi): Behrmann projection
const double lonscale = COLS/(2.0*M_PI);
const double latscale = ROWS/2.0;

static void collect_counts(
    double(*func)(void),	// returns value in range (-1.0,1.0)
    const char filename[]	// Name of output file
){
    unsigned char counts[ROWS][COLS] = {0.0};
    long count=0;

    FILE *outfile = fopen(filename, "w");
    if(outfile == NULL)
    {
	fprintf(stderr, "fopen(\"%s\", \"w\") failed.\n", filename);
	return;
    }

    while(1)
    {
	// Generate random vector in cube of length 2 centered at origin
	double x = func();
	double y = func();
	double z = func();

	// Calculate equal-area cylindrical
        // map coordinates
	double lon = atan2(x,y);
	double sinlat = z/sqrt(x*x + y*y + z*z);

	// Determine which bin to increment.
	int col = floor(lonscale*(M_PI + lon));
	int row = floor(latscale*(1.0 + sinlat));

	if(counts[row][col] == 255)
	   break;
        counts[row][col]++;
	count++;
    }

    fwrite(counts, ROWS, COLS, outfile);
    if(ferror(outfile))
    {
	if(errno)
	    perror(filename);
	else
	    fprintf(stderr, "fwrite(\"%s\", \"w\")"
               "failed.\n", filename);
	return;
    }
    if(fclose(outfile))
    {
	fprintf(stderr, "fclose(\"%s\", \"w\")"
             "failed.\n", filename);
	return;
    }
    printf("%s has a total count of:%ld\n",
        filename, count);

    return;
}

static double uniformm1p1(void)
{	// Rick C. Hodgin's first suggestion:
        // uniform in range (-1.0, 1.0)
    return 2.0*drand48()-1.0;
}

static double get_random_value(void)
{	// Rick C. Hodgin's second suggestion
    double theta = 2.0*M_PI*drand48();
    return sin(theta);
}

int main(void)
{
    collect_counts(uniformm1p1, "first.raw");
    collect_counts(get_random_value, "second.raw");
    return 0;
}
===================================================

I converted the raw output files to PNG format using the commands:

    rawtopgm 360 152 first.raw > first.pgm
    rawtopgm 360 152 second.raw > second.pgm

If you don't have access to that utility, feel free to use whatever
method you're most comfortable with for converting the counts array into
a grayscale image.

The bright peaks in those images correspond to the corners of the cube.
The bright curves connecting them correspond to the edges. It's easy to
see that second.pgm is much more highly peaked than first.pgm.

[toc] | [prev] | [next] | [standalone]

#144530

On 6/3/19 6:40 PM, James Kuyper wrote:
> On Monday, June 3, 2019 at 10:32:32 AM UTC-4, Rick C. Hodgin wrote:
>> On Monday, June 3, 2019 at 10:17:59 AM UTC-4, Ben Bacarisse wrote:
> ...
>>> I don't think so.  What is the actual method you are suggesting (best in
>>> C given the group)?  Your words are not entirely clear.
>>
>> Code (off the top of my head, untested):
>>
>>     const double _2PI = 6.28318530718...;
>>
>>     // Assuming a random function that returns 0..MAX_UNSIGNED_INT
>>     double get_random_value(void)
>>     {
>>         double theta = _2PI * ((double)rand() / 
>>                                (double)MAX_UNSIGNED_INT);
>>         return sin(theta);
>>     }
>>
>> Use that function for each angle.  You have three angles to work
>> with on a sphere, one on the XY plane, one on the XZ plane, and
>> one on the YZ plane:
>>
>>     double x = get_random_value();
>>     double y = get_random_value();
>>     double z = get_random_value();
>>
>> These all exist somewhere between -1.0 and 1.0, and were projected
>> evenly by choosing an angle around the circle to obtain the coord-
>> inate to use for each axes.
> 
> What you're referring to are not angles - they are conventionally
> called direction cosines, being equal to the cosine of the
> corresponding angle.You're onto something by considering them,
> but the direction cosines are not independent of each other: they
> have a constraint that x^2+y^2+z^2 == 1.0. For a spherically
> symmetric distribution of directions, the direction cosine for
> the x axis, considered on it's own, would have a distribution
> proportional to sqrt(1-x^2), which x = sin(theta) will produce;
> the same is true for either of the other two axes. However,
> setting all three direction cosines independently won't satisfy
> the constraints. Following up by rescaling them to a unit vector
> solves that problem, but then they won't have the right
> distribution.
> 
> What you need to do is to keep that constraint in mind while
> generating those values. The following modifications to your
> routine will do the job:
> 
>     double x = get_random_value();
>     double y = sqrt(1-x*x)*get_random_value();
>     double z = sqrt(1-x*x-y*y)*(get_random_value() > 0.0 ? 1.0 :-1.0);
> 
> The sqrt() calls are what enforce the constraints, and they do so
> in a way that produces the desired exactly spherically symmetric
> distribution.
> 
> However, this is mathematically equivalent to the more
> conventional approach described in the stackexchange answer
> cited by Eli, which is simpler.

I've been very busy lately, with few opportunities for recreational use
of usenet. As a result, I snatched one such opportunity despite the fact
that I was apparently suffering more from lack of sleep than I thought.
Most of the above is nonsense. The main exception is the constraint x^2
+ y^2 + z^2 == 1.0

The x, y, and z values should be calculated from the appropriate angle
by taking the cosine of that angle, not the sine, as is indicated by the
name "direction cosine". As far as the distribution of values is
concerned, that doesn't matter - since you generate angles uniformly
covering a full circle, the distribution of values is the same whether
you use sine or cosine.

The key fact is that the portion of the surface of a sphere of radius R
that lies between the latitudes lat_lo and lat_hi is

    2*pi*R*R*(sin(lat_hi)-sin(lat_lo))

Therefore, in order to generate latitudes randomly that are evenly
distributed over the surface of the sphere, what you need to do is
generate a random value z, uniformly distributed over the range from
-1.0 to 1.0, and then calculate latitude = asin(z).

What you did is equivalent to randomly generating latitudes evenly
distributed from -pi/2 to pi/2, and then calculating z = sin(latitude).
The latitudes should not be evenly distributed - there should be a lot
more directions generated with latitudes near the equator than near the
poles, because a much larger portion of the surface of the sphere is
near the equator than to the poles.

The problem with your original suggestion was that it calculated
positions uniformly distributed over the volume of a cube centered at
the center of the sphere. Such a method will produce a
disproportionately large number of directions close to the corners of
the cube, because those corners are farthest from the center of the
sphere. It will produce a disproportionately small number of directions
close to the centers of each face of the cube, because those centers are
closest to the center of the sphere.

Changing from a uniform distribution for each coordinate, to calculating
the coordinate by using the sine of a uniformly distributed angle, makes
the problem much worse. That method increases the RMS value of the
distribution, biasing it toward large values, increasing the likelihood
of generating directions pointing near the corners of the cube, and
reducing the likelihood of generating ones that point near the centers
of the faces of the cube.

I don't have a plot ready to be displayed, but when I made my first stab
at such a plot, I found that the bias was much stronger than I expected,
which was what led me to realize how badly I was mistaken in what I
wrote earlier.

[toc] | [prev] | [next] | [standalone]

#144532

On Thursday, June 6, 2019 at 9:14:17 AM UTC-4, James Kuyper wrote:
> ...I've been very busy lately, with few opportunities for recreational use
> of usenet...

I have too.  I'll get back with you hopefully sometime this weekend.

Thank you for your posts.  They are not forgotten.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#144533

On Thu, 06 Jun 2019 09:14:09 -0400, James Kuyper wrote:

> 
> The key fact is that the portion of the surface of a sphere of radius R
> that lies between the latitudes lat_lo and lat_hi is
> 
>     2*pi*R*R*(sin(lat_hi)-sin(lat_lo))
> 

So then what happens when the problem changes to a different surface
such as an ellipsoid or a hyperboloid or any other?  Will you need
to start a whole new line of reasoning?

The problem is best solved with the mathematics of probability.

A probability density function (PDF) defines probabilities in
terms of AREAS.  This idea allows the uniform PDF, which is rectangular,
to be easily mapped onto any other surface.

For example, on a sphere the differential element of area is
proportional to sin(phi).  This means that, for r = 1,
the relevant PDF is sin(phi).  In other words, we must draw our
samples from the sin(phi) PDF rather than the uniform PDF.

(Note: if we wanted random points within a spherical VOLUME
then the differential volume element is r^2 * sin(phi) and
this would also be the PDF from which we would sample.)

To accomplish this we use "Inverse transform sampling" that
allows sampling from ANY distribution using the uniform PDF:

https://en.wikipedia.org/wiki/Inverse_transform_sampling

Using this mathematical procedure we can pick random points
on ANY surface and not just a sphere.

[toc] | [prev] | [next] | [standalone]

#144553

On 6/6/19 12:17 PM, F. Russell wrote:
> On Thu, 06 Jun 2019 09:14:09 -0400, James Kuyper wrote:
> 
>>
>> The key fact is that the portion of the surface of a sphere of radius R
>> that lies between the latitudes lat_lo and lat_hi is
>>
>>     2*pi*R*R*(sin(lat_hi)-sin(lat_lo))
>>
> 
> So then what happens when the problem changes to a different surface
> such as an ellipsoid or a hyperboloid or any other?  Will you need
> to start a whole new line of reasoning?

The OP isn't even ready to understand this level of description; I think
it's premature to expose him to the problem in more generality.

[toc] | [prev] | [next] | [standalone]

#144563

W dniu piątek, 7 czerwca 2019 02:18:43 UTC+2 użytkownik James Kuyper napisał:
> On 6/6/19 12:17 PM, F. Russell wrote:
> > On Thu, 06 Jun 2019 09:14:09 -0400, James Kuyper wrote:
> > 
> >>
> >> The key fact is that the portion of the surface of a sphere of radius R
> >> that lies between the latitudes lat_lo and lat_hi is
> >>
> >>     2*pi*R*R*(sin(lat_hi)-sin(lat_lo))
> >>
> > 
> > So then what happens when the problem changes to a different surface
> > such as an ellipsoid or a hyperboloid or any other?  Will you need
> > to start a whole new line of reasoning?
> 
> The OP isn't even ready to understand this level of description; I think
> it's premature to expose him to the problem in more generality.

if some names bulshit as generalisations ye im sorta proof on it

generally this is clc not math..and the question was about quick (fast) simple routine.. 

this one with 90 ns is quite ok, sorta what i was thinking about..if sole rand ger 13 ns and you need 3 here final 90 ns is sorta ok

[toc] | [prev] | [next] | [standalone]

#144593

On Friday, June 7, 2019 at 2:22:24 AM UTC-4, fir wrote:
> W dniu piątek, 7 czerwca 2019 02:18:43 UTC+2 użytkownik James Kuyper napisał:
> > On 6/6/19 12:17 PM, F. Russell wrote:
> > > On Thu, 06 Jun 2019 09:14:09 -0400, James Kuyper wrote:
> > > 
> > >>
> > >> The key fact is that the portion of the surface of a sphere of radius R
> > >> that lies between the latitudes lat_lo and lat_hi is
> > >>
> > >>     2*pi*R*R*(sin(lat_hi)-sin(lat_lo))
> > >>
> > > 
> > > So then what happens when the problem changes to a different surface
> > > such as an ellipsoid or a hyperboloid or any other?  Will you need
> > > to start a whole new line of reasoning?
> > 
> > The OP isn't even ready to understand this level of description; I think
> > it's premature to expose him to the problem in more generality.
> 
> if some names bulshit as generalisations ye im sorta proof on it

Sorry - that comment was actually about Rick C. Hodgin, not you. I'd forgotten that you were actually the OP for this thread. I have no idea what you can and cannot understand (other than the importance of clear communication, which you clearly do not understand), but Rick has expressed confusion about my earlier explanation.

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web