2

After upgrading C++ project to Visual studio 2013, the result of the program has changed because of different floating point behavior of the new VC compiler. The floating model is set to /fp:precise

In Visual Studio 2008(v9.0)

float f = 0.4f; //it produce f = 0.400000001
float f6 = 0.400000006f; //it produce f = 0.400000001

In Visual Studio 2013 (v12.0)

float f = 0.4f; //it produce f = 0.400000006                                 
float f1 = 0.40000001f; //it produce f1 = 0.400000006

The setting for the project is identical (converted).

I understand that there is a kind of liberty in floating point model, but I don't like that certain things has changed and the poeple working with old/new version of Visual Studio can't reproduce some bugs being reported by another developers. Is there any setting which can be changed to enforce the same behavior across different version of Visual Studio?

I tried to set platform toolset to vs90 and it still produce 0.400000006 in VS2013.

UPDATE:

I tracked the hexadicimal values in Memory Window. The hexadecimal values, f1, f1 and f6 are all the same. There is a difference in displaying these float values in the watch window. Futhermore the problem is still with float 0.3f. Multiplying same decimal values gives different result.

In Visual Studio 2008(v9.0)

float a = 0.3f; //memory b8 1e 85 3e 00 00 40 40, watch 0.25999999
float b = 19400; 
unsigned long c = (unsigned long)((float)b * a); //5043

In Visual Studio 2013 (v12.0)

float a = 0.3f; //memory b8 1e 85 3e 00 00 40 40, watch 0.259999990
float b = 19400; 
unsigned long c = (unsigned long)((float)b * a); //5044
B. Bilgin
  • 774
  • 12
  • 22
Tomas Kubes
  • 23,880
  • 18
  • 111
  • 148
  • Could it be related to http://stackoverflow.com/questions/1154221/why-are-doubles-added-incorrectly-in-a-specific-visual-studio-2008-project? – Tomas Kubes Jun 20 '14 at 06:37
  • 32-bit floats have only 23-bits of mantissa and they can't store such large precisions, they're only precise to ~7 decimal digits http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html – phuclv Jun 20 '14 at 07:41
  • 2
    The closest float value close to 0.4f is 0x3ecccccd = 0.4000000059604645, so the result 0.400000006 is correct, you can check it here http://www.h-schmidt.net/FloatConverter/ – phuclv Jun 20 '14 at 07:44
  • Ok, let suppose that Microsoft correct the bug. Is there still the way to turn on vs90 compatibility mode? – Tomas Kubes Jun 20 '14 at 08:05
  • 1
    I don't think this is a bug. Were the names and values f6 and f1 above changed by VS converter or by you? If that's you then `0.40000001f` is just exactly the same as `0.400000006f` in single precision (note the number of 0s after 4), and the number 0.400000001 in your comments are wrong, maybe mistyped one more zero digit. Print out more digits in both VS2008 and 2013 to see there's no difference – phuclv Jun 20 '14 at 08:12
  • Yes, you are true, the difference is not in inicialization, but the difference is in the watch and in the multiplying. – Tomas Kubes Jun 20 '14 at 11:51

1 Answers1

4

The behavior is correct, the float type can store only 7 significant digits. The rest are just random noise. You need to fix the bug in your code, you are either displaying too many digits, thus revealing the random noise to a human, or your math model is losing too many significant digits and you should be using double instead.

There was a significant change in VS2012 that affect the appearance of the noise digits. Part of the code generator changes that implement auto-vectorization. The 32-bit compiler traditionally used the FPU for calculations. Which is very notorious for producing different random noise, calculations are performed with an 80-bit intermediate format and get truncated when stored back to memory. The exact moment when this truncation occurs can be unpredictable due to optimizer choices, thus producing different random noise.

The code generator, like it already did for 64-bit code, now uses SSE2 instructions instead of FPU instructions. Which produce more consistent results that are not affected by the code optimizer choices, the 80-bit intermediate format is no longer used. A backgrounder on the trouble with the FPU is available in this answer.

This will be the behavior going forward, the FPU will never come back again. Adjust your expectations accordingly, there's a "new normal". And fix the bugs.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536