NaN-git

> > `-0.0` is parsed as `0.0`. This is not nice because `-0.0` can be generated easily, i.e. > > Fixing this is technically a breaking change, but if you...

> One more "interesting" case is the canonical NaN representation. On x86 it is negative, but all other platforms produce positive NaNs on invalid operations. The same seems to apply...

There is no need for a soft float implementation. The only issue is that many representations of `NaN` exist. The representation should not matter as long as computed `NaN` values...

Either each float result of a computation needs to be checked (I prefer to do this on all platforms because `NaN` propagation is undefined anyhow, e.g. when applying a binary...

Another nix bug: ```nix (1.e200 * 1.e200 - 1.e200 * 1.e200) = 0 ``` both return `true`, but the LHS is `NaN`.

A difference between `libstdc++` and `libc++` when parsing subnormal numbers with `builtins.fromTOML`: No problem with `libstdc++` ```nix nix-repl> builtins.fromTOML ''a = 1e-308'' { a = 1e-308; } ``` but with...

> > A difference between libstdc++ and libc++ when parsing subnormal numbers with builtins.fromTOML > > 🫠🫠🫠🫠🫠🫠🫠 > > As if we haven't had enough TOML fun yet. This is...