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}

S  M  T  W  T  F  S 


1
(5) 
2
(6) 
3
(15) 
4
(20) 
5
(18) 
6
(4) 
7
(3) 
8
(14) 
9
(21) 
10
(24) 
11
(5) 
12
(12) 
13
(7) 
14

15
(6) 
16
(13) 
17
(1) 
18
(6) 
19
(8) 
20
(6) 
21
(1) 
22
(6) 
23
(11) 
24
(21) 
25
(8) 
26
(15) 
27
(25) 
28
(8) 
29
(19) 
30
(26) 




From: Gareth Lewin <GLewin@cl...>  20020416 19:36:31

Hi. Does anyone have code or an algorithm to get the intersection between a swept sphere(Capsule/think ray) vs a triangle ? ___________________ Regards, Gareth Lewin 
From: Gareth Lewin <GLewin@cl...>  20020416 19:33:33

Graphic Gems : http://www.acm.org/pubs/tog/GraphicsGems/gems/TriPoints.c Original Message From: Carsten Dachsbacher [mailto:carsten@...] Sent: 16 April 2002 18:11 To: GDAlgorithmslist@... Subject: [Algorithms] random distributed points on triangles i need to generate many, well distributed points on triangles. what i did is the following: i decided to use barycentric coordinates. with a pseudo random number generator i generate pairs (two floats u/v), which fulfill the u+v<=1 criteria. for each new sample point on a triangle i generate 30 u/v pairs and take the one, with the greatest distance from all other u/v pairs. the problem is, that i dont get the good result i expected (the points seem not to be that good distributed). the reason could be the usage of barycentric coordinates with long narrow triangles. any (better) ideas ? thanks for help, Carsten Dachsbacher 
From: <phil_wilkins@pl...>  20020416 18:05:00

That's the method I use. The reason for inversion clause is that you're actually generating an even distribution over the parallelogram formed by two of the triangle's edges, then mapping the points outside the actual triangle, back into the triangle. If you generate b by subtracting it from a, c will always be zero, and your distribution will be uneven. If you generate b by randomising over the range 1a, your distribution will also be uneven. Cheers, Phil PS ....and if you're random number generator is crap, your distribution will also be crap. "Andrew Jones" <andrew@...> To: "GdalgorithmsList@..." Sent by: <gdalgorithmslist@...> gdalgorithmslistadmin@... cc: eforge.net Subject: RE: [Algorithms] random distributed points on triangles 04/16/2002 10:23 AM The code I use to do this seems to be the following. I think I would notice if it didn't work and it looks like I got the basic method from somewhere else. The key thing seems to be inverting a and b if their sum is greater than 1. static void MakeRndBarycentric( f32 *pF1, f32 *pF2, f32 *pF3) { //Returns three random numbers between 0 and 1 where a+b+c=1 f32 a,b,c; a= SpRandom0to1(); b= SpRandom0to1(); if( a+b > 1.0f) { a= 1.0f a; b= 1.0f b; } c= 1.0fab; *pF1= a; *pF2= b; *pF3= c; } Andrew Jones Sick Puppies Empire Interactive Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Carsten Dachsbacher Sent: 16 April 2002 18:11 To: GDAlgorithmslist@... Subject: [Algorithms] random distributed points on triangles i need to generate many, well distributed points on triangles. what i did is the following: i decided to use barycentric coordinates. with a pseudo random number generator i generate pairs (two floats u/v), which fulfill the u+v<=1 criteria. for each new sample point on a triangle i generate 30 u/v pairs and take the one, with the greatest distance from all other u/v pairs. the problem is, that i dont get the good result i expected (the points seem not to be that good distributed). the reason could be the usage of barycentric coordinates with long narrow triangles. any (better) ideas ? thanks for help, Carsten Dachsbacher _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: <christer_ericson@pl...>  20020416 17:44:56

Thatcher Ulrich wrote: >[...] I think the deal with the implied one is >that it prevents the zeros from consuming a whole bit. Otherwise the >23 mantissa bits would yield only 22 bits of effective precision. The deal with the implied bit is that it is an artifact of the normalization and the binary representation. Since the first bit of a normalized binary FP number V is always one (except for V=0) it makes perfect sense not storing it and thus gaining one bit of precision. You couldn't have an implied bit (or bits) with a nonbinary representation, making a strong argument for a binary representation just for the reason of getting extra precision for free. >Also, the sign bit means you get the precision on both sides of the >origin, which is why it's helpful to center your world at the origin. Yes, this is a very important point. Christer Ericson Sony Computer Entertainment, Santa Monica 
From: Andrew Jones <andrew@em...>  20020416 17:23:32

The code I use to do this seems to be the following. I think I would notice if it didn't work and it looks like I got the basic method from somewhere else. The key thing seems to be inverting a and b if their sum is greater than 1. static void MakeRndBarycentric( f32 *pF1, f32 *pF2, f32 *pF3) { //Returns three random numbers between 0 and 1 where a+b+c=1 f32 a,b,c; a= SpRandom0to1(); b= SpRandom0to1(); if( a+b > 1.0f) { a= 1.0f a; b= 1.0f b; } c= 1.0fab; *pF1= a; *pF2= b; *pF3= c; } Andrew Jones Sick Puppies Empire Interactive Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Carsten Dachsbacher Sent: 16 April 2002 18:11 To: GDAlgorithmslist@... Subject: [Algorithms] random distributed points on triangles i need to generate many, well distributed points on triangles. what i did is the following: i decided to use barycentric coordinates. with a pseudo random number generator i generate pairs (two floats u/v), which fulfill the u+v<=1 criteria. for each new sample point on a triangle i generate 30 u/v pairs and take the one, with the greatest distance from all other u/v pairs. the problem is, that i dont get the good result i expected (the points seem not to be that good distributed). the reason could be the usage of barycentric coordinates with long narrow triangles. any (better) ideas ? thanks for help, Carsten Dachsbacher 
From: Carsten Dachsbacher <carsten@da...>  20020416 17:10:46

i need to generate many, well distributed points on triangles. what i did is the following: i decided to use barycentric coordinates. with a pseudo random number = generator i generate pairs (two floats u/v), which fulfill the u+v<=3D1 criteria. for each = new sample point on a triangle i generate 30 u/v pairs and take the one, with the greatest distance = from all other u/v pairs. the problem is, that i dont get the good result i expected (the points = seem not to be that good distributed). the reason could be the usage of barycentric = coordinates with long narrow triangles. any (better) ideas ? thanks for help, Carsten Dachsbacher 
From: jeffrey Rainy <jrainy@ma...>  20020416 17:01:29

You meant : http://www.lahey.com/float.htm http://www2.hursley.ibm.com/decimal/=20 ? :) J. Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Norman Vine Sent: Tuesday, April 16, 2002 12:45 To: gdalgorithmslist@... Subject: RE: [Algorithms] world measurement Stephen J Baker writes: > >> > >> > 2. Relative precision is a limited resource with floats. =20 > >Where I got this information from is lost in the mists of time  but >I'm pretty sure it's correct: All you should ever need to know about floating point + http://www.lahey.com/float.html http://ww2.hursley.ibm.com/decimal/ Regards Norman _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 
From: Norman Vine <nhv@ca...>  20020416 16:40:06

Stephen J Baker writes: > >> > >> > 2. Relative precision is a limited resource with floats. > >Where I got this information from is lost in the mists of time  but >I'm pretty sure it's correct: All you should ever need to know about floating point + http://www.lahey.com/float.html http://ww2.hursley.ibm.com/decimal/ Regards Norman 
From: Conor Stokes <cstokes@tp...>  20020416 15:10:45

You're totally correct of course, I should try and remember my engineering classes a bit better :) Conor Stokes > > The 'always on' onebit is not actually stored in an IEEE float > number  it's "assumed". Zero is a specialcase bit pattern > (all zeroes as it happens). > > There *is* only a 23 bit mantissa  but that's not because of a redundant > '1' bit  it's because we have one sign bit and eight exponent bits  so > there are only 23 bits left for the mantissa. (And in a 'double', there > are 52 bits of mantissa). > > In a sense, it is a 24 bit mantissa  but that leading '1' bit doesn't > actually consume any space in the bitpattern for a 'float'. > > Where I got this information from is lost in the mists of time  but > I'm pretty sure it's correct: > >  > > s  a one bit sign flag. > e  the biased exponent (the true exponent plus > 0x081 for shortreal > 0x401 for longreal > f  the mantissa (with the leading '1' bit removed) > > There are some special case numbers: > > if ( e == max and f == 0 ) value is +/1 > if ( e == max and f != 0 ) value is NaN (NotaNumber) > if ( e == 0 and f == 0 ) value is zero > if ( e == 0 and f != 0 ) value is denormalised > (leading '1' bit not removed) > > > Short Real Number (aka 'float'). > Consumes 32 bits (sign, 8 bit exponent and 23 bit mantissa): > > Bit > Most sig Least sig > 31 30 29 28 27 26 25 24 23 22 21 20 .... 0 > s e e e e e e e e f f f .... f > > > Long Real Number (aka 'double'). > Consumes 64 bits (sign, 11 bit exponent and 52 bit mantissa): > > Bit > Most sig Least sig > 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 .... 0 > s e e e e e e e e e e e f f f .... f > >  > > Steve Baker (817)6192657 (Vox/VoxMail) > L3Com/Link Simulation & Training (817)6192466 (Fax) > Work: sjbaker@... http://www.link.com > Home: sjbaker1@... http://www.sjbaker.org > 
From: Thatcher Ulrich <tu@tu...>  20020416 14:42:00

On Apr 16, 2002 at 09:01 0500, Stephen J Baker wrote: > On Tue, 16 Apr 2002, Conor Stokes wrote: > > > > > > > 2. Relative precision is a limited resource with floats. You > > > essentially have 24 bits. If you're modeling the Tour de France, and > > > your Lance Armstrong avatar is 1600km from the origin, he can only > > > move in 0.1m increments! That won't work very well if you have a > > > decent framerate. (Solution: move your origin.) > > > > 24bits? Try 23bits, one bit is always on except when the number is zero. :) > > The 'always on' onebit is not actually stored in an IEEE float > number  it's "assumed". Zero is a specialcase bit pattern > (all zeroes as it happens). > > There *is* only a 23 bit mantissa  but that's not because of a redundant > '1' bit  it's because we have one sign bit and eight exponent bits  so > there are only 23 bits left for the mantissa. (And in a 'double', there > are 52 bits of mantissa). > > In a sense, it is a 24 bit mantissa  but that leading '1' bit doesn't > actually consume any space in the bitpattern for a 'float'. > > Where I got this information from is lost in the mists of time  but > I'm pretty sure it's correct: All true. Poor Lance still sees 2^23 bits of precision  I coded up a quickie test to verify. I think the deal with the implied one is that it prevents the zeros from consuming a whole bit. Otherwise the 23 mantissa bits would yield only 22 bits of effective precision. Also, the sign bit means you get the precision on both sides of the origin, which is why it's helpful to center your world at the origin.  Thatcher Ulrich <tu@...> http://tulrich.com 
From: Stephen J Baker <sjbaker@li...>  20020416 14:00:56

On Tue, 16 Apr 2002, Conor Stokes wrote: > > > > 2. Relative precision is a limited resource with floats. You > > essentially have 24 bits. If you're modeling the Tour de France, and > > your Lance Armstrong avatar is 1600km from the origin, he can only > > move in 0.1m increments! That won't work very well if you have a > > decent framerate. (Solution: move your origin.) > > 24bits? Try 23bits, one bit is always on except when the number is zero. :) The 'always on' onebit is not actually stored in an IEEE float number  it's "assumed". Zero is a specialcase bit pattern (all zeroes as it happens). There *is* only a 23 bit mantissa  but that's not because of a redundant '1' bit  it's because we have one sign bit and eight exponent bits  so there are only 23 bits left for the mantissa. (And in a 'double', there are 52 bits of mantissa). In a sense, it is a 24 bit mantissa  but that leading '1' bit doesn't actually consume any space in the bitpattern for a 'float'. Where I got this information from is lost in the mists of time  but I'm pretty sure it's correct:  s  a one bit sign flag. e  the biased exponent (the true exponent plus 0x081 for shortreal 0x401 for longreal f  the mantissa (with the leading '1' bit removed) There are some special case numbers: if ( e == max and f == 0 ) value is +/1 if ( e == max and f != 0 ) value is NaN (NotaNumber) if ( e == 0 and f == 0 ) value is zero if ( e == 0 and f != 0 ) value is denormalised (leading '1' bit not removed) Short Real Number (aka 'float'). Consumes 32 bits (sign, 8 bit exponent and 23 bit mantissa): Bit Most sig Least sig 31 30 29 28 27 26 25 24 23 22 21 20 .... 0 s e e e e e e e e f f f .... f Long Real Number (aka 'double'). Consumes 64 bits (sign, 11 bit exponent and 52 bit mantissa): Bit Most sig Least sig 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 .... 0 s e e e e e e e e e e e f f f .... f  Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://www.sjbaker.org 
From: Thatcher Ulrich <tu@tu...>  20020416 13:18:31

On Apr 16, 2002 at 06:25 +0800, Conor Stokes wrote: > > > > 2. Relative precision is a limited resource with floats. You > > essentially have 24 bits. If you're modeling the Tour de France, and > > your Lance Armstrong avatar is 1600km from the origin, he can only > > move in 0.1m increments! That won't work very well if you have a > > decent framerate. (Solution: move your origin.) > > 24bits? Try 23bits, one bit is always on except when the number is > zero. :) Whoops, you're right. Lance can only move in ~0.2m increments...  Thatcher Ulrich <tu@...> http://tulrich.com 
From: Conor Stokes <cstokes@tp...>  20020416 10:18:36

> > 2. Relative precision is a limited resource with floats. You > essentially have 24 bits. If you're modeling the Tour de France, and > your Lance Armstrong avatar is 1600km from the origin, he can only > move in 0.1m increments! That won't work very well if you have a > decent framerate. (Solution: move your origin.) 24bits? Try 23bits, one bit is always on except when the number is zero. :) Conor Stokes 