f64-only implementation vs. generic implementation

[tinko92]

This library is entirely implemented for f64 and in comments, it is stated that f32 inputs will be converted to f64 without loss of precision. This is true and the provided predicates will be just as correct/robust for f32-values by doing it this way, same for e.g. half-floats or bfloats. For numbers types with higher precision than f64, though, it could return incorrect results.

Numerically, this promotion is not required and afaiu doesn't do anything useful for the computation, except in cases were f32 could underflow/overflow. Shewchuk's algorithms, according to the proofs in his paper, work for all floating-point types that have at least 6 bits of precision for their significands and round-to-even behavior for their basic operations (I think even 4 bits would be sufficient if FMA was used instead of splitting in Two_Product). His implementation allowed switching between types by changing the define for REAL.

So, if e.g. f32 inputs are provided, all computations could be done in f32. This probably wouldn't change anything performance-wise for modern x86 CPUs other than requiring less stack space (I think at most ~16KB rather than ~32KB in insphere adaptive), but it might be more beneficial for other platforms where performance differs between half, single and double precision like GPUs or other CPU architectures than x86. I understand that Rust has a concept of generic functions similar to C++ templates, so, as I understand, the implementation could in principle be made to work for arbitrary floating-point types. I'm new to Rust so I might miss something, though.

Creating a PR to make all provided predicates generic to work for different floating-point types would require some work/learning about rust generics, so I first wanted to ask whether there would be interest from this project in such a PR.