Contemplate rustc_apfloat for platform consistent floats #44

New issue

Open

opened 2024-03-15 01:57:06 +00:00 by jade · 3 comments

jade commented

2024-03-15 01:57:06 +00:00

Owner

Nix regrettably has floats, which can be used to implement ray tracers and other inadvisable things. We would rather it didn't, but let's make them consistent.

jade added the

stability

label

2024-03-15 01:57:06 +00:00

puck commented

2024-03-15 17:30:35 +00:00

Owner

I'm a bit unsure how strongly this is needed; IEEE floats should be bit-identical for the base (divide, add, subtract, multiply) operations. It might be good to have either way, though.

(I also like how mentioning rustc_apfloat immediately divulges who you got this idea from, rather than mentioning the upstream llvm APFloat )

I'm a bit unsure how strongly this is needed; IEEE floats should be bit-identical for the base (divide, add, subtract, multiply) operations. It might be good to have either way, though. (I also like how mentioning `rustc_apfloat` immediately divulges who you got this idea from, rather than mentioning the upstream llvm APFloat :neofox:)

lix-project referenced this issue from a commit

2025-01-29 18:11:12 +00:00

Merge pull request #44 from nix-community/dependabot/github_actions/actions/checkout-3

piegames commented

2025-03-18 10:53:55 +00:00

Member

💭 What if we replaced Nix floats with rational numbers instead?

xokdvium commented

2025-10-18 12:59:37 +00:00

IEEE floats should be bit-identical for the base (divide, add, subtract, multiply)

That's not necessarily the case for when NaNs are involved. For one, nix already suffers from this arch-specific behavior:

let
  a = 1000000000000000000000000000000000000000000000000000000000000.00000000000;
  inf = a * a * a * a * a * a;
  nan = (inf / inf);
  nanStr = toString nan;
in
{
  isX86 = nanStr == "-nan";
}

$ nix build nixpkgs#legacyPackages.aarch64-linux.lixPackageSets.git.lix
$ qemu-aarch64 result/bin/nix eval --file test.nix
{ isX86 = false; }
$ nix eval --file test.nix
{ isX86 = true; }

(rev 53d172a308)

rust_apfloat doesn't have a great track record of being correct, since it's a port of LLVM's APFloat that suffers from correctness issues. Notably https://github.com/rust-lang/rustc_apfloat/issues/11. > IEEE floats should be bit-identical for the base (divide, add, subtract, multiply) That's not necessarily the case for when NaNs are involved. For one, nix already suffers from this arch-specific behavior: ```nix let a = 1000000000000000000000000000000000000000000000000000000000000.00000000000; inf = a * a * a * a * a * a; nan = (inf / inf); nanStr = toString nan; in { isX86 = nanStr == "-nan"; } ``` ``` $ nix build nixpkgs#legacyPackages.aarch64-linux.lixPackageSets.git.lix $ qemu-aarch64 result/bin/nix eval --file test.nix { isX86 = false; } $ nix eval --file test.nix { isX86 = true; } ``` (rev 53d172a3083840846043f7579936e0a3e86737e5)