Add f16, f128

[usamoi]

1. integer_decode is implemented for f128 by truncating the radix to its 64 most significant bits. See Float::integer_decode cannot be implemented for quadruple precision floating types. #98.
2. Because of precision limitations, most implementation are inaccurate under no_std and libm, and a test fail because of this.

[cuviper]

I'm not keen on maintaining for unstable features in this crate, so we're probably going to be blocked here until the language and standard library stabilize these new floats.

At that point, I think we'll probably want to have detection in the build script to enable it automatically, and Cargo features can force that on -- like we used to for has_i128.

[scimind2460]

rust-lang/libs-team#707 would eventually rely on this (as per my implementation) so could we expedite support?

[cuviper]

rust-lang/libs-team#707 would eventually rely on this (as per my implementation) so could we expedite support?

I would not expect the standard library to start using num-traits, especially because that new Complex type should probably be in core, and you can't build num-traits as a dependency before that! I would expect a pseudo-internal trait instead, more like the setup of struct NonZero<T> where T: ZeroablePrimitive.

(My reservations remain about unstable features as well.)

[folkertdev]

Trying this again, though I think the reservations about unstable features are valid:

We're aiming to stabilize f16 this year, and as far as we know support is complete when using LLVM 22 (which nightly rust now does).

For testing portable_simd it would be helpful if this crate supported f16. Specifically, the portable_simd crate uses float-cmp, which in turn uses num-traits. We'd like to test with f16 vectors, but then that requires support in both of those dependencies.

I'd propose to use cargo features, similar to what I implemented for proptest proptest-rs/proptest#638, and I think similar to has_i128 that this crate already has (but I'm guessing the msrv got bumped high enough that i128 is always available, so that feature is now no longer needed).

The f128 type still has lots of issues, I don't think it makes sense to add it at this point in time.

[cuviper]

For testing purposes, you could just [patch.crates-io.num-traits] to an f16-enabled fork, even on a local path.