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}

S  M  T  W  T  F  S 





1

2
(2) 
3
(12) 
4
(16) 
5
(43) 
6
(22) 
7
(35) 
8
(4) 
9
(5) 
10
(6) 
11
(2) 
12
(17) 
13
(5) 
14
(8) 
15
(5) 
16
(10) 
17
(11) 
18
(6) 
19
(14) 
20
(1) 
21

22
(2) 
23
(8) 
24
(2) 
25
(1) 
26
(4) 
27
(31) 
28
(28) 
29
(1) 
30
(4) 
31
(12) 
From: Sam McGrath <sammy@s2...>  20040110 22:50:11

> His accompanying article from Dr. Doobs about the hash function is here: > > http://burtleburtle.net/bob/hash/doobs.html Dr. Doobs? (: Another resource you might look for ideas is the open source library glib. It contains hashing functions of several varieties. Sam McGrath S2 Games http://www.s2games.com 
From: Sergey Nenakhov <asm@kr...>  20040110 21:59:44

> http://www.google.com/search?q=perfect+minimal+hashing&ie=UTF8&oe=UTF8 I should have examined this more carefully before bothering this mailing list. Thanks for pointing to Dr. Doobs article. Sergey. 
From: Matt Pharr <mattgdalgorithms@ph...>  20040110 20:40:39

Sergey Nenakhov <asm@...> writes: > Can you share some experience in hashing arbitrary memory? Actually I need > to hash a fixed size structure, with frequent sequences of zero bits at > fixed offsets. Bob Jenkins has a wellregarded hash function for arbitrary data, available here: http://burtleburtle.net/bob/c/lookupa.c His accompanying article from Dr. Doobs about the hash function is here: http://burtleburtle.net/bob/hash/doobs.html It seems to be pretty carefully engineered to be robust to the kinds of issues you mention above. > I will appreciate if you share some resources on perfect minimal hashing. A google search comes up with an enormous number of goodlooking resources on this. Have you tried that? http://www.google.com/search?q=perfect+minimal+hashing&ie=UTF8&oe=UTF8 matt  Matt Pharr matt@... <URL:http://graphics.stanford.edu/~mmp>; ======================================================================= In a cruel and evil world, being cynical can allow you to get some entertainment out of it. Daniel Waters 
From: Sergey Nenakhov <asm@kr...>  20040110 20:13:07

Hi! Can you share some experience in hashing arbitrary memory? Actually I need to hash a fixed size structure, with frequent sequences of zero bits at fixed offsets. I will appreciate if you share some resources on perfect minimal hashing. Thanks, Sergey. 
From: Stephen Clibbery <s.clibbery@bl...>  20040110 15:52:57

OK, looks like my intuition got it wrong (again)... :) Been playing with this all afternoon, and while you definitely only need to search the positive quadrant, you do still seem to need roll to closely fit an arbitrarily oriented cuboid. So I guess I have to decide whether to keep the brute force (which isnt too slow, really, especially with some optimsations) or attempt some kind of actual minimisation search over the quadrant/roll search space. Cheers, Steve.  Original Message  From: "Stephen Clibbery" <s.clibbery@...> To: <gdalgorithmslist@...> Sent: Saturday, January 10, 2004 12:23 PM Subject: [Algorithms] NearOptimal OBBs > Hi All, > > I need to knock up a routine to get approximately optimal OBBs fairly > quickly. Im aware of a bunch of algo's, including covariancebasis, > facealignedtoconvexhullface, and brute force (testing a bunch of > orientations evenly distributed over a sphere and picking the best). > > Im currently thinking about a brute force approach, because its simple, > robust and linear time. Now, I reckon that due to the symmetry of the 3 box > axes, I only need to test a bunch of directions in the positive quadrant (is > that the right word? I mean oneeighth by volume) of the sphere, since all > other orientations will be covered using directions from this quadrant but > with other OBB axes. > > To try and clarify what I mean, lets say that the direction from the > quadrant determines the direction of the OBBs z axis. Then directions where > the z axis needs to point in a different quadrant will actually be covered > by cases where the z axis points into the positive quadrant but one of the > _other_ axes (or its opposite) points in the direction we require. Since we > then build the box from scratch for that orientation, its totally irrelevant > _which_ axis is pointing that way, and also irrelevant whether its the > actual direction of the axis thats pointing that way, or the 'opposite' > direction (the negative of the axis'). Hence we only need to test directions > in the positive quadrant. Does that sound reasonable? > > Then it comes to 'roll'. For each of these directions on the quadrant, the > orientation can be rolled around. Now I can do more brute force on that (or > even try to find an optimal roll angle), but what Im wondering (but can't > quite get my head round) is whether those roll orientations will actually be > covered by nonrolled orientations from _other_ directions anyway, thus > meaning I dont have to bother rolling at all. My intuition reckons I dont > need to worry about roll, but I can't think of either a way to visualise > why, or a concrete counterexample... > > As an example of where this _does_ work, imagine that we want an orientation > pointing straight down the initial z axis, but rolled (so the only > orientation change is the roll, if you like). Its possible to get the 'same' > box by rotating the z axis 90 degrees to where the x axis used to be, then > 'pitching' it up until either it or the y axis gives the correct > orientation. In effect now, instead of pointing down the z axis and rolling, > we are reorienting the z axis and pitching, so that we effectively point > along the x axis and roll around that. Since this new direction is still in > the original quadrant, and without any roll on it, it will be tested and > found, hence we can ignore the roll angle on the tests... > > Can anyone else better at visualising orientations than me tell me if this > is a good general result? :) > > Cheers, > Steve. > > > >  > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Stephen Clibbery <s.clibbery@bl...>  20040110 12:22:54

Hi All, I need to knock up a routine to get approximately optimal OBBs fairly quickly. Im aware of a bunch of algo's, including covariancebasis, facealignedtoconvexhullface, and brute force (testing a bunch of orientations evenly distributed over a sphere and picking the best). Im currently thinking about a brute force approach, because its simple, robust and linear time. Now, I reckon that due to the symmetry of the 3 box axes, I only need to test a bunch of directions in the positive quadrant (is that the right word? I mean oneeighth by volume) of the sphere, since all other orientations will be covered using directions from this quadrant but with other OBB axes. To try and clarify what I mean, lets say that the direction from the quadrant determines the direction of the OBBs z axis. Then directions where the z axis needs to point in a different quadrant will actually be covered by cases where the z axis points into the positive quadrant but one of the _other_ axes (or its opposite) points in the direction we require. Since we then build the box from scratch for that orientation, its totally irrelevant _which_ axis is pointing that way, and also irrelevant whether its the actual direction of the axis thats pointing that way, or the 'opposite' direction (the negative of the axis'). Hence we only need to test directions in the positive quadrant. Does that sound reasonable? Then it comes to 'roll'. For each of these directions on the quadrant, the orientation can be rolled around. Now I can do more brute force on that (or even try to find an optimal roll angle), but what Im wondering (but can't quite get my head round) is whether those roll orientations will actually be covered by nonrolled orientations from _other_ directions anyway, thus meaning I dont have to bother rolling at all. My intuition reckons I dont need to worry about roll, but I can't think of either a way to visualise why, or a concrete counterexample... As an example of where this _does_ work, imagine that we want an orientation pointing straight down the initial z axis, but rolled (so the only orientation change is the roll, if you like). Its possible to get the 'same' box by rotating the z axis 90 degrees to where the x axis used to be, then 'pitching' it up until either it or the y axis gives the correct orientation. In effect now, instead of pointing down the z axis and rolling, we are reorienting the z axis and pitching, so that we effectively point along the x axis and roll around that. Since this new direction is still in the original quadrant, and without any roll on it, it will be tested and found, hence we can ignore the roll angle on the tests... Can anyone else better at visualising orientations than me tell me if this is a good general result? :) Cheers, Steve. 