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

#144155 — quick & easy random dir vector, how?

sometimes you want random int, but sometimes you need random dir vector in 3d space
(by random dir i mean randomly directed and of length 1.00)

how to generate it to be generated quick 
(sometimes i may need to generate tons of them so quick is important) and easy?

[toc] | [next] | [standalone]

#144156

On Thursday, May 30, 2019 at 4:48:04 PM UTC-4, fir wrote:
> sometimes you want random int, but sometimes you need random dir vector in 3d space
> (by random dir i mean randomly directed and of length 1.00)
> 
> how to generate it to be generated quick 
> (sometimes i may need to generate tons of them so quick is important) and easy?

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 access, with different seeds, and
then perform the math to determine your values between 0.0 and 1.0.

How's the fir compiler coming along (firinator??)?  You were going
to write it in a week or so IIRC.

-- 
Rick C. Hodgin

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

#144163

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

> On Thursday, May 30, 2019 at 4:48:04 PM UTC-4, fir wrote:
>> sometimes you want random int, but sometimes you need random dir vector in 3d space
>> (by random dir i mean randomly directed and of length 1.00)
>> 
>> how to generate it to be generated quick 
>> (sometimes i may need to generate tons of them so quick is important) and easy?
>
> 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 access, 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.

This sort of thing is usually best done by (a) a good web search, or (b)
asking in a suitable group.  Some of fir's questions might help revive
comp.programming (though if there is an active graphics group, that
would be better still).

I don't want to offer any suggestions because fir will probably just be
rude about them and any ensuing off-topic discussion will just pollute
comp.lang.c even more.

-- 
Ben.

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

#144168

W dniu piątek, 31 maja 2019 03:08:57 UTC+2 użytkownik Ben Bacarisse napisał:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Thursday, May 30, 2019 at 4:48:04 PM UTC-4, fir wrote:
> >> sometimes you want random int, but sometimes you need random dir vector in 3d space
> >> (by random dir i mean randomly directed and of length 1.00)
> >> 
> >> how to generate it to be generated quick 
> >> (sometimes i may need to generate tons of them so quick is important) and easy?
> >
> > 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 access, 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.
> 
> This sort of thing is usually best done by (a) a good web search, or (b)
> asking in a suitable group.  Some of fir's questions might help revive
> comp.programming (though if there is an active graphics group, that
> would be better still).
> 
> I don't want to offer any suggestions because fir will probably just be
> rude about them and any ensuing off-topic discussion will just pollute
> comp.lang.c even more.
> 

rude is proper on "1q 50" content..
otherwise it would mean that i legitimize it and i still belive this group may go better (than dwell and propagate stupidity)

this above anti-answer was exceptionally stupid 1) this is good c question, becouse you often use c 'primitives' to wrote c code using them, this question is like asking how to do something on
string in c (like how to reverse string etc) just using rand() and floats - so maybe stop playin fool (this also is appropriate to bartc who plays fool even more)

dont want answer to it dont answer to it, its cool question imo, but its minor and no answers to it is not any harm

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

#144169

On Friday, 31 May 2019 02:08:57 UTC+1, Ben Bacarisse  wrote:
> 
> This sort of thing is usually best done by (a) a good web search, or (b)
> asking in a suitable group.  Some of fir's questions might help revive
> comp.programming (though if there is an active graphics group, that
> would be better still).
> 
A web search turned up the answer on the first hit.

It's not something you are likely to be able to derive yourself if you
are not a mathematician. Needless to say, the obvious method (generate
two or three angles on 0 - 2PI  and rotate around each axis) produces
a distribution which is bunched towards the poles, so you have to be
cleverer.

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

#144228

In comp.lang.c, Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
> On Friday, 31 May 2019 02:08:57 UTC+1, Ben Bacarisse  wrote:
>> This sort of thing is usually best done by (a) a good web search, or (b)
>> asking in a suitable group.  Some of fir's questions might help revive
>> comp.programming (though if there is an active graphics group, that
>> would be better still).
> A web search turned up the answer on the first hit.
> 
> It's not something you are likely to be able to derive yourself if you
> are not a mathematician. Needless to say, the obvious method (generate
> two or three angles on 0 - 2PI  and rotate around each axis) produces
> a distribution which is bunched towards the poles, so you have to be
> cleverer.

Hmmm. My naive first guess would be to pick a random number for the
first angle, find the remaining distance to cover and then use a second
random number to divide that distance between the other two directions.

The winning answer here:

https://math.stackexchange.com/questions/44689/how-to-find-a-random-axis-or-unit-vector-in-3d

is a bit different. Basically it picks an angle and length and then uses
length in calculating all three of the directions, and the angle in
calculating two of the directions. But the math for the division is more
sophisticated than I would have guessed.

Elijah
------
probably would have had that "too many points near pole" issue

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

#144230

W dniu piątek, 31 maja 2019 21:28:08 UTC+2 użytkownik Eli the Bearded napisał:
> In comp.lang.c, Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
> > On Friday, 31 May 2019 02:08:57 UTC+1, Ben Bacarisse  wrote:
> >> This sort of thing is usually best done by (a) a good web search, or (b)
> >> asking in a suitable group.  Some of fir's questions might help revive
> >> comp.programming (though if there is an active graphics group, that
> >> would be better still).
> > A web search turned up the answer on the first hit.
> > 
> > It's not something you are likely to be able to derive yourself if you
> > are not a mathematician. Needless to say, the obvious method (generate
> > two or three angles on 0 - 2PI  and rotate around each axis) produces
> > a distribution which is bunched towards the poles, so you have to be
> > cleverer.
> 
> Hmmm. My naive first guess would be to pick a random number for the
> first angle, find the remaining distance to cover and then use a second
> random number to divide that distance between the other two directions.
> 
> The winning answer here:
> 
> https://math.stackexchange.com/questions/44689/how-to-find-a-random-axis-or-unit-vector-in-3d
> 
> is a bit different. Basically it picks an angle and length and then uses
> length in calculating all three of the directions, and the angle in
> calculating two of the directions. But the math for the division is more
> sophisticated than I would have guessed.
> 
what makes you think its winning it has 2 sqrts and cos and sin so it would be slow

here wining is what is accurate and fast (and has no side disadvantages)

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

#144235

In comp.lang.c, fir  <profesor.fir@gmail.com> wrote:
> W dniu piątek, 31 maja 2019 21:28:08 UTC+2 użytkownik Eli the Bearded napisał:
>> The winning answer here:
>> https://math.stackexchange.com/questions/44689/how-to-find-a-random-axis-or-unit-vector-in-3d
> what makes you think its winning it has 2 sqrts and cos and sin so it would be slow
> here wining is what is accurate and fast (and has no side disadvantages)

It is "winning" in two senses:

1) The question asker "accepted" (green check) that answer as correct
2) That answer has more upvotes (44) than any other answer (second place
   has 30 points).

You can speed up that answer by noting it has one square root used twice
and you could probably get away with a (single) lookup table for sine
and cosine find those values quickly if speed matters more than
accuracy. Heck, it's one square root over a small range of values, you
could use a lookup table for that, too.

Elijah
------
remembers when math textbooks would have sin/cos tables

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

#144236

W dniu piątek, 31 maja 2019 22:36:30 UTC+2 użytkownik Eli the Bearded napisał:
> In comp.lang.c, fir  <profesor.fir@gmail.com> wrote:
> > W dniu piątek, 31 maja 2019 21:28:08 UTC+2 użytkownik Eli the Bearded napisał:
> >> The winning answer here:
> >> https://math.stackexchange.com/questions/44689/how-to-find-a-random-axis-or-unit-vector-in-3d
> > what makes you think its winning it has 2 sqrts and cos and sin so it would be slow
> > here wining is what is accurate and fast (and has no side disadvantages)
> 
> It is "winning" in two senses:
> 
> 1) The question asker "accepted" (green check) that answer as correct
> 2) That answer has more upvotes (44) than any other answer (second place
>    has 30 points).
> 
> You can speed up that answer by noting it has one square root used twice
> and you could probably get away with a (single) lookup table for sine
> and cosine find those values quickly if speed matters more than
> accuracy. Heck, it's one square root over a small range of values, you
> could use a lookup table for that, too.
> 
i preciously said i dont want use look up tables, 
[not that they are bad but they are like differend kind of programming

(i once used them, even got a code that generates some)]

honestly im not sure my precious opinions on them it seem they worked as i tested em, but something also stopped me to use em [probably the fact that i think that the heaviest optimisations should be done but at the end)

maybe with tables this one above will beat this 150 ms version but that one also could use look up table, so i wouldnt name one wining eben in that case of tables without checking 9and now im to weary to check)

it would be proper if you wold name it 'maybe winning' not 'winning' coz it introduces kinda mess and is wearing

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

#144239

