Why are floats so cursed? I ask that non-rhetorically. It's not only ye olde NaN!=NaN; like half of the virtual ink spilled on nailing down language semantics also ends up being about arcane float-related esoterica. Is this, e.g., somehow inherent to the problem space? A weird historical clusterfuck? Something else? (Most recently reminded by: https://github.com/rust-lang/unsafe-code-guidelines/issues/471)
@glaebhoerl my theory: floats are cursed because people want real numbers, but real numbers are tricky because actual constructible real numbers have a lot of undesirable properties, like the inability to determine digits. real numbers are a connected type, so the only functions from R to Bool that respect continuity are constant functions. so either we have analog computers, or we must work with approximations. and that leads to shenanigans.
@typeswitch The need to be approximate is indeed *part* of the cursedness (implying non-associativity too) and the part that seems most inescapable. But so much else seems unforced. NaN bit patterns, global mutable fenv, denormals, x87, NaN!=NaN of course, -0 == +0, and there's more I'm probably forgetting. Everything designed by humans has flaws, but why such a concentration.
looking into it, it seems that the design of FP follows mostly from the need for operations to be closed.
NaN is good, actually -- it says "you did something wrong" rather than just giving you a wrong value.
global mutable fenv (& x87 state) is just an ABI issue tho? it's global state, so it's like everything else in these cursed machines -- e.g. registers are global state -- and the point of ABIs is for people to manage all that global state in a compatible way.
@typeswitch I didn't say NaN is bad (by "bit patterns" I mean that there are very many possible NaN representations and this leads to portability/determinism headaches)
Re fenv, see that whole thread I linked... (I agree with https://github.com/rust-lang/unsafe-code-guidelines/issues/471#issuecomment-1772271284, resp. to the extent possible, all this stuff should be specified by immediates on the instruction itself)
