Floating point issue: C++ to C# migration

Question

I am working on a C++ to C# migration project. And I am stuck with an issue which involves floating point arithmetic. In C++, there is a function

int doubleToInt(double d)
{
    return (int)(d >= 0.0 ? (d + 0.1) : (d - 0.1));
}

The same function I migrate to C# as (Note that, in C++, sizeof(int) is 2 bytes. So I am using short as return type)

private static short doubleToInt(double d)
{
    return (short)(d >= 0.0 ? (d + 0.1) : (d - 0.1));
}

After this conversion, I am doing some operation and generating a binary file. The binary file generated in C# is different when compared to that of C++. Even if I compare the values while debugging (before writing to file), I am getting different answers.

Now I need to explain my client why it is different.

Can someone give me inputs on why it is different?

What I know is, the temporaries generated in C++ while doing floating point arithmetic operations are of higher precision.

Are there any other points? So that I can defend by telling "The way C++ handles the floating point is different from C# Or can I modify the C# program to match C++ output? Is it possible? Also, I can't modify the C++ legacy code. I need to get the same results in C#. Is it possible?

Answer 1

The facts that:

• this function returns different output in C++ versus C# given normal program input, and
• this function returns identical output in C++ versus C# given controlled identical input

suggests:

• the normal program inputs to this function are different in C++ versus C#.

Regarding the latter, in a comment the OP states “I also created a sample test application in C++ and C# and hard coded the input. By hard coding the input to doubleToInt function, I am getting same results.” This suggests that, given identical inputs, the C++ and C# versions of the function return identical outputs. We would deduce from this that the cause of different outputs is different inputs.

The OP also states ”While debugging, to compare the results, if I see the output of C++ and C#, it is different for the same set of values.“ However, this is inconclusive, because debuggers and print statements used for debugging often do not print the complete, exact value of floating-point objects. Quite often, they round to six significant digits. For example, a simple std::cout << x displays both 10000.875 and 10000.9375 as “10000.9”, but they are different numbers and would yield different outputs in doubleToInt.

In conclusion, the problem may be that earlier work in the program, before doubleToInt is called, experiences floating-point rounding or other errors and passes different values to doubleToInt in the C++ and C# versions. To test for this, print the exact inputs to doubleToInt and see if they differ in the two versions.

Printing the inputs exactly might be done with:

• Use the %a format if your implementation supports it. (This is a C feature for printing floating-point values in hexadecimal floating-point notation. Some C++ libraries support it when printf is used.)
• Set the precision very high and print, as with std::cout.precision(100). Some C++ implementations may still not print the exact value (which is a quality issue), but they should print enough digits to distinguish the exact value from neighboring double values.
• Print the bytes of the representation of the value (by converting a pointer to the floating-point object to a pointer to unsigned char and printing the individual char objects).

Based on the code presented, the problem is unlikely to be floating-point issues in doubleToInt. The language definitions permit some slack in floating-point evaluation, so it is theoretically possible that d+.1 is evaluated with excess precision, instead of normal double precision, and then converted to int or short. However, this would result in different results only in very rare cases, where d+.1 evaluated in double precision rounds up to an integer but d+.1 evaluated in excess precision remains just below the integer. This requires that about 38 bits (53 bits in the double significand minus 16 bits in the integer portion plus one bit for rounding) have specific values, so we would expect it to occur only about 1 in 275 billion times by chance (assuming a uniform distribution is a suitable model).

In fact, the adding of .1 suggests to me that somebody was trying to correct for floating-point errors in a result they expected to be an integer. If somebody had a “natural” value they were trying to convert to an integer, the usual way to do it would be to round to the nearest value (as with std::round) or, sometimes, to truncate. Adding .1 suggests they were trying to calculate something they expected to be an integer but were getting results like 3.999 or 4.001, due to floating-point errors, so they “corrected” it by adding .1 and truncating. Thus, I suspect floating-point errors exist earlier in the program. Perhaps they are exacerbated in C#.

Answer 2

You're trying to round numbers here, using the default rounding. C++ didn't mandate the direction of rounding, and it's probably different from C# given the different results.

Answer 3

Your functions would technically produce different results should the double values exceed sizeof(short/int) on a given platform.

Both of the functions have possibilities to lose data as you're truncating (losing precision) from a double to an int or short. Assuming you're targeting a MS environment sizeof(double) == 8, sizeof(int) == 4, and sizeof(short) == 2; this is true for both C++ and C# in a Windows environment (endian-ness and bit-ness (32/64) are irrelevant in these sizes in an MS build).

You also need to give more information as to what's happening AFTER the functions are called to generate the binary output. Technically speaking 'binary' file output is only of unsigned character output (i.e. sizeof() == 1); meaning how you 'write' the output of your functions to the file can also severely affect your files in both C++ and C# with regards to outputting numeric types (double/int/short).

Are you using an fopen call in C++ with a specific formatted output to the file, or are you using std::fstream (or something else)? How are you writing the data to the file in C# as well? Are you doing something like file.Write(doubleToInt(d)) (assuming you're using a System.IO.StreamWriter) or are you using a System.IO.FileStream and converting the doubleToInt output to a byte[] then calling file.Write(dtiByteArr)?

All of that being said my best guess based on the information given would be that your C# function is returning a short instead of an int causing issues when the values passed in to the function are greater than short.MaxValue.

Answer 4

I think your problem is related to how the data (short) is written/read to/from the binary file. You need to consider Big-Endian/Small-Endian, so the data file is consistent no matter what platform the code is in.

Check the System.BitConverter class. The BitConverter.IsLittleEndian field can help with the conversion. The code should be something similar to the following:

  short value = 12348;
  byte[] bytes = BitConverter.GetBytes(value);
  Console.WriteLine(BitConverter.ToString(bytes));

  if (BitConverter.IsLittleEndian)
     Array.Reverse(bytes);

  Console.WriteLine(BitConverter.ToString(bytes)); // write to your file

Answer 5

I haven't completely set myself in to it, so maybe i can be wrong, but it could have something to do with what mentioned here: In a thread about the difference on Float, Decimal and Double

As hey says: Double which you are using, are in C# a floating binary point type. (10001.10010110011) maybe, Double in C++ are more like decimal in C# a floating decimal point type. (12345.65789) And if you compare floating binary point type and floating decimal point type, it wont give the same result.