Numerical inconsistency in .NET

235 views Asked by At

I’m building a CAD-like application in C#. I’m using SlimDX as the graphics engine, and for the number-crunching part, I build custom libraries which ultimately rely on the System.Math class, naturally.

Now, the thing is that the SlimDX libraries use structures composed of the float data type, whereas the Math class contains several methods that only accept and return double objects, for example: Math.Ceiling, and Math.Sin. So I find myself casting my data back and forth, from float to double, constantly.

This doesn’t seem right. I’m not that concerned with the impact on performance the casts might cause (maybe I should be?), but with the numerical instabilities that may arise because of them, which is far more frightening.

So I just wanted to know how you usually manage these kinds of situations, as I’m guessing this must not be an uncommon scenario.

2

There are 2 answers

6
competent_tech On BEST ANSWER

If this were my application and I was that concerned about the possible loss of integrity, I would recreate the appropriate methods using the required data types.

.Net is a general platform that attempts to solve a majority of problems, but it can't solve them all. Although it may be extra work in the short term, if the precision is truly a concern, the time invested will be well worthwhile.

1
Jon Hanna On

There shouldn't be any numerical inconsistencies.

Of the three floating-point datatypes in .NET (float, double and the F type not available to C# but used internally in many members) there are going to be three times they come up:

  1. The storage and definitions done by your application's mathematical engine.
  2. The calculation done by this engine.
  3. Rendering.

Number 1 would presumably be mostly defined in terms of double. Number 2 will also be defined largely in terms of double though it will make some use of F as well. Number 3 will be defined in terms of single for the reasons you give, but if the boundaries between the layers is well-defined this shouldn't have any impact on what is actually calculated.