On double parsing in C#

Question

I have the following code:

var d = double.Parse("4796.400000000001");
Console.WriteLine(d.ToString("G17", CultureInfo.InvariantCulture));

If I compile and run this using an x86 configuration in Visual Studio, then I get the following output:

4796.4000000000005

If I instead compile as x64 I get this:

4796.4000000000015

I realize that using 32 och 64 bit compilation must affect how double values are handled by the system, but given that C# defines double as being 64 bit, shouldn't the result of this operation be the same independently of what compilation configuration I use?

Additional observation

Based on a comment regarding double.Parse I wrote this code:

var d0 = double.Parse("4796.400000000001");
double d1 = 4796.400000000001;
Console.WriteLine("d0: " + d0.ToString("G17", CultureInfo.InvariantCulture));
Console.WriteLine("d1: " + d1.ToString("G17", CultureInfo.InvariantCulture));

I get the following output when compiling as x86:

d0: 4796.4000000000005
d1: 4796.4000000000005

But I get this when I compile as x64:

d0: 4796.4000000000015
d1: 4796.4000000000005

Notice how the values differ in the x64 version, but not in the x86 version.

This duplicate is not really related, well if it is, its drawing a very long bow — TheGeneral, Mar 13 '19 at 08:42
Yip. I agree with @MichaelRandall. The problem is how you're initializing the double. Removing the double.Parse(...) and replacing it with a simple "double d = 4796.400000000001;" solves the discrepancy. — Eric McLachlan, Mar 13 '19 at 08:51
@mjwills The reason why its a little fishy is because `var d1 = 4796.400000000001` result to the same on both architectures, its only when fed as a string through parse it has a different value. Now, given the extended variant, its probably right that its the calculations within parse that makes this problem become apparent. Though this in it self is still curious and interesting... ps there is some blank magic going on the parse method from what i am seeing — TheGeneral, Mar 13 '19 at 08:54
Interesting! Thanks for pointing out that parse operation @MichaelRandall! I added some additional observations to the case based on that. — Øystein Kolsrud, Mar 13 '19 at 09:33
Another observation: It looks like there were changes in this domain in .Net Core quite recently: https://github.com/dotnet/coreclr/pull/20707 (merged on Nov 8, 2018) — Øystein Kolsrud, Mar 13 '19 at 12:42

score 1 · Accepted Answer · answered Jun 17 '19 at 09:18

I think the simple answer to this one is that this is a bug in .NET Framework. I filed the following ticket on the issue:

https://developercommunity.visualstudio.com/content/problem/488302/issue-with-double-parser.html

The issue has been closed as "won't fix" with the following motivation:

The change taken in .NET Core to enable stability in these calculations was large and carried more risk that we typically take in .NET Framework.

score 0 · Answer 2 · answered Mar 13 '19 at 09:21

0

Not sure why there is a difference, though, the code in the x86 configuration is not the same as in the x64 configuration.

answered Mar 13 '19 at 09:21

ArthurAkhmerov

159
2
5

This is not an answer to the question. All this shows is there is a difference in the code generated to call double.Parse & to store the result (qword in both cases) - it doesn't explain why there may be a difference in the result (the result may be the same, it may be the conversion back to string where the issue is) – PaulF Mar 13 '19 at 10:15

On double parsing in C#

2 Answers2