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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#144274

W dniu sobota, 1 czerwca 2019 21:35:38 UTC+2 użytkownik fir napisał:
> W dniu sobota, 1 czerwca 2019 21:05:04 UTC+2 użytkownik fir napisał:
> > W dniu sobota, 1 czerwca 2019 14:48:08 UTC+2 użytkownik Ben Bacarisse napisał:
> > > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > > 
> > > > On Friday, May 31, 2019 at 11:01:26 PM UTC-4, Richard Damon wrote:
> > > >> On 5/31/19 9:15 AM, Rick C. Hodgin wrote:
> > > >> > If you're using vectors, you have an arbitrary X, arbitrary Y, and
> > > >> > arbitrary Z direction you're moving.  It should not bunch up on any
> > > >> > axis, and should be linear across the spectrum of random values.
> > > >> > 
> > > >> > A random value for each axis computed between 0.0 and 2.0, then sub-
> > > >> > tract 1.0 to make it -1.0 to 1.0, and then scale by your velocity
> > > >> > vector whatever that is (a random value, or a known variable).
> > > >> > 
> > > >> > I may be thinking incorrectly, but I don't think I am. :-)
> > > >> 
> > > >> Uniformly random coordinates in X, Y, Z space, and then scaled to be a
> > > >> unit vector will NOT generate a uniform distribution on the unit sphere.
> > > >> The vectors going to the corners of the box will be over 41% more likely
> > > >> then the vectors pointing to the middle of the sides.
> > > >> 
> > > >> To be uniform over the surface of the unit sphere, you want to choose a
> > > >> location with a uniform distribution over longitude, and then the
> > > >> probability of any given latitude should be proportional to the cosine
> > > >> of the latitude. If I am doing my thought correctly about that, you
> > > >> could just take the arcsin of a number between 0 and 1 to get the right
> > > >> distribution.
> > > >> 
> > > >> You can then convert the longitude-latitude pair into an X, Y, Z, which
> > > >> with some simplification gives you the math that others have mentioned.
> > > >> 
> > > >> Another method if you have fast random number generation, but somewhat
> > > >> slow other arithmetic, (especially trig) would be to generate the random
> > > >> X, Y, and Z, and if the magnitude of the vector is greater that 1, throw
> > > >> it away and create another. You may also want to throw it away if it is
> > > >> much too small to avoid quantization grouping when you scale the vector
> > > >> to be unit length (or divide by 0 if you get exactly 0, 0, 0).
> > > >
> > > > I'll code up my algorithm and publish the data.  In my thinking,
> > > > I don't see how it will bunch up at any point over many random samples.
> > > > I'll try it with a million different seeds and post the extremes
> > > > and the averages.  Maybe I'll prove myself wrong and learn something.
> > > > Or maybe you naysayers will owe me a metaphoric apology. :-)
> > > 
> > > You won't need millions of seeds.  The bias is a strong one and will
> > > show up with only relatively few samples and in every run you do.  Your
> > > main problem will be how to plot or report the bias in a 3D version.
> > > 
> > > Here's a rough and ready 2D version:
> > > 
> > > #include <stdio.h>
> > > #include <math.h>
> > > #include <stdlib.h>
> > > 
> > > double rand_dir(void)
> > > {
> > >      return atan2(drand48() - 0.5, drand48() - 0.5);
> > > }
> > > 
> > > #define NB 16
> > > #define NL 100000
> > > 
> > > int main(void)
> > > {
> > >      int count[NB] = {0};
> > >      for (int i = 0; i < NL; i++)
> > >           ++count[(int)(NB * (rand_dir() / (2*3.14159265) + 0.5))];
> > >      for (int i = 0; i < NB; i++)
> > >           printf("%3d %f\n", (int)(i * 360.0/NB), count[i] / ((double)NL/NB));
> > > }
> > > 
> > > (Swap drand48 for some other floating point random number generator.)
> > > 
> > > The program picks directions using uniform x and y, divides them into
> > > NB buckets, and prints the counts as a fraction of the expected value.
> > > It slightly underestimates the bias as the maximum deviation occurs
> > > between two buckets.
> > > 
> > > > We shall see.  The game is on!
> > > >
> > > > It'll be a bit.  I'm wearing a welder's hat the next couple days.
> > > > Will be away from my dev computer.
> > > 
> > > I don't want to discourage you from writing your own.  A 3D version has
> > > an extra challenge -- how to summarise the results in a clear way.  I
> > > have no idea how to do that right now other than plotting the points in
> > > a 3D graphic.
> > > 
> > some my use my green.fire.dll to wisualise it
> > 
> > http://minddetonator.htw.pl/dristest.zip
> > 
> > with code like that 
> > 
> > #include<math.h>
> > #include<stdio.h>
> > 
> > #include "green-fire.h"
> > 
> > 
> > 
> > inline float RandFloatBelow1()
> > {
> >   return (float)(rand()&0x7fff)/0x8000;
> > }
> > 
> > inline float RandFloatTill1()
> > {
> >   return (float)(rand()&0x7fff)/0x7fff;
> > }
> > 
> > 
> > inline float3 GiveRandomDir3d()
> > {
> >    float3 dir;
> > 
> >    float a = 360.*RandFloatBelow1()*degree360;
> >    float b = 360.*RandFloatBelow1()*degree360;
> > 
> >    dir.x = cos(a)*cos(b);
> >    dir.y = sin(a)*cos(b);
> >    dir.z = sin(b);
> > 
> >    return dir;
> > }
> > 
> > 
> > inline float3 GiveRandomDir3d_2()
> > {
> >    float3 dir;
> >    float length_sqare;
> > 
> >    do
> >    {
> >      dir.x = -1.0 + 2.0*RandFloatTill1();
> >      dir.y = -1.0 + 2.0*RandFloatTill1();
> >      dir.z = -1.0 + 2.0*RandFloatTill1();
> > 
> >       length_sqare = dir.x*dir.x + dir.y*dir.y + dir.z*dir.z;
> >    }
> >    while( length_sqare>1.0 || length_sqare<0.0000001);
> > 
> >    float b = 1./sqrt(length_sqare);
> > 
> >    dir.x*=b;
> >    dir.y*=b;
> >    dir.z*=b;
> > 
> >    return dir;
> > 
> > }
> > 
> > 
> > 
> > 
> > void TestDirGenerator()
> > {
> > 
> >  if(frame_number!=1) return; //generate once
> > 
> >   for(int i=0; i<1000*30; i++)
> >   {
> >    float3 dir = GiveRandomDir3d();
> >    AddDotToBag(dir.x*500, dir.y*500, dir.z*500, 3, 0xffffff);
> >   }
> > 
> >   for(int i=0; i<1000*30; i++)
> >   {
> >    float3 dir = GiveRandomDir3d_2();
> >    AddDotToBag(dir.x*500+600, dir.y*500, dir.z*500+1000, 3, 0xffffff);
> >   }
> > 
> > }
> > 
> > void RunFrame(int advance)
> > {
> > 
> > 
> >      TestDirGenerator();
> > 
> >     ClearFrameData(0x404000);
> > 
> >      SetupLights_3moving();
> > 
> >      DrawDot3d(cameraPos.x, cameraPos.y, cameraPos.z,  4, 0xc0c000);
> >      if(space_pressed) FireDotFromCamera(1.5, 0.0, 5000, 50, 0xffffff);
> >      if(a_pressed)   SetDotExplosionFromCamera(3.0, 2, 30, 5000, 15, rgb(rand2(30,255),rand2(30,255),rand2(30,255)  ));
> >      DrawCubesCubeGeo();
> > 
> >      RunDotsBag();
> >      return;
> > 
> > 
> > }
> > 
> > 
> > void ProcessMouseMove(int x, int y){}
> > void ProcessKeyDown(int key){}
> > void OnResize(){}
> > 
> > 
> > int main(void)
> > {
> > 
> >         RegisterMouseMove( ProcessMouseMove );
> >         RegisterKeyDown( ProcessKeyDown );
> >         RegisterOnResize( OnResize );
> >         RegisterRunFrame( RunFrame );
> > 
> >         SetSleepValue(5);
> >         Set3dDrawingMode(1);
> > 
> >         SetScaleOnResize(0);
> >         SetupWindow2(" Example Green Fire App ",  20, 20,  500, 400 );
> > 
> > //        SetScaleOnResize(q);
> > //        SetupWindow3(" Example Green Fire App ",  20, 20,  640*0.8, 480*0.8, 640, 480 );
> > 
> >         return 0;
> > 
> > }
> > 
> > 
> > and with output like that
> > 
> > http://minddetonator.htw.pl/dirtest.png
> > 
> > (those to gigh densities are seen)
> > 
> > sadly my rasterizer is not subpixel and dont draw small dots nice
> > 
> > as a bonus you may draw in 3d space by pressing space or 'a' (i mention it becouse maybe i will post some questions/topics on it)
> > 
> > (hovever obviously it can be tested without drawing too)
> 
> ps not this rasterizer is designed to work in low res (i got my desktop resolution set to 640x480 coz i like it)
> 
> you may 'glue'/'unglue' mouse by pressing tilda '~' and resize but it may slow greatly (alretnatively one could call
> 
>  SetScaleOnResize(1);
> at setup and recompile
> 
> it makes it to count in lowres but 'streatch' lowres texture in bigger windows sizes 
> 
> i working on rasterizer recently and try various ideas searching, recently i added simple feature by drawing (inserting objects) in 3d by pressing 'a ' or space
> (works in that example sent)
> 
> http://minddetonator.htw.pl/dirt.png

ps. this coding in 3d space is real tempting/fun so i encourage if someone would like to use my lib and discuss some ideas here that could be fun and could revitalize the topics form dull talking on coding snippets based only  onstrings/console etc which id deadly dull (pixels better than strings, 3d float space probably better than pixels)

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

#144277

W dniu sobota, 1 czerwca 2019 21:05:04 UTC+2 użytkownik fir napisał:
> 
>   for(int i=0; i<1000*30; i++)
>   {
>    float3 dir = GiveRandomDir3d();
>    AddDotToBag(dir.x*500, dir.y*500, dir.z*500, 3, 0xffffff);
>   }
> 

note, i may add a few words on that abowe

i mean mostly on the "bag" 'concept' i 'invented' (though this is somewhat natural so speaking invented i dont meant that it is not used by many people, more that just that i thinked it up for myself)

i recently a bit think on this.. 

generally in todays graphics you may generate and draw objects on the fly

for(thousands..)
   DrawLine3d(args..)

those args you generate on the fly ant they like not exist on RAM

other way is to add those generated coordinates to some ram array once and 
then use it and eventually update it - instead of generating it on the fly


this second scenerio seems like more fundamental for me in some way, this firs feels than like some kind of super-optimisation

so in my rasterizer i named that ram array (internal for library) as a bag ("dot bag" becouse i mostly now experimanting with this one for 3d dots, maybe i later will ad some other bags for lines or maybe tris/quads/cubes, im not sure yet)


i not used this 'concept; to much yet so
im not sure what exactli i can say on it but it seems in some way interesting (as a concept) and maybe even some book could be written on it (or at least maybe some chapter in some book)

i mention it becouse maybe i later will write somethiong on related things and this is basic concept)

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

#144278

W dniu sobota, 1 czerwca 2019 23:52:45 UTC+2 użytkownik fir napisał:
> W dniu sobota, 1 czerwca 2019 21:05:04 UTC+2 użytkownik fir napisał:
> > 
> >   for(int i=0; i<1000*30; i++)
> >   {
> >    float3 dir = GiveRandomDir3d();
> >    AddDotToBag(dir.x*500, dir.y*500, dir.z*500, 3, 0xffffff);
> >   }
> > 
> 
> note, i may add a few words on that abowe
> 
> i mean mostly on the "bag" 'concept' i 'invented' (though this is somewhat natural so speaking invented i dont meant that it is not used by many people, more that just that i thinked it up for myself)
> 
> i recently a bit think on this.. 
> 
> generally in todays graphics you may generate and draw objects on the fly
> 
> for(thousands..)
>    DrawLine3d(args..)
> 
> those args you generate on the fly ant they like not exist on RAM
> 
> other way is to add those generated coordinates to some ram array once and 
> then use it and eventually update it - instead of generating it on the fly
> 
> 
> this second scenerio seems like more fundamental for me in some way, this firs feels than like some kind of super-optimisation
> 
> so in my rasterizer i named that ram array (internal for library) as a bag ("dot bag" becouse i mostly now experimanting with this one for 3d dots, maybe i later will ad some other bags for lines or maybe tris/quads/cubes, im not sure yet)
> 
> 
> i not used this 'concept; to much yet so
> im not sure what exactli i can say on it but it seems in some way interesting (as a concept) and maybe even some book could be written on it (or at least maybe some chapter in some book)
> 
> i mention it becouse maybe i later will write somethiong on related things and this is basic concept)

