Support using float instead of double

[ubruhin]

Hi,

It looks like the library currently only supports double. But for platforms with only a single-precision FPU it would be nice to allow using float for performance reasons. From usability point of view, it would be great to make the classes a template so we could pass either float or double as template argument. Alternatively it would also be OK to replace all occurrences of double with an own typedef and e.g. allow switching to float with a define passed to the compiler, or something like that.

Are there any plans in this direction, or would this be totally out of scope of this library?

[abellgithub]

I'm not sure I understand. Are you working on a system that only has single-precision floating-point? Or do you just want the input to be single-precision? Or do you want processing on the GPU itself?

[ubruhin]

Are you working on a system that only has single-precision floating-point?

Yes, basically that's what I mean. But I'm not "working" on such a system - I develop an application which is intended to be portable. When compiling for a typical x86 platform, the application should use double for all floating point operations. But when compiling for an ARM platform which only has a single-precision FPU, the application should use float for all floating point operations. For this library it would mean that input data should be single-precision, and all operations should be performed with single precision (often that's easy, since the functions from <cmath> are overloaded for both float and double, so it will choose the corresponding overload depending on the argument type).

To be more clear, I develop an application using Qt. And Qt provides the typedef qreal which is usually defined as double, but on some platforms it might be defined as float. That's handy for application developers since I don't have to care about the underlying platform. But I'd also need this library to be configurable that way.

[abellgithub]

The issue is that getting decent (and correct) triangulation depends on an appropriate level of precision. I'm not sure that just replacing double with float will yield decent results and behavior. When I've worked on systems without native double-precision, it was emulated by the compiler. This seems like it might be an application where you need that added precision, though it's highly dependent on the actual data.

[ubruhin]

The issue is that getting decent (and correct) triangulation depends on an appropriate level of precision.

But if the input data also has reduced precision, do you think this is still an issue?

When I've worked on systems without native double-precision, it was emulated by the compiler.

Yes of course, but the problem is that this could be very inefficient compared to using float instead. So I'm not sure if the slogan "Probably the fastest C++ open source 2D Delaunay implementation" in your readme is still true on such platforms 🙂

[abellgithub]

The issue is that getting decent (and correct) triangulation depends on an appropriate level of precision.

But if the input data also has reduced precision, do you think this is still an issue?

Absolutely

[ubruhin]

OK so of course I leave it up to you to decide whether the library should also perform well on single-precision FPU or if that's out of scope. At least you now know that there are potential users which would be interested in that feature 🙂 I don't need the library immediately (currently I use another one), but I might reconsider using this library some day in future...

Thanks!

[abellgithub]

Have you tried:

sed/double/float/g

to see if you get results that are OK?

[ubruhin]

Not yet - I might do that once I seriously start evaluating this library for my application 🙂