simplify f16 to_degrees and to_radians by using expression directly

[karolzwolak]

Simplify f16 to_degrees and to_radians by using expression directly.
This seems to return the same values for me, but maybe on some targets the literal is actually better?

I added a test that's gonna check if they are equivalent in CI, we'd probably want to get rid of it once we get verify this.

r? @tgross35

[tgross35]

The results here will be identical. I meant something like what f64 does where the result is calculated (possibly to a const),

rust/library/core/src/num/f64.rs

Lines 871 to 876 in 16ad385

	pub const fn to_degrees(self) -> f64 {
	// The division here is correctly rounded with respect to the true
	// value of 180/π. (This differs from f32, where a constant must be
	// used to ensure a correctly rounded result.)
	self * (180.0f64 / consts::PI)
	}

[karolzwolak]

So you're saying we can just merge this? And why the behavior difference for f64?

[karolzwolak]

Oh wait, you mean the to_degrees() is a const fn, which in turn could increase precision for constant which uses to_degrees()?

[tgross35]

Not quite :) I mean that it makes absolutely no difference whether we multiply by the literal 57.2957795130823208767981548141051703, or assign it to a const first, or let. They compiler guarantees that the comptime and runtime semantics are the same here.

What I do mean is for f16, 57.295... is not exactly the same as 180 / pi https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=85a373861e735f8c2a58b00b4540a150. And using the value of 180 / pi happens to roundtrip for an input of 180.0, though not for other values.

I'm not sure which value (exact at larger precision or computed as f16) should be preferred though, @beetrees is more likely to have this knowledge ready to go.