Closed mourner closed 5 years ago
hmmm, I hadn't tested delaunay.find on collinear input — pushing a test now; it's already working with your code, so it seems the algorithm does indeed converge to a correct point without the special handling of neighbors for this case.
Hmm, what did that collinear code in neighbors target then? Should we remove it there as well? In theory, collinear input doesn’t have triangles so neighbors as a concept don’t make sense.
In a collinear diagram A B C D E, the neighbors of B are A and C.
I mean, what is A B etc here? We return zero triangles in the triangulation. So neighbors can only make sense in the context of Voronoi cells.
A B C D E are consecutive points on an axis. Their voronoi cells do exist (the blue, orange, green, … areas on the image below); the neighbors of a cell are the cells that are immediately before and after them on the axis (except for the two extremal points which have only 1 neighbor).
Ref. https://observablehq.com/@fil/d3-delaunay-degenerate-cases
Ha I understand your remark after clicking "send". Yes it's a concept with voronoi, not delaunay.
Closes #76 by inlining neighbors loop in
delaunay.find
(so that it doesn't touch a generator). Brings performance back to v4.0.2 levels (~4x faster).Before merging, I guess I should add the collinear handling that's in
neighbors
too?