Hacker News Reader

Comment by fnord77 | Hacker News Reader

> a fuel estimation program for a small cargo airline > ...floating point computations

Hello, rounding errors. Oh hell no.

You make a valid point, pity to see it downvoted. Please keep in mind that in many dialects of BASIC you didn't have more datatypes than 'string' and 'float', and that the original program used floats. Even so, it is definitely possible to make reliable software using floating point, you just have to know exactly what you are doing and you will spend a lot of time on tests to ensure that you do not end up with nonsense output in edge cases.

Floating point is used regularly in avionics and other fields involving critical computations, it is not the floating point data type itself that is problematic, what is problematic is poorly understanding the underlying implementation details and what kind of limitations that will cause.

A good example is trying to count integers with more bits than the underlying precision of the implementation will allow. But in this particular case floating point would have been my 'tool of choice' anyway, fixed point would have introduced a lot of complications for very little gain - if any - gain and would not be worth it.

So in many cases I would agree with you that rounding errors could cause huge problems but in this particular case the inputs were in ranges where this could not happen, the software was tested exhaustively across all input ranges to ensure well defined behavior.

Please. Don't kneejerk. Any floating point errors will be multiple orders of magnitude smaller than than the accuracy of either the fuel gauges or the pumps.

Not if you use multiplication and floats.

We certainly cannot use it for money, for example. Most shops I know of have fancy decimal libraries they never get to use because an unsigned long unit of centicents is simpler, predictable and easy to encode and assume client software will have the same rounding strategy.

Fixed point isn't any better than floating point.

If anything errors in floating point numbers are graceful and give you a lot of leeway before they become catastrophic. Fixed point works until you hit 2(n-1) bits then probably breaks unexpectedly. Where n is the last exponent you have seen in business.

Fixed point libraries tend to be better because good ones can cleanly identify when they're unable to continue and often tell you why.

Floating point libraries can't even do this.

Just like the variation in the output voltage of a pin might be amplified by an op-amp. These things are taken into account by engineers, it's their duty to mathematically prove they're not an issue and fix it if it is.

Did you know in the US it's essentially against the law to use floating point math on currency? The situation is more complex than I simplified here, however the complexity is on the order than you'd need a lawyer to explain it to you to really appreciate it.

You can call it a knee-jerk reaction, but the law itself clearly has that bias, and for good reason.

All regulations were paved in blood.

Which law covers that?

Not just the US, IIRC financial institutions around the world are required to do decimal rounding. OTOH I don't see why you would even use floating point for money. Just scale your integers to the required precision (and make sure you've got enough bits for the kind of amounts you need to be able to handle) and you're good.

Having worked in both aerospace (GP's comment) and e-commerce (your comment), I can tell you that these are not the same problem and do not require the same solution.

First week on the job in e-commerce, I educated the junior engineers on the problems that can arise when using floating point math with currencies, then prioritized work to remove any floating point math from the code. That doesn't mean I wouldn't use floating point anywhere else. In aerospace in particular, I've used floating-point without issue, so I don't think you're point about currencies has any relevancy to the GP's comment regarding fuel estimation.

fun fact - before 2001, the US stockmarket traded in sixteenths not decimals

That may or may not be true depending on how the program is written. All of the math can be correct, but make the mistake of relying on floating point math having the associative and distributive properties (it doesn't). I'd imagine the most trouble prone part of the fuel load calculation to be the cancellation error introduced by naively determining the derivative of some function.

E.g.

  step = 0.001
  fprime = (f(x+step) - f(x)) / step

Having a tiny step value means substantially worse error due to rounding. Instead of being a tiny fraction of a percent off now you've got something potentially dangerous like 30% off. You can't just handwave away loss of precision as something to ignore, there are a handful of common pitfalls that will amplify the total error to the point where it's unacceptably high and not intuitive to figure out the cause of the error.

Yeah, it' simple to see in this example. Though it's often harder to see in practice, I once heard/read some interesting advice: Test your software in all four rounding modes. If the software works correctly (and approximately agrees) in all four modes, you're good. (I suppose this assumes that you've got reasonable test coverage.)

Reply on news.ycombinator.com