4 ms·

This is definitely nice. But I'm thinking that NaN is a bit like null, in that it's a surprising value that may pop up which suddenly means something completely

by jfries 9y ago

This is definitely nice. But I'm thinking that NaN is a bit like null, in that it's a surprising value that may pop up which suddenly means something completely different, and code must handle it correctly. Just as some languages (like Rust) provide a way to say that a variable can't be null, I think it would make sense to have a floating point value that can't be NaN. Comparison of two non-NaNnable floating point value can then just return a boolean, because we know it will never fail.

Animats 9y ago
A key point of IEEE floating point is that NaN propagates. Any arithmetic operation that involves a NaN returns NaN. So you don't have to check until the end of the computation. Unless, of course, branching is involved. A floating point type that could never be NaN is quite reasonable for a language with exceptions. But in a language without them, what's supposed to happen?
- jfries 9y ago
  Well if the language is flexible enough it doesn't have to be a big annoyance to have types for both fp32 and nnfp32 (no-NaN fp32). nnfp32 guarantees things that a fp32 doesn't, for example that comparison is always legal and works as expected. This way you can perform calculations on fp32, but then have to sanitize the output before storing it back in the data structure. One way to use the type system to enforce sanitation could be if values in a database are of type nnfp32, and the only way to produce a nnfp32 is using a function which returns Option<nnfp32>, returning Some only if the value is not NaN.
  - comex 9y ago
    In fact there is a Rust crate for this: https://danielkeep.github.io/rust-numeric-float/doc/numeric_float/index.html https://danielkeep.github.io/rust-numeric-float/doc/numeric_...
    - jfries 9y ago
      Wow, that is fantastic! :) it looks like the same idea but developed.
- dhekir 9y ago
  And for the half-initiated in IEEE 754, who think (like I used to) that all operations defined in the standard (including non-arithmetic ones) propagate NaNs, don't forget that pow is also defined (recommended, not obligatory), and that pow(NaN, 0) == 1, as well as pow(1, NaN) == 1, so there is a way to "lose" NaNs when using standard but non-arithmetic operations.

by jfries 9y ago

Animats 9y ago

A key point of IEEE floating point is that NaN propagates. Any arithmetic operation that involves a NaN returns NaN. So you don't have to check until the end of the computation. Unless, of course, branching is involved. A floating point type that could never be NaN is quite reasonable for a language with exceptions. But in a language without them, what's supposed to happen?

jfries 9y ago
Well if the language is flexible enough it doesn't have to be a big annoyance to have types for both fp32 and nnfp32 (no-NaN fp32). nnfp32 guarantees things that a fp32 doesn't, for example that comparison is always legal and works as expected. This way you can perform calculations on fp32, but then have to sanitize the output before storing it back in the data structure. One way to use the type system to enforce sanitation could be if values in a database are of type nnfp32, and the only way to produce a nnfp32 is using a function which returns Option<nnfp32>, returning Some only if the value is not NaN.
- comex 9y ago
  In fact there is a Rust crate for this: https://danielkeep.github.io/rust-numeric-float/doc/numeric_float/index.html https://danielkeep.github.io/rust-numeric-float/doc/numeric_...
  - jfries 9y ago
    Wow, that is fantastic! :) it looks like the same idea but developed.
dhekir 9y ago
And for the half-initiated in IEEE 754, who think (like I used to) that all operations defined in the standard (including non-arithmetic ones) propagate NaNs, don't forget that pow is also defined (recommended, not obligatory), and that pow(NaN, 0) == 1, as well as pow(1, NaN) == 1, so there is a way to "lose" NaNs when using standard but non-arithmetic operations.