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

Half-float preserve more bits for denormals #208

Merged
merged 1 commit into from
Mar 19, 2022
Merged

Conversation

ranvis
Copy link
Contributor

@ranvis ranvis commented Mar 16, 2022

PR: Half-float preserve more bits for denormals

Description

Encoding of half-float values that is in range of denormalized numbers had been trimmed the whole mantissa bits.
This patch improves it by reflecting some bits to the encoded value.

Some examples:

binary32  before  after   before     after
38000000  0x0200  0x0200  3.0518e-5  3.0518e-5
38004000  0x0200  0x0201  3.0518e-5  3.0577e-5
38008000  0x0200  0x0202  3.0518e-5  3.0637e-5
387f8000  0x0200  0x03fe  3.0518e-5  6.0916e-5
387fc000  0x0200  0x03ff  3.0518e-5  6.0976e-5

I used "round half away from zero" instead of "round to even" because it is simple and doesn't need an execution branch.

Checklist

  • I have read followed CONTRIBUTING.md
    • I have added tests
    • I have updated the documentation
    • I have updated the CHANGELOG
  • Are there any breaking changes? If so, are they documented?
  • Does this PR introduce any platform specific code? If so, is this captured in the description?
  • Security: Does this PR potentially affect security? If so, is this captured in the description?
  • Performance: Does this PR potentially affect performance? If so, is this captured in the description?

@PJK
Copy link
Owner

PJK commented Mar 17, 2022

Hi @ranvis, thank you for the patch! This is a breaking change, so I'd like to understand the benefit. Do you have some real-world usecase(s) for keeping more bits?

@PJK PJK closed this Mar 17, 2022
@PJK PJK reopened this Mar 17, 2022
@ranvis
Copy link
Contributor Author

ranvis commented Mar 18, 2022

The patch will make it possible to round-trip half-float values.
In the current implementation some half-float value say 0007 is decoded to 4.1723e-7.
On the other hand, 4.1723e-7 is encoded to 0004, which is 2.3842e-7 if decoded again.
But does that affect in real-world?
I'd say if anyone ever storing half-float, this will make it better.
But I'm not sure if one want to store half-float.

@PJK
Copy link
Owner

PJK commented Mar 19, 2022

Got it, thanks. Having encode and decode functions composing to identity (up to the float => half float data loss) sounds like a good argument.

Brief search doesn't show anyone relying on the half, so let's go ahead with this. Thanks a lot for the improvement!

PJK added a commit that referenced this pull request Mar 19, 2022
@PJK PJK merged commit 3b4338e into PJK:master Mar 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants