Re: Acceleration Structures For Vertex Snapping

Okay, worst case is different from average case, granted. But since the cell
size in this case is fixed (related to snap distance), the number of mesh
vertices that cell will contain varies with n. An example: if your mesh was
evenly tessellated in space, the number of vertices in a single cell would
be n / k, where k is the number of cells your mesh intersects. That makes
finding the closest vertex an "n / k" operation, which is definitely not
constant time. That is what I meant when I said it was O(n). It would only
be O(1) average case if we had a "vertices per cell" limit we could somehow
enforce, but we don't.

No, that's not true. Hash tables are fast in practice because they do a
> small number of reasonably fast operations in the average case, not
> because they do a large number of operations in a magically ultra-fast
> fashion (which would be the O(N) with tiny constant that you decribe).
>

There's no magic, an O(N) algorithm does not necessarily do N operations.
Hash tables are fast because they run in O(n / k) time, where k is
comparable to or larger than n. If you make k a function of n, as is often
done, then it becomes constant time average case.

-- 
Jeff Russell
Engineer, 8monkey Labs
www.8monkeylabs.com

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev

_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list