Get different result when using ToString("F2", new CultureInfo("de-DE") in .NET6 and .Framework4.7.2

[guangzhengli]

Description

code:

  double value = 50.555d;
  Console.WriteLine(value.ToString("F2", new CultureInfo("de-DE")));

.dotnet6: output = 50.55
.Framework4.7.2 output = 50.56

Reproduction Steps

    internal class Program
    {
        static void Main(string[] args)
        {
            double value = 50.555d;
            Console.WriteLine(value.ToString("F2", new CultureInfo("de-DE")));
        }
    }

Expected behavior

output = 50.56

Actual behavior

output = 50.55

Regression?

No response

Known Workarounds

Console.WriteLine(string.Format(new CultureInfo("de-DE"), "{0:0.00}", value));

Configuration

No response

Other information

Is there any reason for this difference? Thanks!

[ghost]

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

code:

  double value = 50.555d;
  Console.WriteLine(value.ToString("F2", new CultureInfo("de-DE")));

.dotnet6: output = 50.55
.Framework4.7.2 output = 50.56

Reproduction Steps

    internal class Program
    {
        static void Main(string[] args)
        {
            double value = 50.555d;
            Console.WriteLine(value.ToString("F2", new CultureInfo("de-DE")));
        }
    }

Expected behavior

output = 50.56

Actual behavior

output = 50.55

Regression?

No response

Known Workarounds

Console.WriteLine(string.Format(new CultureInfo("de-DE"), "{0:0.00}", value));

Configuration

No response

Other information

Is there any reason for this difference? Thanks!

Author:	guangzhengli
Assignees:	-
Labels:	area-System.Globalization
Milestone:	-

[aloraman]

That's a known breaking change, that happened in .NET Core 2.1
See https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings:

On .NET Framework and .NET Core up to .NET Core 2.0, the runtime selects the result with the greater least significant digit (that is, using MidpointRounding.AwayFromZero).
On .NET Core 2.1 and later, the runtime selects the result with an even least significant digit (that is, using MidpointRounding.ToEven)

NB The logic behind this change is to make transformation number -> string -> number to preserve original value as much as possible, which is fine for serialization/deserialization scenarios. It's a major pain point for number -> string conversions for UI-related tasks though.

[KalleOlaviNiemitalo]

@aloraman, in the net6.0 output "50.55", the least significant digit is 5, which is not even, so the text you quoted does not explain this difference.

Instead, I think the cause is that (double)50.555 is a little less than the infinite-precision 50.555, so it is not halfway between 50.55 and 50.56. Even though it is halfway between (double)50.55 and (double)50.56.

[aloraman]

@KalleOlaviNiemitalo Well, yes. It happens because actual float-pointing value is less than 50.555, but it doesn't explain the difference with .NetFramework. It is indeed caused by that breaking change in .Net Core 2.1, but this quote is the only piece of documentation, that explains what happened.
To get to the details of what's actually changed you need to dig deeper into Github issues (e.g., #27174 and related changes dotnet/coreclr#12894) which is not simple - a lot of repos were moved and/or archived. Basically, the implementation has moved from native ecvt function, to different managed implementation, which uses Dragon4 algorithm. We can guess .NetFramework uses similar _ecvt function (at least open sourced SSCLI does)
The thing is, the breaking change has happened intentionally, so the chance this behavior will be fixed in the future is very slim.

[Joe4evr]

That's a known breaking change, that happened in .NET Core 2.1 See https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings:

There was another change to floating-point number parsing and formatting in .NET Core 3.0: https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/#making-the-formatter-ieee-754-2008-compliant

[aloraman]

@Joe4evr
It seems you're correct
50.555.ToString("F2") still produces 50.56 on .NET Core 2.1
It does produce 50.55 on .NET Core 3.1, so the change happened somewhere in 2.2-3.1

[eerhardt]

cc @tannergooding @dakersnar

[tannergooding]

IEEE 754 floating-point values can only exactly represent values that are a multiple of some power of 2. Since 50.555 doesn't fit this requirement, it rounds to the nearest representable result instead: 50.55499999999999971578290569595992565155029296875.

The floating-point parsing/formatting behavior prior to .NET Core 3.1 was not IEEE 754 compliant and had numerous edge case bugs where it would effectively "double round" due to not considering the exact represented value.

The value rounded to 2 fractional digits is indeed 50.55 because the third fractional digit of the infinitely precise value represented is 4 and therefore below the midpoint. This likewise matches what other languages do for their IEEE 754 floating-point parsing/formatting under similar circumstances.

The breaking changes here were intentional and documented as part of the move to be IEEE 754:2008 compliant and to bring ourselves inline with how other languages do floating-point parsing/formatting. This was documented in the blog post called out above (https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/#making-the-formatter-ieee-754-2008-compliant) and in the Breaking Changes documentation for .NET Core 3.0: https://docs.microsoft.com/en-us/dotnet/core/compatibility/3.0#floating-point-formatting-and-parsing-behavior-changed

[danmoseley]

@guangzhengli I don't know what you are using double for, but please note that you should not use double for financial calculations. Use Decimal .

[guangzhengli]

Thanks for letting me know about these.