Rounding issues .Net Core 3.1 vs. .Net Core 2.0/.Net Framework

Question

I'm experiencing some rounding issues between .NET Core 3.0 and .NET Framework/.NET Core 2.x.

I've been searching on the web for a while, but I couldn't find the right term to search for, so i'm posting it here.

I wrote the following sample console app to illustrate my problem:

class Program
{
    static void Main(string[] args)
    {
        const double x = 123.4567890 / 3.14159265358979;
        Console.WriteLine(x);

        const double y = 98.76543210 / 3.14159265358979;
        Console.WriteLine(y);

        const double z = 11.2233445566778899 / 3.14159265358979;
        Console.WriteLine(z);

        Console.ReadKey();
    }
}

I ran this program on different frameworks and got the following output:

• .NET Framework 4.7.2
  • 39,2975164552063
  • 31,4380134506439
  • 3,57250152843761
• .NET Core 2.0:
  • 39,2975164552063
  • 31,4380134506439
  • 3,57250152843761
• .NET Core 3.0:
  • 39,2975164552063
  • 31,438013450643936
  • 3,5725015284376096

As you can see, the 3.0 output differs from the first two, and has got more precision starting from the 13th number after the floating point.

I assume that the precision of .NET Core 3.0 is more accurate.

But my case is that I want to migrate from .NET Framework to .NET Core 3.0. Before migrating, I wrote tests for the .Net Framework library to make sure the calculations will give the same output after migrating to .NET Core 3.0 . For that, I just wrote tests like:

//Arrange
const double expectedValue = 0.1232342802302;

//Act
var result = Subject.Calculate();
//Assert
result.Should.Be(expectedValue);

If I migrate the code and run the tests, which I wrote to the .NET Framework, the tests will fail. I got minor differences like

Expected item[0] to be 0.4451391569556069, but found 0.44513915698437145.
Expected result to be -13.142142181869094, but found -13.142142181869062.

My question here is; how do I force to round .NET Core 3.0 in the same way as .NET Framework/.NET Core 2.0 does, so I won't get these minor differences.

And could anyone explain this difference / describe the changes of rounding in .NET Core 3.1 versus .NET Framework?

Answer 1

That's bizarre.... I've setup a solution with 4 projects

• a .NET Framework 4.7.2 project
• a .NET Core 2.0 project
• a .NET Core 3.1 project
• a .NET Core 3.1 project to run all 3 projects at once.

In every project I used the Math.PI constant to see if something changes, and indeed it did, but not how I expect.

If I run the fourth project, the one that calls all 3, I get this result

So the values from all 3 projects are the same. But if I run these separately I get these results:

.NET Framework

.NET Core 2

.NET Core 3

So for some reason I get different results from yours in .NET Core using the Math.PI constants, and these are the same between version 2 an 3.1. However I get the same result as your with .NET Framework, which is different from the two .NET Core. But as we saw above, if you run all 3 projects from another project made in .NET Core, you get the same results, meaning that maybe is the calling project that determines what rounding should be used. Unfortunately I can't find the exact reason why this happens, but if I remember correctly there are some minor differences in how rounding works in Windows versus in Unix systems. Since .NET Core is cross-platform, I think is using the Unix rounding, rather than the Windows one that is probably used by .NET Framework, leading to these differences.

EDIT: This is going beyond science now... I used the constant value of 3.14159265358979 instead of Math.PI, which in theory is the same (according to Microsoft Documentation) . But by using this value the results change again! If you run the test where all 3 projects are running, you still get these same results for all 3, but these are different from the previous run

39,2975164552063
31,438013450643936
3,5725015284376096

When launching the .NET Framework project, you get the same results as before, while running the .NET Core ones you get the above results. So using the constant value, instead of Math.PI, changes the results once again. But this is really non-sense, since under the hood, Math.PI is just a double constant with the 3.14159265358979 value

EDIT 2: I wrote the same program with Python

def main():
    x = 123.4567890 / 3.14159265358979
    print(x)
    y = 98.76543210 / 3.14159265358979
    print(y)
    z = 11.2233445566778899 / 3.14159265358979
    print(z)


if __name__ == "__main__":
    main()

and the results are identical to .NET Core

39.2975164552063
31.438013450643936
3.5725015284376096

I then tried to do the same using Go

package main

import "fmt"

func main() {
    x := 123.4567890 / 3.14159265358979
    fmt.Println(x)
    y := 98.76543210 / 3.14159265358979
    fmt.Println(y)
    z := 11.2233445566778899 / 3.14159265358979
    fmt.Println(z)
}

And in this case the results are the following

39.2975164552063
31.43801345064394
3.5725015284376096

The y has been rounded to ..94, while x and z are the same as python and .NET Core.

As a final test I tried doing this with Javascript/Node.JS

let x = 123.456789 / 3.14159265358979;
console.log(x);
let y = 98.7654321 / 3.14159265358979;
console.log(y);
let z = 11.2233445566778899 / 3.14159265358979;
console.log(z);

But here also the results are the same as python and .Net Core

39.2975164552063
31.438013450643936
3.5725015284376096

Since Python, JS, .NET Core and GO (if you don't consider the y rounding), are cross-platform, I assume there is something tied to the Windows ecosystem that .NET framework relies on. It would be interesting to try with other frameworks/languages tied to Windows, but I don't know any other than .NET Framework (maybe Visual Basic?)

Answer 2

This is a documented change that makes the formatter and parser compliant with IEEE 754-2008. From the IEEE Floating-Point section in the What's new in .NET 3.0 document :

Floating point APIs are being updated to comply with IEEE 754-2008 revision. The goal of these changes is to expose all required operations and ensure that they're behaviorally compliant with the IEEE spec. For more information about floating-point improvements, see the Floating-Point Parsing and Formatting improvements in .NET Core 3.0 blog post.

The examples in the blog post actually address what happened here with Pi (emphasis mine):

ToString(), ToString("G"), and ToString("R") will now return the shortest roundtrippable string. This ensures that users end up with something that just works by default.

An example of where it was problematic was Math.PI.ToString() where the string that was previously being returned (for ToString() and ToString("G")) was 3.14159265358979; instead, it should have returned 3.1415926535897931.

The previous result, when parsed, returned a value which was internally off by 7 ULP (units in last place) from the actual value of Math.PI. This meant that it was very easy for users to get into a scenario where they would accidentally lose some precision on a floating-point value when the needed to serialize/deserialize it.

The actual data hasn't changed. The y and z values do have greater precision, even in .NET 4.7. What did change is the formatter. Before Core 3.x, the formatter would use only 15 digits even if the values had greater precision.

The blog post explains how to get the old behavior :

For ToString() and ToString("G") you can use G15 as the format specifier as this is what the previous logic would do internally.

The following code:

const double y = 98.76543210 / 3.14159265358979;
Console.WriteLine(y);
Console.WriteLine("{0:G15}",y);

Will print :

31.438013450643936
31.4380134506439