some things worth mentioning i observed this bag concept gies (to api) are for example ttl (time to live) or mentioned ability/quality to simply store its state
so for example you could add immediately
some things like movement behind the hood
or whole physics system

i mean 

for(...) 
  DrawDot3D(...)

only alllows to draw

for(...) 
  AddDot3D(...)
allows for example set ttl *in frames) and after that those dots will automatically vanish (freeing ram and freeing rasterizer burden) which is very nice feature

it gives some kinda new dimension to such api/universe

thats why its worth special mentioning imo

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

#144279

i also may add, i recently think how/what to design maybe in that form of mentioned way bag-based api, coz probably something interesting could be inented/thought up

[as to accusations that i make blog-like posts (like here) i answered: blog-like is not bad if content is interesting (and if someone will keep things maybe in more one place not starting thousands of threads etc), (also if introduction is made etc) 
as to accusations that this is off topic i also answered: c has various wings, and saying that only "c standard" is on-topic and c programming is not (or saying that only c that works on strings, printfs and things is on =topic) is wrong (in fact i think like opposite c-standard is not on c, cioz c is not a standard, standard is standard and c ic c)
what i say in this thread is just specific and interesting "wing of c" (which is specifiacally good if someone only gat some feel what is good in programming at all)

(hoever not to play like dik-like troll i also could be able to adjust if someone would say something sane (hovever this not includes proposition to improve my typing))

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

#144267

Rick C. Hodgin:

> If you're using vectors, you have an arbitrary X,
> arbitrary Y, and arbitrary Z direction you're moving.  It
> should not bunch up on any axis, and should be linear
> across the spectrum of random values.
>
> A random value for each axis computed between 0.0 and 2.0,
> then sub- tract 1.0 to make it -1.0 to 1.0, and then scale
> by your velocity vector whatever that is (a random value,
> or a known variable).
>
> I may be thinking incorrectly, but I don't think I am. :-)
> [...]
> I'll code up my algorithm and publish the data.  In my
> thinking, I don't see how it will bunch up at any point
> over many random samples.  I'll try it with a million
> different seeds and post the extremes and the averages.
> Maybe I'll prove myself wrong and learn something.  Or
> maybe you naysayers will owe me a metaphoric apology. :-)

It might save you wasted effort if you analysed your
solution before implementing it.  To put it short, a random
point in a cube with the center at the origin will not have
a random radius-vector.  Image your method on a plane.  The
likeligood of the direction formed by a random point in a
square is proportional to the distance along that direction
from center to edge.  Therefore, the likeliest for
directions are along the diagonals and the least likely are
the four parallel to the edges.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#144328

On Saturday, June 1, 2019 at 8:30:34 AM UTC-4, Anton Shepelev wrote:
> Rick C. Hodgin:
> 
> > If you're using vectors, you have an arbitrary X,
> > arbitrary Y, and arbitrary Z direction you're moving.  It
> > should not bunch up on any axis, and should be linear
> > across the spectrum of random values.
> >
> > A random value for each axis computed between 0.0 and 2.0,
> > then sub- tract 1.0 to make it -1.0 to 1.0, and then scale
> > by your velocity vector whatever that is (a random value,
> > or a known variable).
> >
> > I may be thinking incorrectly, but I don't think I am. :-)
> > [...]
> > I'll code up my algorithm and publish the data.  In my
> > thinking, I don't see how it will bunch up at any point
> > over many random samples.  I'll try it with a million
> > different seeds and post the extremes and the averages.
> > Maybe I'll prove myself wrong and learn something.  Or
> > maybe you naysayers will owe me a metaphoric apology. :-)
> 
> It might save you wasted effort if you analysed your
> solution before implementing it.  To put it short, a random
> point in a cube with the center at the origin will not have
> a random radius-vector.  Image your method on a plane.  The
> likelihood of the direction formed by a random point in a
> square is proportional to the distance along that direction
> from center to edge.  Therefore, the likeliest for
> directions are along the diagonals and the least likely are
> the four parallel to the edges.

It occurred to me this morning, that even if the distribution
of the points using this system are not uniform across the
surface of the sphere, they would still be fully random, be-
cause they're being based on fully random points being gener-
ated on all three axes.

The system would still work from a random point of view, it
would just not be completely symmetric across the surface of
the unit sphere.

-- 
Rick C. Hodgin

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

#144331

On Monday, June 3, 2019 at 8:30:20 AM UTC-4, Rick C. Hodgin wrote:
> It occurred to me this morning, that even if the distribution
> of the points using this system are not uniform across the
> surface of the sphere, they would still be fully random, be-
> cause they're being based on fully random points being gener-
> ated on all three axes.
> 
> The system would still work from a random point of view, it
> would just not be completely symmetric across the surface of
> the unit sphere.

This might actually be a way to solve some unsolved equations in
math today, if you could prove that in cases of even a non-uniform
application of the algorithm it does still work, then it would
follow that it would also hold true over a uniform application.

Even a tessellated icosphere.  Imagine breaking up each resulting
triangle into as many sub-triangles as you like, and then randomly
choosing a point somewhere in that triangle, which correlates to
one of the sub-triangle numbers.

A random selection of which tessellated triangle to select, and
then a random selection within on which sub-triangle to detect.
You could even then pick another random location within that last-
level triangle, and sub-divide even further.

But even so, a very fast algorithm I think would be to use the
random values on the axes and project onto the unit sphere.  A
better, more evenly distributed algorithm, would be to use the
random values between 0..2pi on each axes, sin(theta) to project
as a unit square, and then do the same using those points, as
they would not be bunched up anywhere, but would be random around
the unit sphere.

I think that would work.

-- 
Rick C. Hodgin

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

#144334

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Monday, June 3, 2019 at 8:30:20 AM UTC-4, Rick C. Hodgin wrote:
>> It occurred to me this morning, that even if the distribution
>> of the points using this system are not uniform across the
>> surface of the sphere, they would still be fully random, be-
>> cause they're being based on fully random points being gener-
>> ated on all three axes.

"Fully random" is rather vague.  How much bias in the distribution would
it take before you declared it not "fully random"?  You could pick
points in a "brick" (x in [-1, 1], y in [-2, 2], z in [-5, 5] for
example) and normalise those.  Would those directions be "fully random"?

Maybe "fully random" means that the probably of getting a given
direction is nowhere zero?  If so, that would permit a very extreme
bias.

>> The system would still work from a random point of view, it
>> would just not be completely symmetric across the surface of
>> the unit sphere.

You mean uniform, not symmetric.  The biased distribution is symmetric
(to some extent) but not uniform.

> But even so, a very fast algorithm I think would be to use the
> random values on the axes and project onto the unit sphere.

Fast and non-uniform is not necessarily better than slower and uniform.

> A better, more evenly distributed algorithm, would be to use the
> random values between 0..2pi on each axes, sin(theta) to project as a
> unit square, and then do the same using those points, as they would
> not be bunched up anywhere, but would be random around the unit
> sphere.
>
> I think that would work.

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.

-- 
Ben.

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

#144335

On Monday, June 3, 2019 at 10:17:59 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > On Monday, June 3, 2019 at 8:30:20 AM UTC-4, Rick C. Hodgin wrote:
> >> It occurred to me this morning, that even if the distribution
> >> of the points using this system are not uniform across the
> >> surface of the sphere, they would still be fully random, be-
> >> cause they're being based on fully random points being gener-
> >> ated on all three axes.
> 
> "Fully random" is rather vague.  How much bias in the distribution would
> it take before you declared it not "fully random"?

That was my question to someone who worked at Centaur back in the
early 2000s when I received one of their VIA C7-M CPUs with a
built-in hardware random number generator.  The Centaur tech gave
me the assembly opcodes to be able to activate the instructions,
and I began doing some testing.

At 40C the distribution was perfect over billions of samples.  As
the CPU temperature began to rise, however, there was a noted skew
toward 0 and 255.  It looked like you took the straight-line that
had been there before, and placed a large basketball on it, causing
it to be lower in the middle around 128, and higher at the sides
around 0 and 255, with a fairly proportional curve like the outer
circumference of a basketball.

I asked the Centaur Tech about it, and he said that even though the
values are skewed at higher temperatures, they still are sufficienly
random to be considered truly random, as you could not predicted
where on the 0..255 range each value would fall.

It would be the same here with this spherical randomness.

> You could pick
> points in a "brick" (x in [-1, 1], y in [-2, 2], z in [-5, 5] for
> example) and normalise those.  Would those directions be "fully random"?
> 
> Maybe "fully random" means that the probably of getting a given
> direction is nowhere zero?  If so, that would permit a very extreme
> bias.
> 
> >> The system would still work from a random point of view, it
> >> would just not be completely symmetric across the surface of
> >> the unit sphere.
> 
> You mean uniform, not symmetric.  The biased distribution is symmetric
> (to some extent) but not uniform.

Perhaps.  It would only be symmetric around a few great circles.

> > But even so, a very fast algorithm I think would be to use the
> > random values on the axes and project onto the unit sphere.
> 
> Fast and non-uniform is not necessarily better than slower and uniform.

One of fir's goals (IIRC) was that it should be a fast algorithm.

> > A better, more evenly distributed algorithm, would be to use the
> > random values between 0..2pi on each axes, sin(theta) to project as a
> > unit square, and then do the same using those points, as they would
> > not be bunched up anywhere, but would be random around the unit
> > sphere.
> >
> > I think that would work.
> 
> 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.

-- 
Rick C. Hodgin

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

#144341

On 03/06/2019 16:32, Rick C. Hodgin wrote:
> On Monday, June 3, 2019 at 10:17:59 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> On Monday, June 3, 2019 at 8:30:20 AM UTC-4, Rick C. Hodgin wrote:
>>>> It occurred to me this morning, that even if the distribution
>>>> of the points using this system are not uniform across the
>>>> surface of the sphere, they would still be fully random, be-
>>>> cause they're being based on fully random points being gener-
>>>> ated on all three axes.
>>
>> "Fully random" is rather vague.  How much bias in the distribution would
>> it take before you declared it not "fully random"?
> 
> That was my question to someone who worked at Centaur back in the
> early 2000s when I received one of their VIA C7-M CPUs with a
> built-in hardware random number generator.  The Centaur tech gave
> me the assembly opcodes to be able to activate the instructions,
> and I began doing some testing.
> 
> At 40C the distribution was perfect over billions of samples.  As
> the CPU temperature began to rise, however, there was a noted skew
> toward 0 and 255.  It looked like you took the straight-line that
> had been there before, and placed a large basketball on it, causing
> it to be lower in the middle around 128, and higher at the sides
> around 0 and 255, with a fairly proportional curve like the outer
> circumference of a basketball.
> 
> I asked the Centaur Tech about it, and he said that even though the
> values are skewed at higher temperatures, they still are sufficienly
> random to be considered truly random, as you could not predicted
> where on the 0..255 range each value would fall.
> 

What this means is that the values are non-deterministic and 
uncorrelated - if you have a sequence of samples from it, these give you 
no clues as to what future samples might be.  The distribution of these 
samples is another matter entirely.

For computing purposes, you often take samples from a "true" random 
source, or at least a high entropy source, and use them as seeds for a 
pseudorandom number generator with a more uniform distribution (and 
usually faster algorithms).  This gives you a convenient way to get 
uniform distribution while still being largely non-deterministic.

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

#144350

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Monday, June 3, 2019 at 10:17:59 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > On Monday, June 3, 2019 at 8:30:20 AM UTC-4, Rick C. Hodgin wrote:
>> >> It occurred to me this morning, that even if the distribution
>> >> of the points using this system are not uniform across the
>> >> surface of the sphere, they would still be fully random, be-
>> >> cause they're being based on fully random points being gener-
>> >> ated on all three axes.
>> 
>> "Fully random" is rather vague.  How much bias in the distribution would
>> it take before you declared it not "fully random"?
>
> That was my question to someone who worked at Centaur back in the
> early 2000s when I received one of their VIA C7-M CPUs with a
> built-in hardware random number generator.  The Centaur tech gave
> me the assembly opcodes to be able to activate the instructions,
> and I began doing some testing.
>
> At 40C the distribution was perfect over billions of samples.  As
> the CPU temperature began to rise, however, there was a noted skew
> toward 0 and 255.  It looked like you took the straight-line that
> had been there before, and placed a large basketball on it, causing
> it to be lower in the middle around 128, and higher at the sides
> around 0 and 255, with a fairly proportional curve like the outer
> circumference of a basketball.
>
> I asked the Centaur Tech about it, and he said that even though the
> values are skewed at higher temperatures, they still are sufficienly
> random to be considered truly random, as you could not predicted
> where on the 0..255 range each value would fall.
>
> It would be the same here with this spherical randomness.

I can't find an answer in that anecdote.  Did you intend that?  If not,
could be more direct please?

>> > A better, more evenly distributed algorithm, would be to use the
>> > random values between 0..2pi on each axes, sin(theta) to project as a
>> > unit square, and then do the same using those points, as they would
>> > not be bunched up anywhere, but would be random around the unit
>> > sphere.
>> >
>> > I think that would work.
>> 
>> 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();

And then project onto the unit sphere (i.e. normalise to a unit vector)?
I don't see how this can make the distribution uniform.

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

I think the sin function adds to the bias.

-- 
Ben.

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

#144351

On Monday, June 3, 2019 at 4:14:25 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > I asked the Centaur Tech about it, and he said that even though the
> > values are skewed at higher temperatures, they still are sufficiently
> > random to be considered truly random, as you could not predict where
> > on the 0..255 range each value would fall.
> >
> > It would be the same here with this spherical randomness.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I can't find an answer in that anecdote.

It's there in the highlighted sentence.

-- 
Rick C. Hodgin

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

