RFC: make all f32/f64 methods const

I'm defining some f64 consts as literals, but it would be nice if I could express intent by writing them as a calculation using const fns. These include things like f64::recip and f64::ln. What do others think? Is there any reason not to?

Potential problems I can think of are that answers on the host machine might be different to the answers given on the target machine, even if the instruction set is the same (due to fpu differences). I'm not sure if this happens or matters in practice.

I guess this is the relevant issue, but there's not much discussion:

2 Likes

I think we can split this into the ones that are expected to be good within ½ ULP and the ones that are allowed to be only 1 ULP. I forget exactly which are which (I don't know if Rust documents this), but IIRC there are some functions that aren't known how to be implemented efficiently to ½ ULP.

So maybe we could make the "easy" ones const as they're supposed to give exactly the same results in all cases.

Though I guess there are problems with different NaNs too, in theory...

2 Likes

Yeah, and some methods are extra easy. For example I think recip, to_degrees and to_radians could be made const fn just by adding const in their signature.

Edit: Actually no. While it is already possible to write const RECIP: f32 = 1.0 / X where X is a constant of type f32, it is not allowed to have a const function that returns 1.0 / param where param is of type f32.