Repository navigation
Correct decimal conversions to Half and BFloat16 - #135668
Merged
tannergooding merged 1 commit intoOct 13, 2026
Merged
tannergooding merged 1 commit into
tannergooding merged 1 commit into
Conversation
Use target-format fast paths and exact fallback rounding to avoid double-rounding. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @dotnet/area-system-numerics |
This was referenced Oct 13, 2026
vcsjones
approved these changes
Oct 13, 2026
tannergooding
added a commit
that referenced
this pull request
Oct 15, 2026
) Fixes Issue #135659 <!-- Issue Number --> main PR #135668 <!-- Link to PR if any that fixed this in the main branch. --> # Description <!-- Give a brief summary of the issue and how the pull request is fixing it. --> This backports the fix for double-rounding in decimal-to-Half and decimal-to-BFloat16 conversions. The exact fallback now rounds directly to the destination format, and Half parsing uses the corrected tie-to-even exponent boundary. # Customer Impact <!-- What is the impact to customers of not taking this fix? --> Applications converting decimal values close to Half or BFloat16 midpoints can receive the adjacent representable value on the wrong side of the midpoint. The error also affects some Half subnormal values. # Regression <!-- Is this fixing a problem that was introduced in the most recent release, ie., fixing a regression? --> No. The issue reproduces in .NET 11 RC builds; Half had the same double-rounding issue in .NET 10, and BFloat16 is new in .NET 11. # Testing <!-- What kind of testing has been done with the fix. --> - `.\build.cmd clr+libs -rc checked` — passed (checked baseline). - `.\build.cmd clr.corelib+clr.nativecorelib+libs.pretest -rc checked` — passed, 0 warnings and 0 errors. - `dotnet build /t:test src\libraries\System.Runtime\tests\System.Runtime.Tests\System.Runtime.Tests.csproj` — passed: 77,859 total, 0 failed, 87 skipped. # Risk <!-- Please assess the risk of taking this fix. Provide details backing up your assessment. --> Low. The change is limited to decimal floating-point rounding and Half's parser tie boundary, with regression cases for midpoint-adjacent values, ties, and subnormals. The mainline PR's focused comparison reported 6.368 ns for a BFloat16 decimal cast versus 4.096 ns for casting through double; the run had notable variance and was not a separate baseline-runtime build, so this is an observed cost rather than conclusive regression evidence. No separate release-branch benchmark was run. # Package authoring no longer needed in .NET 9 IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version. Keep in mind that we still need package authoring in .NET 8 and older versions. Resolves #135659 > [!NOTE] > This PR description was prepared with GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Decimal-to-
Halfand decimal-to-BFloat16conversions can round to the wrong neighbor when the decimal lies just to one side of a target-format midpoint but first rounds to the midpoint asdouble. Use target-format fast paths where valid, with an exact target-precision fallback for the remaining values. Also correct Half'sMinExponentRoundToEvenboundary from -21 to -22; this fixes affected Half parsing ties as well.Testing
.\build.cmd clr.corelib+clr.nativecorelib+libs.pretest -rc checked— passed, 0 warnings and 0 errors.dotnet build /t:test src\libraries\System.Runtime\tests\System.Runtime.Tests\System.Runtime.Tests.csproj— passed, 78,595 tests, 0 failed, 87 skipped.git diff --check— passed.Performance
A focused local BFloat16 comparison for
123.456mmeasured 6.368 ns for the decimal cast versus 4.096 ns for(BFloat16)(double)value. The run had notable variance and was not a separate baseline-runtime build, so treat this as an observed cost to assess rather than a conclusive regression measurement.Risk
The behavioral change is limited to decimal conversions to the 16-bit formats and Half parsing at the corrected tie boundary. Regression tests cover midpoint-adjacent values, ties, and subnormal cases for both formats.
Resolves #135659
Note
This PR description was prepared with GitHub Copilot.