#144359

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Monday, June 3, 2019 at 4:14:25 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > I asked the Centaur Tech about it, and he said that even though the
>> > values are skewed at higher temperatures, they still are sufficiently
>> > random to be considered truly random, as you could not predict where
>> > on the 0..255 range each value would fall.
>> >
>> > It would be the same here with this spherical randomness.
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> I can't find an answer in that anecdote.
>
> It's there in the highlighted sentence.

You used the phrase "fully random" and I asked "How much bias in the
distribution would it take before you declared it not 'fully random'?"
The anecdote does not use that phrase.  The engineer is talking about
true randomness -- a physical property of a data source.  Pseudo-random
numbers are entirely predictable, so the engineer's talk of
unpredictable values can't carry over to answer my question.  What's
more, I was asking a quantitative question -- how /much/ bias is
allowable in what you call a fully random distribution?

It hardly matters now.  I was curious about what you meant, but not so
curious as to keep trying to find out.

-- 
Ben.

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

#144366

On Monday, June 3, 2019 at 5:42:11 PM UTC-4, Ben Bacarisse wrote:
> It hardly matters now.  I was curious about what you meant, but not so
> curious as to keep trying to find out.


So we're done then?

-- 
Rick C. Hodgin

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

#144363

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.
That approach is probably also faster, mainly because it involves
one less call to sqrt(). More subtly, that algorithm can also be
optimized to call the non-standard function sincos(), which
calculates both sin(theta) and cos(theta), saving a significant
amount of time reducing the argument to the range 0<=theta<pi/4
only once. Many compilers, if they see code that calls sin() and
cos() for the same angle, will optimize that pair into a single
call to sincos().

The following anecdote is only loosely related to anything
discussed earlier in this thread:

I found out about that optimization when it triggered a bug in
the optimization of third-party library code which provided its
own function called sincos() which simply called sin() and cos()
separately, without sharing the work of argument reduction. The
sincos() that was provided as an extension was not visible to
user code unless appropriate non-conforming options were
selected. Therefore, when those options were not selected, it
should have been fine for user code to define a function with
the same name. For that reason, the extension should have been
called _sincos(). However, the optimizer converted those sin()
and cos() calls into an infinitely recursive call to sincos()
rather than a non-recursive call to _sincos().

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

#144390

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'll snip the rest of your reply for now and come back to it]

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 means
I need an X,Y,Z coordinate to achieve a point, and the surface is
the set of points that are valid.

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.

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

-- 
Rick C. Hodgin

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

#144406

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> 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'll snip the rest of your reply for now and come back to it]
>
> 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.

> That means
> I need an X,Y,Z coordinate to achieve a point, and the surface is
> the set of points that are valid.

Yup.

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

An another problem crops up which is that your code does appear to
correspond to the description you give here.

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?

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

-- 
Ben.

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

#144408

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.

-- 
Rick C. Hodgin

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

#144455

On 6/4/2019 8:48 AM, 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.
> 

Afaict, the bias seems to go to the corners of the unit cube. Fwiw, when 
I get some more time, I can show this to you in a 3d object. Here is an 
example of what I am thinking about... These lines are not random, but I 
can use them as a medium to actually plot this thing:

https://skfb.ly/6Ku6s

This is a vector field plotted on the unit cube.

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

#144456

On 6/4/2019 9:09 PM, Chris M. Thomasson wrote:
> On 6/4/2019 8:48 AM, 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.
>>
> 
> Afaict, the bias seems to go to the corners of the unit cube. Fwiw, when 
> I get some more time, I can show this to you in a 3d object. Here is an 
> example of what I am thinking about... These lines are not random, but I 
> can use them as a medium to actually plot this thing:
> 
> https://skfb.ly/6Ku6s
> 
> This is a vector field plotted on the unit cube.

This has nine points. One for each corner, and on in the middle.

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

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

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

csiph-web