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

This isn't a "culprit" so much as a fact along with 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.

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