Skip to content

Fix issue 16026: std.math.frexp!float() wrong for very small subnormals#4337

Merged
dnadlinger merged 1 commit intodlang:masterfrom
tsbockman:issue_16026
May 22, 2016
Merged

Fix issue 16026: std.math.frexp!float() wrong for very small subnormals#4337
dnadlinger merged 1 commit intodlang:masterfrom
tsbockman:issue_16026

Conversation

@tsbockman
Copy link
Contributor

This PR fixes Phobos issue #16026: std.math.frexp!float() and std.math.frexp!double() return a wrong significand for subnormal values.

The problem turns out to be a wrong "magic number" 0x8000 which selects which values of the highest 16 bits should be preserved while manually changing the exponent using bitwise operations. The correct value is ~F.EXPMASK, which happens to equal 0x8000 for the 80-bit and 128-bit IEEE formats, but not for 32- or 64-bit.

(Ultimately, I intend to replace the entire frexp() implementation with a clearer and more concise one based on RealRep, but I realize that it may take a while to get such a large change pulled, so I thought I'd submit this quick fix in the mean time.)

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
16026 std.math.frexp!float() wrong for very small subnormal values

tuple(-T.nan, -T.nan, int.min),

// Phobos issue #16026:
tuple(3 * (T.min_normal * T.epsilon), T( .75), (T.min_exp - T.mant_dig) + 2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the issue need to be included with the test?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's just a comment, so obviously it doesn't need to be there. This is a common practice in the core dlang projects though: to label tests with the issue number that precipitated their inclusion.

Two main benefits I see:

  • Seeing issue labels like this scattered throughout the tests provides real-world evidence to people browsing the code about what kind of test cases are needed for full coverage of related algorithms. Without that feedback, it is hard to know when to stop adding test cases.
  • For anyone tempted to reduce the number of test cases while refactoring, or while trying to speed up the test suite, it says, "Don't remove this one!"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No one should be removing tests though if they want to keep the coverage. ;-)

@ibuclaw
Copy link
Member

ibuclaw commented May 18, 2016

Looks fine

@9il 9il added the math label May 22, 2016
@tsbockman
Copy link
Contributor Author

@9il Can we pull this? It's just a tiny bug fix.

@dnadlinger
Copy link
Contributor

Auto-merge toggled on

@dnadlinger dnadlinger merged commit 4991b82 into dlang:master May 22, 2016
@tsbockman
Copy link
Contributor Author

@klickverbot Thanks.

@tsbockman tsbockman deleted the issue_16026 branch May 22, 2016 21:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants