5 ms·

Floats are not evil. They are just not as intuitive as integers because it is impossible to represent every possible rational number in the range with a fixed n

by nom 10y ago

Floats are not evil. They are just not as intuitive as integers because it is impossible to represent every possible rational number in the range with a fixed number of bits. Once you get that, everything makes sense.

monochromatic 10y ago
That does not make sense of getting a failure from assert x/y == x/y
- mikeash 10y ago
  Properly implemented floats will never fail that (barring NaN). That gcc sometimes does is a compiler bug, not a float problem.
- cellularmitosis 10y ago
  I agree. Explaining that assertion requires explaining that the x87 FPU is providing a leaky abstraction. If you ask for double math, it gives you a result which is a long double while it resides in a register, and then becomes a double when moved to RAM. There are some cases where direct comparison of floating point values is what you want, and this issue can still bite you even then.
  - int_19h 10y ago
    For x87, it's not a leaky abstraction - it fully supports 80-bit floats as a type, and documents that its registers are 80-bit, and so are operations on them. There's nothing abstract about it. The bug is that GCC is utilizing the (documented, by-design) x87 behavior in a way that causes it to produce the wrong result, for the sake of performance.
    - abstractbeliefs 10y ago
      >compiler developers do unintuitive but technically legal thing in the name of performance I still think the relationship between compiler developers and developer-users is toxic as fuck, but as long as we keep comparing compilers by increasingly anal microbenchmarks instead of increasingly anal "correct in practice" tests, I don't see why we continue to find this a surprise. When we demand better performance, compiler developers are going to exploit undefined behavior as well as other language "loopholes" that don't make intuitive sense. Perhaps a new focus on correctness in practice would change this.

by nom 10y ago

monochromatic 10y ago

That does not make sense of getting a failure from assert x/y == x/y

mikeash 10y ago
Properly implemented floats will never fail that (barring NaN). That gcc sometimes does is a compiler bug, not a float problem.
cellularmitosis 10y ago
I agree. Explaining that assertion requires explaining that the x87 FPU is providing a leaky abstraction. If you ask for double math, it gives you a result which is a long double while it resides in a register, and then becomes a double when moved to RAM. There are some cases where direct comparison of floating point values is what you want, and this issue can still bite you even then.
- int_19h 10y ago
  For x87, it's not a leaky abstraction - it fully supports 80-bit floats as a type, and documents that its registers are 80-bit, and so are operations on them. There's nothing abstract about it. The bug is that GCC is utilizing the (documented, by-design) x87 behavior in a way that causes it to produce the wrong result, for the sake of performance.
  - abstractbeliefs 10y ago
    >compiler developers do unintuitive but technically legal thing in the name of performance I still think the relationship between compiler developers and developer-users is toxic as fuck, but as long as we keep comparing compilers by increasingly anal microbenchmarks instead of increasingly anal "correct in practice" tests, I don't see why we continue to find this a surprise. When we demand better performance, compiler developers are going to exploit undefined behavior as well as other language "loopholes" that don't make intuitive sense. Perhaps a new focus on correctness in practice would change this.