W dniu piątek, 31 maja 2019 23:01:03 UTC+2 użytkownik fir napisał:
> W dniu piątek, 31 maja 2019 22:36:30 UTC+2 użytkownik Eli the Bearded napisał:
> > In comp.lang.c, fir  <profesor.fir@gmail.com> wrote:
> > > W dniu piątek, 31 maja 2019 21:28:08 UTC+2 użytkownik Eli the Bearded napisał:
> > >> The winning answer here:
> > >> https://math.stackexchange.com/questions/44689/how-to-find-a-random-axis-or-unit-vector-in-3d
> > > what makes you think its winning it has 2 sqrts and cos and sin so it would be slow
> > > here wining is what is accurate and fast (and has no side disadvantages)
> > 
> > It is "winning" in two senses:
> > 
> > 1) The question asker "accepted" (green check) that answer as correct
> > 2) That answer has more upvotes (44) than any other answer (second place
> >    has 30 points).
> > 
> > You can speed up that answer by noting it has one square root used twice
> > and you could probably get away with a (single) lookup table for sine
> > and cosine find those values quickly if speed matters more than
> > accuracy. Heck, it's one square root over a small range of values, you
> > could use a lookup table for that, too.
> > 
> i preciously said i dont want use look up tables, 
> [not that they are bad but they are like differend kind of programming
> 
> (i once used them, even got a code that generates some)]
> 
> honestly im not sure my precious opinions on them it seem they worked as i tested em, but something also stopped me to use em [probably the fact that i think that the heaviest optimisations should be done but at the end)
> 
> maybe with tables this one above will beat this 150 ms version but that one also could use look up table, so i wouldnt name one wining eben in that case of tables without checking 9and now im to weary to check)
> 
> it would be proper if you wold name it 'maybe winning' not 'winning' coz it introduces kinda mess and is wearing

btw i checked it


inline float RandFloatBelow1()
{
  return (float)(rand()&0x7fff)/0x8000;
}

inline float RandFloatTill1()
{
  return (float)(rand()&0x7fff)/0x7fff;
}

inline float3 GiveRandomDir3d_4()
{
   float3 dir;

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

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

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

   return dir;
}

visualy it seems to look ok, as to speed its about 300 ms..
those look up versions i probably will not check - or maybe? im not sure

hovever this hint was helpfull

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

#144171

On Friday, 31 May 2019 02:08:57 UTC+1, Ben Bacarisse  wrote:
> Some of fir's questions might help revive
> xxxx.xxxxxxxxxx (though if there is an active graphics group, that
> would be better still).

I don't think inflicting fir on further newsgroups is a kind thing to do,
but I'm an iq 50 blaber.

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

#144175

mark.bluemel@gmail.com wrote:

>> Some of fir's questions might help revive
>> xxxx.xxxxxxxxxx (though if there is an active graphics group, that
>> would be better still).
> 
> I don't think inflicting fir on further newsgroups is a kind thing to do,
> but I'm an iq 50 blaber.

The more other groups get firred, the less will be this one.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

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

#144202

mark.bluemel@gmail.com writes:

> On Friday, 31 May 2019 02:08:57 UTC+1, Ben Bacarisse  wrote:
>> Some of fir's questions might help revive
>> xxxx.xxxxxxxxxx (though if there is an active graphics group, that
>> would be better still).
>
> I don't think inflicting fir on further newsgroups is a kind thing to do,
> but I'm an iq 50 blaber.

comp.programming is dead.  But someone incoherent and rude can none the
less spark a discussion.  The general question of taking uniform
floating point numbers in [0, 1) and generating uniform directions is an
interesting one.  And there are many other related questions such as
picking a point on any other surface with equal probability.

-- 
Ben.

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

#144206

W dniu piątek, 31 maja 2019 16:23:00 UTC+2 użytkownik Ben Bacarisse napisał:
> mark.bluemel@gmail.com writes:
> 
> > On Friday, 31 May 2019 02:08:57 UTC+1, Ben Bacarisse  wrote:
> >> Some of fir's questions might help revive
> >> xxxx.xxxxxxxxxx (though if there is an active graphics group, that
> >> would be better still).
> >
> > I don't think inflicting fir on further newsgroups is a kind thing to do,
> > but I'm an iq 50 blaber.
> 
> comp.programming is dead.  But someone incoherent and rude can none the
> less spark a discussion.  The general question of taking uniform
> floating point numbers in [0, 1) and generating uniform directions is an
> interesting one.  And there are many other related questions such as
> picking a point on any other surface with equal probability.
> 
if you would be to much polite (a bit rude you could say though i dont use this word) for blabblers (iq 50 content makers) than this group will drown in balabling

a bit of discipline is needed... good example are trolls who feed arogant spaming moron dik and help him to spam and trollize this group in iq 20 threads making this place like some den of imbeciles

also various idiot of type "google it" "it cant be done" "i answer only to say that i has nothing to say" also should be treated with a dose of discipline imo 9as they are idiots, and maybe not idiots but medicores who like to kill time by blabling)

i would personally to make this group discussing some more creative usefull and interesting topics (in 'modern c' spirit, i coud say) and thats what i talk not a first time

