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

#144186

On Friday, May 31, 2019 at 8:55:04 AM UTC-4, Malcolm McLean wrote:
> On Friday, 31 May 2019 13:20:21 UTC+1, Rick C. Hodgin  wrote:
> > On Thursday, May 30, 2019 at 9:08:57 PM UTC-4, Ben Bacarisse wrote:
> > > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > > > The discussion of good random algorithms came up a few months ago.
> > > > Chris Thomasson posted a great algorithm:
> > > >
> > > >     https://groups.google.com/d/msg/comp.lang.c/RI0rdENv59s/BVUWgMBFDQAJ
> > > >
> > > > Use multi-channels, one for each [axis], with different seeds, and
> > > > then perform the math to determine your values between 0.0 and 1.0.
> > > 
> > > I think it's unlikely that that is the problematic part.  Once you have
> > > a source of uniformly distributed floating-point numbers, the question
> > > remains of how to pick a point on the unit sphere so that every point
> > > (AKA direction) is equally likely.
> > 
> > If he's looking for random vectors, you would not seek to move on
> > the unit sphere, but in whatever directions there are on each axis.
> > 
> > One could calculate the distance from your starting point to the
> > ending point so that you move one logical unit.  An arbitrary velo-
> > city on each axis (within reason), and an arbitrary direction on
> > each axis, and you can move 1 unit at a time using completely ran-
> > dom values without worrying anything about the unit sphere.  You
> > could calculate them as random values 0..2pi and then resolve their
> > (axis-relative) cos,sin coordinates to get real vector values, but
> > that's just one way to do it.
> > 
> > Is mine a correct thinking?
> > 
> No, you want each point on the sphere surrounding your origin to have
> an equal chance of being hit.
> So if you take a random point of longitude, you get a random point on
> the equator, which is a good start. But if you then take a random point
> of latitude, the points cluster up near the poles - not so good.
> 
> Another approach might be to take random x, y, z on a uniform box.
> However then you get more random points towards the corners of the box.
> You can get round this be excluding all points that don't lie within
> the unit sphere. That's a bit icky, but it will work and is your first
> method.

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

-- 
Rick C. Hodgin

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

#144188

W dniu piątek, 31 maja 2019 15:15:40 UTC+2 użytkownik Rick C. Hodgin napisał:
> I may be thinking incorrectly, but I don't think I am. :-)
> 
anybody knows it, your idiot who dont knows it.. geta out of my threads arrogant spamer

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

#144199

On 31/05/2019 15:15, Rick C. Hodgin wrote:
> On Friday, May 31, 2019 at 8:55:04 AM UTC-4, Malcolm McLean wrote:
>> On Friday, 31 May 2019 13:20:21 UTC+1, Rick C. Hodgin  wrote:
>>> On Thursday, May 30, 2019 at 9:08:57 PM UTC-4, Ben Bacarisse wrote:
>>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>>>> The discussion of good random algorithms came up a few months ago.
>>>>> Chris Thomasson posted a great algorithm:
>>>>>
>>>>>     https://groups.google.com/d/msg/comp.lang.c/RI0rdENv59s/BVUWgMBFDQAJ
>>>>>
>>>>> Use multi-channels, one for each [axis], with different seeds, and
>>>>> then perform the math to determine your values between 0.0 and 1.0.
>>>>
>>>> I think it's unlikely that that is the problematic part.  Once you have
>>>> a source of uniformly distributed floating-point numbers, the question
>>>> remains of how to pick a point on the unit sphere so that every point
>>>> (AKA direction) is equally likely.
>>>
>>> If he's looking for random vectors, you would not seek to move on
>>> the unit sphere, but in whatever directions there are on each axis.
>>>
>>> One could calculate the distance from your starting point to the
>>> ending point so that you move one logical unit.  An arbitrary velo-
>>> city on each axis (within reason), and an arbitrary direction on
>>> each axis, and you can move 1 unit at a time using completely ran-
>>> dom values without worrying anything about the unit sphere.  You
>>> could calculate them as random values 0..2pi and then resolve their
>>> (axis-relative) cos,sin coordinates to get real vector values, but
>>> that's just one way to do it.
>>>
>>> Is mine a correct thinking?
>>>
>> No, you want each point on the sphere surrounding your origin to have
>> an equal chance of being hit.
>> So if you take a random point of longitude, you get a random point on
>> the equator, which is a good start. But if you then take a random point
>> of latitude, the points cluster up near the poles - not so good.
>>
>> Another approach might be to take random x, y, z on a uniform box.
>> However then you get more random points towards the corners of the box.
>> You can get round this be excluding all points that don't lie within
>> the unit sphere. That's a bit icky, but it will work and is your first
>> method.
> 
> 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. :-)
> 

