You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(31) 
2
(28) 
3
(10) 
4
(15) 
5
(22) 
6
(21) 
7
(30) 
8
(30) 
9
(44) 
10
(6) 
11
(5) 
12
(50) 
13
(33) 
14
(61) 
15
(68) 
16
(43) 
17
(24) 
18
(14) 
19
(85) 
20
(33) 
21
(30) 
22
(38) 
23
(1) 
24
(5) 
25
(6) 
26
(6) 
27
(29) 
28
(34) 
29
(81) 
30
(61) 
31
(10) 
From: Peter Bertok <bertok@ge...>  20010311 23:31:54

Because errors accumulate! Crank something through an algo a few trillion times, and even very small errors can become a problem. Double precision numbers are NOT sufficient for a lot of things, like some finiteelement analysis methods, fractals with high zoom factors, certain verylarge matrix problems, etc...  Original Message  From: "Andy Ross" <andy@...> To: <gdalgorithmslist@...> Sent: Saturday, March 10, 2001 6:01 AM Subject: Re: [Algorithms] Multiprecision math libraries > Robert Dibley wrote: > > > > > If anyone also has info on 128bit fixedpoint math libraries > > > that work exceedingly well, I may use that instead. > > > > No references for you, but if you do a little maths I think you'll find 128 > > bit integers would be plenty  it gives you something like the entire > > universe down to micrometre accuracy (ok, I'm exaggerating a little) so > > you won't need to worry about floating point. > > I beg to differ, you're actually UNDER estimating a bit: > > Speed of light: 3 x 10^8 m/s > Length of year: Pi x 10^7 seconds (within a few percent) > Size of visible > universe: 1 x 10^10 light years (a rough age for the universe) > um per meter: 1 x 10^6 > > Multiply that all out, and you get: > > Size of universe in micrometers: 10^32 > > Biggest value representable in 128 bits: 10^38 > > Bingo. So 128 bits actually represents the universe to within > a picometer, not a micrometer. Thbbt! > > More to the point: why on earth would anyone NEED this in a > computer simulation? This is precision to the point of absurdity; > even double precision floating point is more than sufficient for > pretty much anything someone would care to represent. > > Andy > >  > Andrew J. Ross NextBus Information Systems > Senior Software Engineer Emeryville, CA > andy@... http://www.nextbus.com > (510)4203126 Why Wait? > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > 
From: Gil Gribb <ggribb@ra...>  20010311 22:25:55

> Re: frustum planes from matrix: Wow, great one Gil! Here is another then. :) > > To convert Euler Angles to 1 Rotation Matrix, or to convert Euler Angles to > 3 Axis, it is basically conceptually apply 3 angles. > > Since there are 3 angles, there are 6 different orders to apply them in, > which result in 6 different set of equations for the matrix, or for the > axis. And you might change the sign of each angle. So, I look at 48 different possiblities. > 1. Which set of the 6 ordering is the most "correct" one under what > conditions? What are these conditions? How to test for them? (Pseudocode > most welcome.) All of them are correct. My low level systems never use euler angles, but the other programmers using these systems have euler angles as pretty much mandatory. They are very effective at using euler angles to get the work done. I would go so far as to say they are experts at using euler angles. What I do is perform an extensive interview of the programmers who will be using the technology. I not only learn about what they want for euler angles, but what they expect of their coordinate systems in general. That is the big difference between the technology and the use of the technology. My code really does not care which of the 48 possiblities we use. The users of the technology really really care which one we pick. But since they don't see the general case, they can't really even tell you what they want. And when you talk to them, expect to hear some things that make absolutely no sense. But with a carefully worded questionaire, you can tease the information out of them. I can dig up my interview for the coordinate systems of a new engine if you like. After the interview, I write a few key routines that define the conventions they want , EulerAnglesToMatrix() for this specific issue. Once the key routines are written and everybody is happy with them, you don't have to think about it anymore. The conventions my shop wanted was the x,y, and z rotation applied in order with the rotations on the right of the input vector. And with the y rotation negated....shrugs...whatever makes them happy. > 2. What is the "conceptual relationship" between all 6 of these matrices, or > these sets of axes? Conceptually they should lead to some sort of equality > of equivalence in "many" (but not "all") situations. How is that > mathematically explained? What I mean is how do these differently looking > sums of products of sines end up being "same most of the time but not > always"? I dunno, I hate euler angles, except for one or two angle problems. I have much more skill in the matrix domain....linear is easy. So, I pick a convention, convert to matrix, solve my problems there, and hope they don't ask for the solution in terms of euler angles. Gil > > While addressed Gil, it is definitely open to everybody else like Dave > Eberly, Tom Forsyth, etc. > > Corrinne Yu > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Tony Cox <tonycox@mi...>  20010311 21:28:16

>To convert Euler Angles to 1 Rotation Matrix, or to convert Euler Angles to >3 Axis, it is basically conceptually apply 3 angles. > >Since there are 3 angles, there are 6 different orders to apply them in, >which result in 6 different set of equations for the matrix, or for the >axis. > >1. Which set of the 6 ordering is the most "correct" one under what >conditions? What are these conditions? How to test for them? (Pseudocode >most welcome.) Unanswerable, I think. Since the three spatial dimensions are entirely equivalent, we don't consider any one them to be 'special', then no one ordering can have any greater significance than another. Indeed, the only case where Euler angles are really useful is when the rotation angles approach zero and the rotations 'almost' commute  as when constructing an incremental rotation to apply. This corresponds to the case where we don't have to worry about the ordering, which is just as well if we've already established that there is no 'correct' one to pick. >2. What is the "conceptual relationship" between all 6 of these matrices, or >these sets of axes? Conceptually they should lead to some sort of equality >of equivalence in "many" (but not "all") situations. How is that >mathematically explained? What I mean is how do these differently looking >sums of products of sines end up being "same most of the time but not >always"? They're not the same most of the time. They're different almost all of the time. I think the order is significant in all cases except where at least two of the angles are zero (modulo 2pi). Tony Cox  Lead Engineer Windows Gaming Developer Relations Group http://msdn.microsoft.com/directx=20 
From: Corrinne Yu <corrinney@ho...>  20010311 20:56:24

Re: frustum planes from matrix: Wow, great one Gil! Here is another then. :) To convert Euler Angles to 1 Rotation Matrix, or to convert Euler Angles to 3 Axis, it is basically conceptually apply 3 angles. Since there are 3 angles, there are 6 different orders to apply them in, which result in 6 different set of equations for the matrix, or for the axis. 1. Which set of the 6 ordering is the most "correct" one under what conditions? What are these conditions? How to test for them? (Pseudocode most welcome.) 2. What is the "conceptual relationship" between all 6 of these matrices, or these sets of axes? Conceptually they should lead to some sort of equality of equivalence in "many" (but not "all") situations. How is that mathematically explained? What I mean is how do these differently looking sums of products of sines end up being "same most of the time but not always"? While addressed Gil, it is definitely open to everybody else like Dave Eberly, Tom Forsyth, etc. Corrinne Yu 
From: notnot <notnot@xs...>  20010311 00:07:40

May be offtopic, but can someone translate this inline assembly code (compiles with MS VC) to a form that compiles under Linux (gcc, g++)? inline void FloatToInt(int *i, float f) { __asm fld f __asm mov edx,i __asm FRNDINT __asm fistp dword ptr[edx]; } Erwin, http://www.xs4all.nl/~notnot 