this is hovever hard work and i dont think if its at all possible - but it would be better (than repaating 'dull c beaurocracy' with common feed of idiots like hodgin and its pathological and depressing stupidity affairs)

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

#144213

W dniu piątek, 31 maja 2019 16:42:21 UTC+2 użytkownik fir napisał:
> W dniu piątek, 31 maja 2019 16:23:00 UTC+2 użytkownik Ben Bacarisse napisał:
> > mark.bluemel@gmail.com writes:
> > 
> > > On Friday, 31 May 2019 02:08:57 UTC+1, Ben Bacarisse  wrote:
> > >> Some of fir's questions might help revive
> > >> xxxx.xxxxxxxxxx (though if there is an active graphics group, that
> > >> would be better still).
> > >
> > > I don't think inflicting fir on further newsgroups is a kind thing to do,
> > > but I'm an iq 50 blaber.
> > 
> > comp.programming is dead.  But someone incoherent and rude can none the
> > less spark a discussion.  The general question of taking uniform
> > floating point numbers in [0, 1) and generating uniform directions is an
> > interesting one.  And there are many other related questions such as
> > picking a point on any other surface with equal probability.
> > 
> if you would be to much polite (a bit rude you could say though i dont use this word) for blabblers (iq 50 content makers) than this group will drown in balabling
> 
> a bit of discipline is needed... good example are trolls who feed arogant spaming moron dik and help him to spam and trollize this group in iq 20 threads making this place like some den of imbeciles
> 
> also various idiot of type "google it" "it cant be done" "i answer only to say that i has nothing to say" also should be treated with a dose of discipline imo 9as they are idiots, and maybe not idiots but medicores who like to kill time by blabling)
> 
> i would personally to make this group discussing some more creative usefull and interesting topics (in 'modern c' spirit, i coud say) and thats what i talk not a first time
> 
> this is hovever hard work and i dont think if its at all possible - but it would be better (than repaating 'dull c beaurocracy' with common feed of idiots like hodgin and its pathological and depressing stupidity affairs)

one could say that is part of general discussion of what that group should be

i could say that this kind of group could have separate 'wings' as there are some
people interested only or mostly in 'c bearoucracy' (i mean not c but standard and given pdf or set of pdf describing it, dull thing for me) one other could have to want to discuss 'c extensions' 
(good for me, sometimes, but only if sane not a trash, and not to much) other for 'fundamental concepts' yet other for 'real c coding' - i mean all of it it could have place (unless maybe its to much iq 50)

anybody though imo could agree that life of spamer dik is not quite suitable to be main (or even side topic of this group) if this group can be more healthy place again (this 'rude' remark is especially pointed to trolls feeding that idiot and allowing those imbecile content eat this place more and more)

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

#144177

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?

-- 
Rick C. Hodgin

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

#144179

On 31/05/2019 13:20, 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?
> 

I couldn't see the problem at first. For example you could generate 
random latitude/longitude coords of +/- 90 and +/- 180 degrees, and plot 
those on a sphere. They ought to be randomly distributed.

But it's easy to see that in the areas nearer the poles, the points 
would be more closely clustered. They would be properly spread out only 
on a Mercator projection.

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

#144209

Bart <bc@freeuk.com> writes:

> On 31/05/2019 13:20, 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?
>>
>
> I couldn't see the problem at first. For example you could generate
> random latitude/longitude coords of +/- 90 and +/- 180 degrees, and
> plot those on a sphere. They ought to be randomly distributed.
>
> But it's easy to see that in the areas nearer the poles, the points
> would be more closely clustered. They would be properly spread out
> only on a Mercator projection.

I'd have to think about that, but map projections are one way to
go.  Pick any rectangular equal-area projection, pick uniform x and y
and then apply the inverse projection to get a point on the sphere.

-- 
Ben.

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

#144327

Bart <bc@freeuk.com> writes:
...
> I couldn't see the problem at first. For example you could generate
> random latitude/longitude coords of +/- 90 and +/- 180 degrees, and
> plot those on a sphere. They ought to be randomly distributed.
>
> But it's easy to see that in the areas nearer the poles, the points
> would be more closely clustered. They would be properly spread out
> only on a Mercator projection.

The number of points per steradian generated by your algorithm rises to
infinity as you get closer to the poles. The Mercator projection expands
in scale to infinity as it approaches the poles. However, the scale
increases faster than the density of the points you're generating, so
the density of the points actually drops as you approach the poles in
the Mercator projection.

Your algorithm  produces points that are evenly distributed in any
equirectangular projection
<https://en.wikipedia.org/wiki/Equirectangular_projection>

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

#144182

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.
 

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

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

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

csiph-web