Alexander Huszagh

@myrrlyn This would be doable for sure. The only issue is that the number of significant digits would have to increase dramatically for the arbitrary-precision arithmetic. Currently, in base 10,...

For the actual links to the documentation in the code, the comments documenting all this can be found [here](https://github.com/Alexhuszagh/rust-lexical/blob/18076323d1225c910c086f0b9fa56ac83458d40f/lexical-core/src/atof/algorithm/bhcomp.rs#L150). The formula so you can test it on your own is...

Support for f16 and bf16 should be trivial, however. For f128, I"m very worried about the following however, so it would never be the default (maybe on option like `radix`?)....

@Evrey What implementations do you want for f16, bf16, and f128. I see the following: - [half](https://docs.rs/half/1.7.1/half/index.html) for f16, bf16 I don't see a Rust version of `f128` that doesn't...

@RazrFalcon The preliminary logic for all of this is implemented, however, I need concrete types for anything more significant. The following additions have been added, with appropriate types, should make...

@Evrey I've just looked at the `half` crate, and there is no support for any mathematical operations, which prevents the fast path from being implemented. In order to implement this...

@RazrFalcon I believe LLVM supports via it's intrinsics all of the ones we want. Not everything, so it would have to be feature-gated and implemented on supported hardware. Here's documentation...

Ok I've taken a closer look at this, and it seems we have the following cases: - __fp16, __bf16 in Clang's own specifications seem to be storage-only formats. After a...

Ok, I've thought about it a bit more carefully, and as long as we implement the logic to and from f32 properly, no loss of accuracy is possible since the...

On a separate note, I believe I've removed all the hard-coded logic internally to support f128, removing all the assumptions about an f64 mantissa used to simplify some trait impls....