Release and debug mode give different results unless I print a value

Question

I have release and debug codes that can give dramatically different results. Since I can't debug release code I have been printing value to a file to compare the two modes. I have localized my problem to a few lines of code.

var yFloat = topArcDetails.ArcPoints.GetInterpolatedYAt(point.X);
var tvdOnTopHorizon = (double) yFloat;
var yPointDouble = (double) point.Y;
deltaTvdTop = yPointDouble - tvdOnTopHorizon;
if (point.X == 2102.0 && point.Y > 1573.0 && point.Y < 1574.0)
{
    var message = String.Format("MD, TVD,         tvdOnTopHorizon, deltaTvdTop = {0}  {1}          {2}  {3}", point.X, point.Y, tvdOnTopHorizon, deltaTvdTop);
    //var message = String.Format("MD, TVD, yFloat, tvdOnTopHorizon, deltaTvdTop = {0}  {1}  {2}  {3}  {4}", point.X, point.Y, yFloat, tvdOnTopHorizon, deltaTvdTop);
    var oldOut = Console.Out;
    using (TextWriter w = File.AppendText("debugOutput.txt"))
    {
        Console.SetOut(w);
        Console.WriteLine(message);
    }
    Console.SetOut(oldOut);
}

Note that I have two choices of the message I can print to file. One message contains the value of yFloat, the other does not.

If I run in release mode without debugging the first message will give:

MD, TVD,         tvdOnTopHorizon, deltaTvdTop = 2102  1573.135            1554.6184437573   18.5164439380169

The second message will give:

MD, TVD, yFloat, tvdOnTopHorizon, deltaTvdTop = 2102  1573.135  1554.618  1554.61840820313  18.5164794921875

Notice that just printing the value of yFloat causes small changes in the last two numbers. In debug mode I see no difference caused by the print statement the two results are:

MD, TVD, yFloat, tvdOnTopHorizon, deltaTvdTop = 2102  1573.135  1554.618  1554.61840820313  18.5164794921875
MD, TVD,         tvdOnTopHorizon, deltaTvdTop = 2102  1573.135            1554.61840820313  18.5164794921875

The debug result agree with the release results where yFloat is printed. I know that the core issue is the fact that the code mixes floating point and doubles, which was someone else's bad idea. Although printing the value of yFloat fixes the problem, I don't think that is very practical. It does make me think that there must be something I can do to get the release version to agree with the debug version.

Answer 1

The C# language specification (you should have a copy in a folder like C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC#\Specifications\1033 or you can download it) says this in Section 4.1.6 Floating point types:

Floating-point operations may be performed with higher precision than the result type of the operation. For example, some hardware architectures support an “extended” or “long double” floating-point type with greater range and precision than the double type, and implicitly perform all floating-point operations using this higher precision type. Only at excessive cost in performance can such hardware architectures be made to perform floating-point operations with less precision, and rather than require an implementation to forfeit both performance and precision, C# allows a higher precision type to be used for all floating-point operations. Other than delivering more precise results, this rarely has any measurable effects. However, in expressions of the form x * y / z, where the multiplication produces a result that is outside the double range, but the subsequent division brings the temporary result back into the double range, the fact that the expression is evaluated in a higher range format may cause a finite result to be produced instead of an infinity.

(The key point is the sentence I've put in bold.)

Essentially this means the C# compiler is free to optimise the code however it likes as long as the accuracy gets better not worse.

In your case, although topArcDetails.ArcPoints.GetInterpolatedYAt(point.X) returns a float, the result is used for calculating a double. Apparently the compiler is inlining the code as an optimisation when building the release version, bypassing the conversion to float. (You might also find differences in the output when compiling in x86 release vs. x64 release modes.)

You can explicitly cast the value, even though this looks redundant,

var yFloat = (float) topArcDetails.ArcPoints.GetInterpolatedYAt(point.X);

which will force the compiler to convert the result into a float before using it.

So in conclusion you have to choose between accuracy and repeatability. If you care most about getting the most accurate result (and perhaps better performance), allow the compiler to do its optimisations. If you care more about getting identical results across platforms then you'll need to add extra casts by hand to force intermediate calculations into a fixed number of bits.