Hacker News Reader

Comment by okl | Hacker News Reader

I'm very annoyed by this title. It's a beginners mistake and FP numbers just are what they are -- a tradeoff between precision, range and efficiency. If you use FP, you should be familiar with its intricacies in the same way a C programmer needs to be aware of unsigned overflows.

View on HN

I agree. Enough already. Isn't this covered in something like week 2 of CS 101? If you've missed that, maybe the literally decades of "ermagerd, floats!" articles would give you a hint.

As someone who's worked in science and finance (modeling, not accounting), floats work just fine, thank you very much. The modeling/accounting split in finance is a legit point of confusion, though.

IEEE 754 floating-point format has been very carefully and deliberately designed by the top experts in the field. When someone "it sucks", that is a guarantee that whatever design he might come up with would suck ten times as much.

Floating point feels to me like a very well designed jack-of-all-trades. They are decent for most tasks, but if you know exactly what you want to do then you can find something that does that particular job better.

This. Sure, floating point numbers come with a footgun, but the title is so clickbaity, would it really hurt to name it: "What I wish I knew about floating numbers before relying on them?"

I think it's common to just not be taught floating points need to be handled a lot differently than whole numbers, so the common experience is getting bit by it. I don't remember ever being taught that in my traditional schooling, personally.

This is a good link to send to people: https://floating-point-gui.de/

I remember covering how floating point were stored, but I don’t remember going all that deep into how that affected arithmetic.

also: https://0.30000000000000004.com/

Nooo unsigned integers suck, if you subtract 5 from 3 what would you get? Then I had a stroke of genius and figured it out, I have no idea what I'm doing.

The problem is that the creeping imprecision actually comes from the exponential mismatch, not the actual float itself. If we were inputting floats in binary format, most of our problems would disappear. But since we think in decimal, we input in decimal, and then magical complicated algorithms convert those "decimal" values to the "nearest" binary representation. And then the trouble ensues when we try to use them in calculations and get weird results.

Decimal floats would operate just as we're used to, and would solve 95% of our floating point problems.

> Decimal floats would operate just as we're used to, and would solve 95% of our floating point problems.

It does not in fact solve the problem identified in this blog post (a non-associative issue). It does not solve any of the problems I generally see mentioned in topics like multiplayer video game desyncs (math libraries on different platforms don't return the same results). It's a pretty bold assertion that "95% of our floating point problems" would be solved.

Every single one of the problems in the article are due to binary-exponent / decimal-exponent mismatch and the inevitable differences in how different platforms do the conversions. With decimal floats, that problem disappears. There is no converted-it-to-90.34326374227855; all implementations would correctly have 90.34326 because there's no lossy conversion-to-binary-exponent to make; it's just stored in decimal with a decimal exponent, the end.

Multiply 90.34326 by 0.1 and then 0.1 again? Once again, all platforms will correctly and EXACTLY give the result 0.9034326. No loss of precision at all. Or do it 0.1 times 90.34326 times 0.1. Same result (exactly the same). Do that with binary floats and you're in for a world of hurt.

> Every single one of the problems in the article are due to binary-exponent / decimal-exponent mismatch and the inevitable differences in how different platforms do the conversions.

The article itself actually started with your assumption... and found it wasn't true. The type conversion wasn't the issue--it was coming back as the same value on all the different systems.

The flaw was that the sum came out wrong depending on the order that it was done. And the input numbers were (if I'm understanding correctly) computed as a / b, for some integer values a and b, which are not generally perfectly precise in decimal or binary floating point.

I think I need to do a blog post on this. I get the same kind of reaction from pretty much anyone I talk to about this, and it takes hours of explanations & diagrams to get them to understand. It's a real shame too, because a correct understanding would have a LOT more people putting pressure on implementors to support decimal floats :/

Reply on news.ycombinator.com