Question

Is there a general best practice strategy for dealing with floating point inaccuracy?

The project that I’m working on tried to solve them by wrapping everything in a Unit class which holds the floating point value and overloads the operators. Numbers are considered equal if they “close enough,” comparisons like > or < are done by comparing with a slightly lower or higher value.

I understand the desire to encapsulate the logic of handling such floating point errors. But given that this project has had two different implementations (one based on the ratio of the numbers being compared and one based on the absolute difference) and I’ve been asked to look at the code because its not doing the right, the strategy seems to be a bad one.

So what is best the strategy for try to make sure you handle all of the floating point inaccuracy in a program?

Answer 1

You want to keep data as dumb as possible, generally. Behavior and the data are two concerns that should be kept separate.

The best way is to not have unit classes at all, in my opinion. If you have to have them, then avoid overloading operators unless it has to work one way all the time. Usually it doesn’t, even if you think it does. As mentioned in the comments, it breaks strict weak ordering for instance.

I believe the sane way to handle it is to create some concrete comparators that aren’t tied to anything else.

struct RatioCompare {
  bool operator()(float lhs, float rhs) const;
};

struct EpsilonCompare {
  bool operator()(float lhs, float rhs) const;
};

People writing algorithms can then use these in their containers or algorithms. This allows code reuse without demanding that anyone uses a specific strategy.

std::sort(prices.begin(), prices.end(), EpsilonCompare());
std::sort(prices.begin(), prices.end(), RatioCompare());

Usually people trying to overload operators to avoid these things will offer complaints about “good defaults”, etc. If the compiler tells you immediately that there isn’t a default, it’s easy to fix. If a customer tells you that something isn’t right somewhere in your million lines of price calculations, that is a little harder to track down. This can be especially dangerous if someone changed the default behavior at some point.