Hacker News Reader

Comment by quickthrower2 | Hacker News Reader

Floating point values are not numbers. They are ranges. They are approximately a field like entity-ish.

Floating point values are binary scientific notation with a fixed precision. All of the unintuitive behaviour of floats is repeated if you imagine conducting decimal calculations yourself in said scientific notation, with intermediate rounding at every step.

Floats are only ranges in that each real number (within the overall range limit) has a unique floating point representation to which it is closest, up to rounding at the precise interval boundary.

Floats can be extended to interval arithmetic, but doing so requires the extra work of keeping track of interval limits. When calculations lose precision (through cancellation of digits in the floating point representation), the interval of uncertainty is larger than the floating point precision.

IEEE 754 floating point are numbers, they are not ranges. Every operation rounds to a representable number in the set.

In what way do they behave like ranges?

I generally prefer to think of them as they are: able to represent a subset of the rationals, plus a couple other weird values, but not a field, and importantly, not obeying any of the usual algebraic laws with arithmetic.

Yep. Floating point addition is not even associative, so they're not only not a field, but not a ring, not a group, nor even a monoid.

Can you point me to a reference?

Every floating point article (including IEEE 754) I've seen treats normal floating point numbers as dyadic rationals.

Everyone is correcting you, but no one is pointing out the real culprit. Floating point operations are not the same as math operations (i.e. +, -, *, / behave differently).

I think what you mean here is that floating point numbers and the usual operators (+,*) and inverses (-,/) do not work the same as Reals (i.e. they don't form a field), but people often behave as if they do.

This is a common confusion.

IEEE 754 is well defined so that $a+b=b+a$ But it can't give you warranty that $(a+b)+c=a+(b+c)$ (well known error propagation issue)

IEEE guarantees commutativity, but does not guarantee the correctness of a+b.

My point is that floating point numbers are real numbers, but the usual operations on them will not give you the same results as the operations on real numbers.

IEEE does guarantee the correctness of a+b in the sense that it will return the floating-point number that is closest to the real number that would've been computed with infinite precision.

There's no randomness or fuzziness in floating-point rounding.

> IEEE does guarantee the correctness of a+b in the sense that it will return the floating-point number that is closest to the real number that would've been computed with infinite precision.

Until you deal with overflow.

And to be frank, this is just redefining "correctness". If you want to view FPs as real numbers (which they are), there's nothing wrong with pointing out that real number operations will give you incorrect results (even ignoring overflow).

> There's no randomness or fuzziness in floating-point rounding.

I did not imply there was.

FP are part of R, like Q or D sets. (I think it should be considered/seen as a subset of decimal numbers set.)

Nothing I said implied they weren't.

I don't think you can see them as a range. Sure, you can think of the float representation of 0.1 and 0.2 as a small range around those values, but what does that make 0.1 + 0.2, or 0.1 * 0.2, or 0.1 ** 0.2? Now the resulting float no longer represents the range of potential conversion error.

And at the same time, integer values (up until some decently high numbers) are represented correctly, so they would need a different range.

Reply on news.ycombinator.com