[ranvis]

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]

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?

[ranvis]

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]

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!