Floating point numbers, and why they suck • Hacker News Board

Re: Floating point numbers, and why they suck

#21

Post by adgjlsfhk1 » Fri, Dec 17, 2021, 2:07 PM UTC

RicoElectrico wrote: post #4

I wish that fixed point numbers (as in Qx.y) was a first class citizen in programming languages. As well as saturation arithmetic. Actually I wonder if anybody did a performance/power comparison of using floating point vs fixed point math in some common tasks using modern CPUs with extensive FP support.

Julia has this https://github.com/JuliaMath/FixedPointNumbers.jl. In general, fixed point is a little slower, but it's not awful. Fixed point is really good for small bit-widths in hardware though.

Re: Floating point numbers, and why they suck

#22

Post by spicybright » Fri, Dec 17, 2021, 2:09 PM UTC

pjam wrote: post #19

okl wrote: post #10

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.

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/

Re: Floating point numbers, and why they suck

#23

Post by jwmerrill » Fri, Dec 17, 2021, 2:13 PM UTC

kstenerud wrote: post #6

The problem is that we're still stuck with only binary floating point types in our CPUs and compilers and runtime environments, over a decade after ieee754 released their decimal float spec [1]. Once we finally move away from binary floats, these nasty binary-exponent-decimal-exponent lossy conversions will end (as will the horribly complicated nasty scanf and printf algorithms). This is a solved problem. Our actual…

Decimal floating point still doesn’t have associative addition or multiplication.

Re: Floating point numbers, and why they suck

#24

Post by kstenerud » Fri, Dec 17, 2021, 2:16 PM UTC

jwmerrill wrote: post #23

kstenerud wrote: post #6

The problem is that we're still stuck with only binary floating point types in our CPUs and compilers and runtime environments, over a decade after ieee754 released their decimal float spec [1]. Once we finally move away from binary floats, these nasty binary-exponent-decimal-exponent lossy conversions will end (as will the horribly complicated nasty scanf and printf algorithms). This is a solved problem. Our actual…

Decimal floating point still doesn’t have associative addition or multiplication.

But it can be shaped by rules to be associative enough to be useful for the common case. All you need to do is ensure that your calculations are in no danger of blowing past the max significant digits (much like you'd guard against overflow on integer types). Once you need more range, you switch to a multi-word numeric format (or impose rounding rules).

Re: Floating point numbers, and why they suck

#25

Post by Mikhail_K » Fri, Dec 17, 2021, 2:17 PM UTC

okl wrote: post #10

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.

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.

Re: Floating point numbers, and why they suck

#26

Post by okl » Fri, Dec 17, 2021, 2:19 PM UTC

longemen3000 wrote: post #17

In Julia, there is the `isapprox` function to inexactly compare 2 numbers. (you can use it in infix form: `x≈y`. By default, two numbers are approximately equal if their relative tolerance is less than `sprt(eps(typeof(x))` (around 1e-8 for 64bit Floating point numbers) Using equality to compare 2 floating point numbers doesn't get you anywhere, specially if you are using mathematical functions (the implementation of…

Relative tolerance becomes problematic though if your numbers are very close to zero. (https://randomascii.wordpress.com/2012/02/25/comparing-float...)

Re: Floating point numbers, and why they suck

#27

Post by fiedzia » Fri, Dec 17, 2021, 2:23 PM UTC

> We are sending the data to the warehouse as a float

There is your problem

Re: Floating point numbers, and why they suck

#28

Post by unnouinceput » Fri, Dec 17, 2021, 2:26 PM UTC

And that's why you user "currency" type of style. Both as calculation in your programming language (Go in this article) and in DB (PostgreSQL in this article). Fixed width "floating" number which is actually your largest integer type (64 bits these days, but there are libraries for 128 bits aplenty as well) is your friend.

Re: Floating point numbers, and why they suck

#29

Post by kstenerud » Fri, Dec 17, 2021, 2:27 PM UTC

okl wrote: post #10

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.

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.

Re: Floating point numbers, and why they suck

#30

Post by marcosdumay » Fri, Dec 17, 2021, 2:28 PM UTC

ape4 wrote: post #8

Ancient COBOL had binary coded decimal.

Every database and most programing languages have decimal floating point types. They usually don't use BCD, and instead use some more efficient representation. But anyway, the representation is irrelevant.

By the way, integral BCD (what COBOL did most of the time) is useless.