Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lossless TryFrom<f{32,64}> implementations for f16 and bf16 #90

Open
Robbepop opened this issue May 30, 2023 · 1 comment
Open

lossless TryFrom<f{32,64}> implementations for f16 and bf16 #90

Robbepop opened this issue May 30, 2023 · 1 comment

Comments

@Robbepop
Copy link

Robbepop commented May 30, 2023

Would it be possible to introduce lossless TryFrom implementations for bf16 and f16 types from Rust primitive f32 and f64 types so that for example f16::try_from(value).map(f16::to_f32) is either Err or Ok(value2) with value == value2 for all possible values?

This means that if TryFrom is Ok the conversion was lossless and it is possible to fully recover the f32 or f64 value later on if no mutations happen in between. If TryFrom yields Err then it is not possible to losslessly convert the particular f32 or f64 value. No rounding shall take place.

I actually need this if this can be implemented efficiently. :)

Alexhuszagh added a commit to Alexhuszagh/float16 that referenced this issue Dec 15, 2024
This adds `from_f*_lossless` functions, which then are implemented as `TryFrom`, which will only return values if they can fully roundtrip.

Related to starkat99#90
Alexhuszagh added a commit to Alexhuszagh/float16 that referenced this issue Dec 15, 2024
This adds `from_f*_lossless` functions, which then are implemented as `TryFrom`, which will only return values if they can fully roundtrip.

Related to starkat99#90
@Alexhuszagh
Copy link

@Robbepop not sure if there's still interest but I implemented this and would gladly make a PR here. It's not too complicated or inefficient, but it does need special handling of denormals and overflow.

It will roundtrip for anything besides signaling NaNs, which will be returned as a NaN (either quiet or signaling depending on context), and it's not much less efficient or is as efficient compared to the software conversion functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants