Hacker News Reader

Comment by TylerE | Hacker News Reader

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.

View on HN

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.)

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.

Reply on news.ycombinator.com