You are thinking incorrectly - at least if the OP wants a uniform
distribution.

It is worth noting, however, that he asked for random direction but did
not specify the distribution.  If the distribution doesn't matter, then
your suggestions are simpler to implement.

Imagine he had asked for random numbers between 2 and 12.  An answer of
"roll two dice and add them" will give such random numbers.  But it
won't be uniformly distributed - it will bunch around 7.  Your
suggestions for directions will also span the range requested, but will
bunch up instead of being even across the sphere.

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

#144212

On Friday, May 31, 2019 at 10:12:35 AM UTC-4, David Brown wrote:
> [snip]

I do not read your posts, David.  I never will again.

When you post something in reply to me, you're posting for
yourself and other people only.

-- 
Rick C. Hodgin

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

#144217

On 31/05/2019 17:14, Rick C. Hodgin wrote:
> On Friday, May 31, 2019 at 10:12:35 AM UTC-4, David Brown wrote:
>> [snip]
> 
> I do not read your posts, David.  I never will again.
> 

Yes, I know, I'm possessed by daemons that speak through me, and all
sorts of other nonsense.

> When you post something in reply to me, you're posting for
> yourself and other people only.
> 

Exactly, yes - I post for other people.

You are welcome to read my posts and benefit from them, of course - you
might learn something.  (Also, you may disagree and in return, help me
learn something - technical on-topic posts only, of course.)

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

#144222 — Rick should killfile everybody. (Was: quick & easy random dir vector, how?)

In article <75b51387-41f0-4137-a4bd-eadd73cd8ccd@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>On Friday, May 31, 2019 at 10:12:35 AM UTC-4, David Brown wrote:
>> [snip]
>
>I do not read your posts, David.  I never will again.

You would make a lot of people very happy if you stopped reading *any* posts.

Why limit your courtesy to DavidB only?
Is it because of the special relationship that you two share?

Please, please, please.  Killfile everybody in the group.  We will all
thank you.  We might even bake you a cake.

-- 
Reading any post by Fred Hodgin, you're always faced with the choice of:
    lunatic, moron, or troll.

I always try to be generous and give benefit of the doubt, by assuming troll.

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

#144225 — Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?)

On Friday, May 31, 2019 at 1:39:35 PM UTC-4, Kenny McCormack wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> >I do not read your posts, David.  I never will again.
> 
> Why limit your courtesy to DavidB only?

David's the only one I've ever permanently stop reading posts
from in my entire life.  Even Peter Cheung ... I still read
his posts and he's threatened more than once to kill me.

David and I do not correlate on anything, and after several
years of him telling me I was wrong in the multitude of my
life's endeavors, I was ready to be forever done with that
hateful, negative input into my life.  I've never regretted
the decision.

-- 
Rick C. Hodgin

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

#144241 — Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?)

On 31/05/2019 18:55, Rick C. Hodgin wrote:
> On Friday, May 31, 2019 at 1:39:35 PM UTC-4, Kenny McCormack wrote:
>> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>>> I do not read your posts, David.  I never will again.
>>
>> Why limit your courtesy to DavidB only?
> 
> David's the only one I've ever permanently stop reading posts
> from in my entire life.  Even Peter Cheung ... I still read
> his posts and he's threatened more than once to kill me.
> 
> David and I do not correlate on anything, and after several
> years of him telling me I was wrong in the multitude of my
> life's endeavors,

I'm just discovering the same thing. I've never known so much negativity 
from one person:

I don't know what I'm talking about. I'm not qualified to design 
languages. I'm not qualified to write compilers. Who cares how fast a 
compiler is. Who cares how small and compact it is. Who cares about all 
those new features. What a waste of time doing any of this stuff is. 
It's all pointless unless there are a million users. It's a waste of 
time if it can't compile 150-million line applications. Any such 
language and/or compiler can only ever be a toy.

"That just shows you know sod all about language design ..."

Oh, apparently I don't know C either. I can't write and understand C 
code. I don't understand my compilers or their options. I might, one 
day, be able to class myself as a beginner.

And no language syntax I can devise is ever going to be clearer than C 
(no matter how ugly the C equivalent). No new feature exists that can't 
be badly hacked with some ugly macro.

I was once playing with an early Raspberry Pi, fairly slow. My compiler 
took a second or two to compile some program; gcc took a minute. 
Impressive? No! Who cares how fast it is on a Pi. Nobody does serious 
development on those. They all use a PC to cross-compile.

But he's not entirely negative: in his world, nothing is ever too big, 
too slow or too complex. There's absolutely nothing wrong with having 
complexity and inconsistency in a language that learning 1000 pages of 
the standard reference by heart won't solve.

There's no such thing as bad code in C, provided it was legal at any 
time in the last 50 years. There is no criticism that can be levelled at 
any compiler for accepting such code, because it had once been legal, 
and there's nothing wrong with a compiler defaulting to a 1975 standard.

There is no limit to how many macro or typedef levels can be piled on 
top of each other before the code becomes impossible. Since you can 
write poor code in any language, C can't be any worse than any other in 
that regard [it is].

There can never be anything wrong with the C language that can't be 
solved with advanced compilers, IDEs, analysers, or smart editors.

There can never any annoying behaviour of a C compiler (== gcc) that 
can't be solved by some magic combination of its 2000 options.

There is nothing wrong with all the problems of using C as an 
intermediate target language that can't be fixed by jumping through 
preposterous hoops and making the process ten times more complicated 
than just writing native code.

There is not a single one of C's 193 undefined behaviours that is 
unnecessary: they all benefit the language. They make it easier to 
program not harder!

One bad (but once legal) piece of code is rejected by one compiler, and 
passed by another, even with the same options? Both are doing a fine job!

  I was ready to be forever done with that
> hateful, negative input into my life.  I've never regretted
> the decision.

David doesn't like mere individuals devising new program languages or 
writing compilers or doing anything that, in his opinion, should only be 
attempted by as large a team as possible, and preferably by  a corporation.

Even though plenty of now mainstream languages - including C - started 
that way.

I think possibly he might be a frustrated language designer or compiler 
writer and takes it out on others by pissing all over their ideas and 
achievements.

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

#144247 — Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?)

Bart <bc@freeuk.com> writes:
> On 31/05/2019 18:55, Rick C. Hodgin wrote:
[...]
>> David and I do not correlate on anything, and after several
>> years of him telling me I was wrong in the multitude of my
>> life's endeavors,
>
> I'm just discovering the same thing. I've never known so much negativity 
> from one person:

David, you're going to want to reply to this.  I implore you not to.
Ignore it and move on.  There's more than enough noise in this
newsgroup.

This has nothing to do with whether I think Rick, or Bart, or you are
right or wrong.  My point is that replying to this will inevitably
lead to more off-topic noise.

I have redirected followups.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#144249 — Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?)

In article <lnzhn2p5n5.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> wrote:
>Bart <bc@freeuk.com> writes:
>> On 31/05/2019 18:55, Rick C. Hodgin wrote:
>[...]
>>> David and I do not correlate on anything, and after several
>>> years of him telling me I was wrong in the multitude of my
>>> life's endeavors,
>>
>> I'm just discovering the same thing. I've never known so much negativity 
>> from one person:
>
>David, you're going to want to reply to this.  I implore you not to.
>Ignore it and move on.  There's more than enough noise in this
>newsgroup.
>
>This has nothing to do with whether I think Rick, or Bart, or you are
>right or wrong.  My point is that replying to this will inevitably
>lead to more off-topic noise.
>
>I have redirected followups.

Heh heh.

Well done, sir!

-- 
Reading any post by Fred Hodgin, you're always faced with the choice of:
    lunatic, moron, or troll.

I always try to be generous and give benefit of the doubt, by assuming troll.

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

#144248 — Re: Rick should killfile everybody. (Was: quick & easy random dir vector, how?)

In article <I4hIE.928439$2T.658833@fx20.am4>, Bart  <bc@freeuk.com> wrote:
>On 31/05/2019 18:55, Rick C. Hodgin wrote:
>> On Friday, May 31, 2019 at 1:39:35 PM UTC-4, Kenny McCormack wrote:
>>> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>>>> I do not read your posts, David.  I never will again.
>>>
>>> Why limit your courtesy to DavidB only?
>> 
>> David's the only one I've ever permanently stop reading posts
>> from in my entire life.  Even Peter Cheung ... I still read
>> his posts and he's threatened more than once to kill me.
>> 
>> David and I do not correlate on anything, and after several
>> years of him telling me I was wrong in the multitude of my
>> life's endeavors,
>
>I'm just discovering the same thing. I've never known so much negativity 
>from one person:

Yes - you got it right.

DB is clearly a piece of work.

That's why I think he & Rick should just go shack up together and leave
the rest of us alone.

They are so much alike.  They so deserve each other.

-- 
The people who were, are, and always will be, wrong about everything, are still
calling *us* "libtards"...

    (John Fugelsang)

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

#144657

El viernes, 31 de mayo de 2019, 17:14:50 (UTC+2), Rick C. Hodgin  escribió:
> On Friday, May 31, 2019 at 10:12:35 AM UTC-4, David Brown wrote:
> > [snip]
> 
> I do not read your posts, David.  I never will again.
> 
> When you post something in reply to me, you're posting for
> yourself and other people only.
> 
> -- 
> Rick C. Hodgin

oooofff

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

#144207

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

> On Friday, May 31, 2019 at 8:55:04 AM UTC-4, Malcolm McLean wrote:
>> On Friday, 31 May 2019 13:20:21 UTC+1, Rick C. Hodgin  wrote:
>> > On Thursday, May 30, 2019 at 9:08:57 PM UTC-4, Ben Bacarisse wrote:
>> > > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > > > The discussion of good random algorithms came up a few months ago.
>> > > > Chris Thomasson posted a great algorithm:
>> > > >
>> > > >     https://groups.google.com/d/msg/comp.lang.c/RI0rdENv59s/BVUWgMBFDQAJ
>> > > >
>> > > > Use multi-channels, one for each [axis], with different seeds, and
>> > > > then perform the math to determine your values between 0.0 and 1.0.
>> > > 
>> > > I think it's unlikely that that is the problematic part.  Once you have
>> > > a source of uniformly distributed floating-point numbers, the question
>> > > remains of how to pick a point on the unit sphere so that every point
>> > > (AKA direction) is equally likely.
>> > 
>> > If he's looking for random vectors, you would not seek to move on
>> > the unit sphere, but in whatever directions there are on each axis.
>> > 
>> > One could calculate the distance from your starting point to the
>> > ending point so that you move one logical unit.  An arbitrary velo-
>> > city on each axis (within reason), and an arbitrary direction on
>> > each axis, and you can move 1 unit at a time using completely ran-
>> > dom values without worrying anything about the unit sphere.  You
>> > could calculate them as random values 0..2pi and then resolve their
>> > (axis-relative) cos,sin coordinates to get real vector values, but
>> > that's just one way to do it.
>> > 
>> > Is mine a correct thinking?
>> > 
>> No, you want each point on the sphere surrounding your origin to have
>> an equal chance of being hit.
>> So if you take a random point of longitude, you get a random point on
>> the equator, which is a good start. But if you then take a random point
>> of latitude, the points cluster up near the poles - not so good.
>> 
>> Another approach might be to take random x, y, z on a uniform box.
>> However then you get more random points towards the corners of the box.
>> You can get round this be excluding all points that don't lie within
>> the unit sphere. That's a bit icky, but it will work and is your first
>> method.
>
> 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).

The question was rather specific -- to pick a random direction.  The
solution in 2D is to pick a random point on the unit circle --
essentially just scaling [0, 1) to the range [0, 2pi).  Try picking an x
and y value and using the resulting direction.  You will find they are
not uniformly distributed.

> I may be thinking incorrectly, but I don't think I am. :-)

That's often a problem.  We have that trouble.  With maths, there is at
least way to find out.

-- 
Ben.

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

#144211

On Friday, May 31, 2019 at 10:43:29 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Friday, May 31, 2019 at 8:55:04 AM UTC-4, Malcolm McLean wrote:
> >> On Friday, 31 May 2019 13:20:21 UTC+1, Rick C. Hodgin  wrote:
> >> > On Thursday, May 30, 2019 at 9:08:57 PM UTC-4, Ben Bacarisse wrote:
> >> > > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> > > > The discussion of good random algorithms came up a few months ago.
> >> > > > Chris Thomasson posted a great algorithm:
> >> > > >
> >> > > >     https://groups.google.com/d/msg/comp.lang.c/RI0rdENv59s/BVUWgMBFDQAJ
> >> > > >
> >> > > > Use multi-channels, one for each [axis], with different seeds, and
> >> > > > then perform the math to determine your values between 0.0 and 1.0.
> >> > > 
> >> > > I think it's unlikely that that is the problematic part.  Once you have
> >> > > a source of uniformly distributed floating-point numbers, the question
> >> > > remains of how to pick a point on the unit sphere so that every point
> >> > > (AKA direction) is equally likely.
> >> > 
> >> > If he's looking for random vectors, you would not seek to move on
> >> > the unit sphere, but in whatever directions there are on each axis.
> >> > 
> >> > One could calculate the distance from your starting point to the
> >> > ending point so that you move one logical unit.  An arbitrary velo-
> >> > city on each axis (within reason), and an arbitrary direction on
> >> > each axis, and you can move 1 unit at a time using completely ran-
> >> > dom values without worrying anything about the unit sphere.  You
> >> > could calculate them as random values 0..2pi and then resolve their
> >> > (axis-relative) cos,sin coordinates to get real vector values, but
> >> > that's just one way to do it.
> >> > 
> >> > Is mine a correct thinking?
> >> > 
> >> No, you want each point on the sphere surrounding your origin to have
> >> an equal chance of being hit.
> >> So if you take a random point of longitude, you get a random point on
> >> the equator, which is a good start. But if you then take a random point
> >> of latitude, the points cluster up near the poles - not so good.
> >> 
> >> Another approach might be to take random x, y, z on a uniform box.
> >> However then you get more random points towards the corners of the box.
> >> You can get round this be excluding all points that don't lie within
> >> the unit sphere. That's a bit icky, but it will work and is your first
> >> method.
> >
> > 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).
> 
> The question was rather specific -- to pick a random direction.

That's what my solution does.

You have random movement on the X axis, the Y axis, the Z axis.
Each one is independent.  Each one is linear.

Given those vectors, solve for a 3D movement of one unit, and
that gives you your 3D termination point, as well as your step
velocity if you want to render it in Nn frames over Mm seconds.

> The
> solution in 2D is to pick a random point on the unit circle --
> essentially just scaling [0, 1) to the range [0, 2pi).  Try picking an x
> and y value and using the resulting direction.  You will find they are
> not uniformly distributed.

