Maybe I can share some of my experiences when developing Spade.

Support for f32

When investigating different number types for Spade, I started to riddle my code with debug_assert! calls that would check various preconditions, e.g. "Is the given point really on the right side of this edge?". Maybe that is applicable for you as well to detect precision loss as early as possible? Also, lots of randomized tests helped. These tests would usually triangulate some random points and, if no panic occurred during triangulation, perform a sanity check on the triangulation structure. This check would ensure that important invariants (e.g. are the points of triangles always sorted ccw?) or structural requirements (Has every half edge a twin?) are met.

I have had bad experiences with f32 and precision for spade, up to the point that I stopped using it even for very small point sets. However, delaunator seems to be more robust for f64, maybe this robustness is also true for f32.

One last note: I have not had any problems with overflowing f32 or f64 values, their range seems to be large enough for any realistic input set.

Support for integer types

If you decide to support integer coordinates, integer overflow is checked in debug configuration. Also, I noted some divisions ( / ) in your code, those may not work as intended for integer coordinates.

Support for custom number types (BigIntegers, arbitrary precision floats)

When I ran into precision problems back then, my first attempt to fix this was to use arbitrary precision floating point numbers. Besides being terribly slow, they are also very cumbersome to handle as there is no Copy bound on the number type.

Accept other number types #4

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions