float::not_nan

[oriongonza]

Proposal

Problem statement

We could make working with floats a bit nicer by leveraging ?

Motivating examples or use cases

rust-lang/rust#84277 (comment)

fn do_thing_checked(rhs: f32, lhs: f32) -> Option<f32> {
  if (rhs.is_nan() || lhs.is_nan()) { return None }
  let res = do_thing(rhs, lhs);
  if res.is_nan() { return None }
  Some(res)
}

Solution sketch

fn not_nan(self) -> Option<Self> {
    (!num.is_nan()).then_some(num)
}

The example would look like the following:

fn do_thing_checked(rhs: f32, lhs: f32) -> Option<f32> {
  rhs.not_nan()?;
  lhs.not_nan()?;
  do_thing(rhs, lhs).not_nan()
  // or continue using it with
  let res = do_thing(rhs, lhs).not_nan()?;
  ...
}

Alternatives

This could also be an extension trait implemented in a third party crate.

[bjoernager]

On a related note: We already have the NonZero and NonNull wrappers, so would there be any merit in adding a NonNan type as well?

[oriongonza]

On a related note: We already have the NonZero and NonNull wrappers, so would there be any merit in adding a NonNan type as well?

https://internals.rust-lang.org/t/pre-rfc-nonnan-type/8418/25

[oshaboy]

I like not_nan but sadly there's no option^haha to go from Option to f64.

So perhaps this should be an IsNan trait that requires an is_nan impl. Or you could just implement Try on f64.

[bjoernager]

https://internals.rust-lang.org/t/pre-rfc-nonnan-type/8418/25

Since the linked discussion, NonZero itself has been extended with normal, checking, and saturating arithmetic methods. The checking methods specifically return an Option<Self> object, a pattern which I feel we could use as the basis for a similar NonNan type, e.g.:

impl NonNan<f32> {
    pub fn checked_sqrt(self) -> Option<Self>;
}

Option<NonNan<f32>> would then have the exact same representation as just f32, but at the same time implementing Try (although I am not sure if the compiler can currently work with multiple representations for None like it does with NaN).

On the other hand, most floating-point operations do not yield NaN as long as all of the operands are numerical. In these cases we can simply define them like we already do with the primitive floats.

[pitaj]

I think we need a stronger motivating example. In most cases, checking for NaN isn't necessary because most float operations will happily take a NaN and just output a NaN in response. In some cases, checking for NaN will even prevent optimizations such as vectorization.

[bjoernager]

I think the same can somewhat be said for NonZero. The main use of NonNan as I see it is in interfaces that want to enforce numericality at compile-time, with the most prominent advantage of this being avoiding FPEs from signalling NaNs (a little like how NonZero avoids panics from divide-by-zero).

[cuviper]

Option<NonNan<f32>> would then have the exact same representation as just f32, but at the same time implementing Try (although I am not sure if the compiler can currently work with multiple representations for None like it does with NaN).

No, currently the compiler will pick exactly one niche value for None. This also extends to multiple levels, like Option<Option<NonNan>> would pick one niche for None, another for Some(None), and all the non-niche values for the Some(Some(non_nan)). If the compiler changed to be more flexible in the first case, it would lose the extended cases.

So, there's no "free" conversion for NonNan::new(f32) -> Option<Self>, whereas NonZero<int> can just copy it.

[programmerjake]

I think the same can somewhat be said for NonZero. The main use of NonNan as I see it is in interfaces that want to enforce numericality at compile-time, with the most prominent advantage of this being avoiding FPEs from signalling NaNs (a little like how NonZero avoids panics from divide-by-zero).

Well, Rust assumes that all FP exceptions are masked and the status bits are ignored, so signalling NaNs are treated as any other NaN and basically all hardware will not cause any traps or go any slower because the NaN happens to be signalling.

This is different than division by zero, where x86's division instructions will cause interrupts, and presumably because of that it is UB in LLVM, so checking for division by zero is required.

[oshaboy]

Another 2 benefits I mentioned in the other thread are that firstly all NonNan will implement Ord and Eq. Allowing them to be used as keys. Secondly a NaN type lets you create NaNs out of payloads and to get the payload from the NaN allowing for NaN boxing.

[tgross35]

ordered_float provides a NotNan wrapper that adds Ord, Eq, and Hash.

[kennytm]

On the other hand, most floating-point operations do not yield NaN as long as all of the operands are numerical. In these cases we can simply define them like we already do with the primitive floats.

It is quite easy to yield infinities from finite numbers (e.g. MAX + MAX = INFINITY) and then yield NaNs from infinities (e.g. INFINITY - INFINITY = NAN). Similar to NonZero most operations do indeed get filtered out especially the useful ones (+−×÷).

Operation	NonNaN	Finite
Add, Sub, Sum	❌ (∞ - ∞)	❌ (MAX + MAX)
Mul, Product	❌ (∞ × 0)	❌ (MAX × MAX)
mul_add	❌ (∞×0+0)	❌ (MAX×MAX+0)
Div, Rem, div_euclid, rem_euclid	❌ (0 ÷ 0)	❌ (0 ÷ 0)
Neg, abs, signum, copysign	✅	✅
floor, ceil, round, round_ties_even, trunc	✅	✅
fract	❌ (fract(∞))	✅
powi, recip	✅	❌ (0-1)
powf, sqrt	❌ ((-1)0.5)	❌ ((-1)0.5)
cbrt	✅	✅
exp, exp2, exp_m1	✅	❌ (exp(MAX))
ln, log, log2, log10, ln_1p	❌ (log(-2))	❌ (log(-2))
hypot	✅	❌ (hypot(MAX, MAX))
sin, cos, tan, sin_cos	❌ (sin(∞))	✅1
asin, acos	❌ (asin(2))	❌ (asin(2))
atan	✅	✅
atan2	✅	✅
sinh, cosh	✅	❌ (sinh(MAX))
tanh	✅	✅
asinh	✅	✅
acosh, atanh	❌ (acosh(-2))	❌ (acosh(-2))
gamma	❌ (Γ(-1))	❌ (Γ(-1))
ln_gamma	✅2	❌ (ln Γ(MAX))
next_up, next_down	✅	❌ (next_up(MAX))
to_degrees	✅	❌ (to_degrees(MAX))
to_radians	✅	✅
max, min, maximum, minimum, clamp	✅	✅
midpoint	❌ (midpt(∞, -∞))	✅

Footnotes

1. Mathematically tan(π/2 + nπ) = ±∞, but a binary floating point number can never accurately represent whole non-zero multiples of π/2, so tan(x) will always produce finite output given finite f32/f64 x. ↩

2. I'd argue that the sign of ln Γ(-n) is undefined, but on Linux x86_64 and macOS arm64 it seems to always pick the +∞ side. Not sure if this is platform-specific. The manpage of lgamma suggested when computing ln Γ(-n) the value of signgam is unspecified. I think this also applied to lgamma_r. ↩

[bjoernager]

Well, Rust assumes that all FP exceptions are masked and the status bits are ignored, so signalling NaNs are treated as any other NaN and basically all hardware will not cause any traps or go any slower because the NaN happens to be signalling.

I was not aware of this. Thank you. This dismisses my point.

No, currently the compiler will pick exactly one niche value for None. This also extends to multiple levels, like Option<Option> would pick one niche for None, another for Some(None), and all the non-niche values for the Some(Some(non_nan)). If the compiler changed to be more flexible in the first case, it would lose the extended cases.

Could it be worthwhile creating an exception in this case? Even if this costs us the optimisation at higher, nested levels... But the memory concerns as pointed out by @oshaboy would at least be mitigated with Option<NonNan<f32>>, where conversions to/from f32 would then be no-ops.

It is quite easy to yield infinities from finite numbers (e.g. MAX + MAX = INFINITY) and then yield NaNs from infinities (e.g. INFINITY - INFINITY = NAN). Similar to NonZero most operations do indeed get filtered out especially the useful ones (+−×÷).

Wouldn't Finite have to be a subset of NonNan as NaNs are (pedantically speaking) non-numbers? Otherwise thank you for the table.

[kennytm]

Wouldn't Finite have to be a subset of NonNan as NaNs are (pedantically speaking) non-numbers?

Yes Finite excluded NaN and Infinities. But you could easily produce both from simple operations.

TBH I find it strange that the original request only rejected NaN. For instance, if you are interfacing with standard SQL databases you will need to reject both NaN and Infinity.