For that reason, it's not a good solution.  You need linear
values, which can be accomplished with vectors and not sin/cos
values relative to a rotational theta.

-- 
Rick C. Hodgin

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

#144244

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

> On Friday, May 31, 2019 at 10:43:29 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Friday, May 31, 2019 at 8:55:04 AM UTC-4, Malcolm McLean wrote:
>> >> On Friday, 31 May 2019 13:20:21 UTC+1, Rick C. Hodgin  wrote:
>> >> > On Thursday, May 30, 2019 at 9:08:57 PM UTC-4, Ben Bacarisse wrote:
>> >> > > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> > > > The discussion of good random algorithms came up a few months ago.
>> >> > > > Chris Thomasson posted a great algorithm:
>> >> > > >
>> >> > > >     https://groups.google.com/d/msg/comp.lang.c/RI0rdENv59s/BVUWgMBFDQAJ
>> >> > > >
>> >> > > > Use multi-channels, one for each [axis], with different seeds, and
>> >> > > > then perform the math to determine your values between 0.0 and 1.0.
>> >> > > 
>> >> > > I think it's unlikely that that is the problematic part.  Once you have
>> >> > > a source of uniformly distributed floating-point numbers, the question
>> >> > > remains of how to pick a point on the unit sphere so that every point
>> >> > > (AKA direction) is equally likely.
>> >> > 
>> >> > If he's looking for random vectors, you would not seek to move on
>> >> > the unit sphere, but in whatever directions there are on each axis.
>> >> > 
>> >> > One could calculate the distance from your starting point to the
>> >> > ending point so that you move one logical unit.  An arbitrary velo-
>> >> > city on each axis (within reason), and an arbitrary direction on
>> >> > each axis, and you can move 1 unit at a time using completely ran-
>> >> > dom values without worrying anything about the unit sphere.  You
>> >> > could calculate them as random values 0..2pi and then resolve their
>> >> > (axis-relative) cos,sin coordinates to get real vector values, but
>> >> > that's just one way to do it.
>> >> > 
>> >> > Is mine a correct thinking?
>> >> > 
>> >> No, you want each point on the sphere surrounding your origin to have
>> >> an equal chance of being hit.
>> >> So if you take a random point of longitude, you get a random point on
>> >> the equator, which is a good start. But if you then take a random point
>> >> of latitude, the points cluster up near the poles - not so good.
>> >> 
>> >> Another approach might be to take random x, y, z on a uniform box.
>> >> However then you get more random points towards the corners of the box.
>> >> You can get round this be excluding all points that don't lie within
>> >> the unit sphere. That's a bit icky, but it will work and is your first
>> >> method.
>> >
>> > 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).
>> 
>> The question was rather specific -- to pick a random direction.
>
> That's what my solution does.

Yes, but I thought you were aiming for what the OP wanted.  You can pick
a random direction with one bit 0=left, 1=right.  As I said right at the
start: "the question remains of how to pick a point on the unit sphere
so that every point (AKA direction) is equally likely".

> You have random movement on the X axis, the Y axis, the Z axis.
> Each one is independent.  Each one is linear.

Did you mean uniform?

>> The
>> solution in 2D is to pick a random point on the unit circle --
>> essentially just scaling [0, 1) to the range [0, 2pi).  Try picking an x
>> and y value and using the resulting direction.  You will find they are
>> not uniformly distributed.
>
> For that reason, it's not a good solution.

That's one way to look at it!

> You need linear
> values, which can be accomplished with vectors and not sin/cos
> values relative to a rotational theta.

I don't understand this.  Are you suggesting an algorithm?

The task is to pick random points uniformly distributed over the
surface of the unit sphere.

-- 
Ben.

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

#144253

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

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

#144260

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

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.

-- 
Rick C. Hodgin

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

#144269

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

-- 
Ben.

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

#144272

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)

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

#144273

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

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

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

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

csiph-web