5

I am writing numerical calculation software using .NET C#, which needs to be blazingly fast. There is a lot of fractional math. So using decimal type is pretty much out of the question, given its poor speed relative to using double. But of course double has its problems testing for equality, with floating point rounding issues.

My options seem to be subclassing double and overriding ==, < and >; versus creating extension methods for double equivalent to these. My tendency is to go with the latter - less code to change and maybe it will be less confusing to others reading the code later? Is there another option? What are other good reasons to choose one over the other?

  • 19
    How would you subclass double when it's a value type and, by definition, not eligible to be a base class? – Damien_The_Unbeliever Oct 21 at 7:42
  • 12
    Note that "blazingly fast" software is unless if it gives completely wrong answers. I also question whether C# is an appropriate choice given your stated requirements. For maximal performance of correct maths, Fortran usually wins. – OrangeDog Oct 21 at 8:18
  • 2
    @OrangeDog Fortran doesn't buy you anything over C++ or Rust unless perhaps if you're using arrays that are parallelized across a supercomputer cluster. And whilst garbage-collected languages like C#, Java and Haskell are indeed generally somewhat slower, it's not a huge difference (whereas dynamic languages or decimal arithmetic are much slower than floating-point in any of those languages). So, it can be a perfectly valid decision to use C# here. – leftaroundabout Oct 21 at 9:02
  • 2
    @OrangeDog BLAS deals with an extremely simple, extremely homogeneous sort of problem, which thus lends itself ideally for Fortran. For linear algebra, the right thing to do is generally to call that library, regardless from what language you use yourself. (Also: neither C nor Fortran is best in BLAS – Cuda is.) – leftaroundabout Oct 21 at 9:59
  • 3
    What kind of numerical calculations are you doing that equality tests are important? Generally algorithms in numerical analysis rely more on tests for inequality. E.g., you deem an algorithm converged when the error is less than some tolerance. About the only time you test for (approximate) equality in practice is when validating results against a known standard, and there it's easy enough to just use an approximate comparison subroutine, instead of pretending that you're really testing for "equality". – Nobody Oct 21 at 13:26
47

"double has its problems testing for equality".

No, that is not true. "double" does not have such problems. Equality testing for double values is well defined and usually works as it should (which may sometimes not be what several programmers expect, of course).

True is: programmers have often problems with testing for equality correctly in numerical software. You cannot simply fix this by using another data type, or by providing some standard equality comparers with some standard precision for equality up-front. Though such approaches may be part of a solution, you first and foremost need to make sure the programmers in your team know how to do floating point comparisons correctly.

Before reading the rest of my answer, please have a look into "What Every Computer Scientist Should Know About Floating-Point Arithmetic". Now. No excuses.

So, since you read this paper, you now have learned that there are several alternatives on how comparisons can be done when using floating point numbers, and one has pick the correct one for the specific case. For example, it may be necessary to take absolute or relative errors into account, to analyse the required precision for each individual comparison/quantity, or to take the specific operations and algorithms into account which will be used in the numerical software you are designing. Another thing which might be necessary is to adapt the scaling of some quantities, or other measures to keep rounding errors under control.

To find out what one really needs, I would recommend starting to implement some of the algorithms and determine precisely which kind of floating point comparisons are required there. When comparisons of the same kind occur more than two or three times, then it is time to refactor them into a reusable library (maybe using extension methods, which is a useful way in C# whenever it comes to add some reuseable methods to an existing type one cannot change). It should be clear now why overloading an operator like == is not useful, since there is only one such operator per type, with no additional parameters like a precision.

Don't try this up-front until you have already written several of such numerical programs!

| improve this answer | |
  • 12
    The floating point article is a classic and definitely recommended reading. But I do think it IS fair to say that "double has its problems testing for equality", since the results are different than their would mathematically. Sure it's up to programmers to work around it, but it's definitely a limitation of doubles, inevitable though it may be. – Mark Oct 21 at 11:39
  • 5
    @Mark: Lots of iterative numerical algorithms require to stop when the value of some function goes below some "epsilon" - and the number of iterations depend on how epsilon is chosen deliberately. Choosing epsilon=zero would end up in an infinite loop, even if there would be something like a infinitely precise fractional data type available. – Doc Brown Oct 21 at 12:05
  • 2
    ... where I agree is that sometimes the typical "64 bits" for a double are not enough, and there are problems where 128 bit floating point numbers can be more useful. But to find out when this is the case, one will need usually need a firm understanding of the requirements of the specific situation. – Doc Brown Oct 21 at 12:10
  • 5
    @Mark: the OP did not make the comparison "double" versus "real numbers", they made the comparsion "double" vs. "some higher precision type like decimal", and my point is that this is a misconception - higher precision types will always lead the the same problems. What you call a "limitation of double" I would only call "a limitation of having to work on real hardware where any fractional number will get only a small, finite number of bits for its representation, whatever type one choses to work with". – Doc Brown Oct 22 at 13:06
  • 3
    @SilentAxe That expression does not give a wrong answer. It's only wrong if you make the assumption that "double precision float" and "real numbers" are the same. If you do write your model assuming they are the same, you will be surprised. That all being said, the argument typically made is that "3.0" and "3.0000000000000001" are different spellings of the same floating point number, just as "1.0" and "0.999..." are different spelling of the same real number. – Cort Ammon Oct 22 at 20:43
26

financial calculation software

double has its problems testing for equality, with floating point rounding issues.

These two problems are not compatible. Do not write a == that isn't transitive, especially not for financial software. Depending on the calculations you are doing, you might not need floating point numbers at all, but rather do everything in fixed point (i.e. integer) arithmetic.

| improve this answer | |
  • 1
    Unfortunately, programming languages nowadays are expected to define == and != in a broken non-transitive fashion for floating-point types, rather than specifying e.g. that if x and y are both NaN, x==y, x>=y, and x<=y will be true (and other comparisons false), and if x is NaN and Y isn't or vice versa, x!=y will be true and all other comparisons false. That would have allowed testing for NaN via !(x>=0 || x<=0), while keeping == as an equivalence relation. – supercat Oct 21 at 16:47
  • 2
    @supercat as far as I can tell, you're just proposing another kind of broken. There are different reasons for a number to be NaN, but the reason isn't saved in the object. So you really cannot assume NaN==NaN, because that could mean 0/0==sqrt(-1). – Eric Duminil Oct 22 at 5:42
  • 1
    @supercat also, do you have an example of non transitive ==? The only half surprising fact I could find is that == isn't reflective with NaN.!= cannot be transitive, and isn't supposed to be, is it? – Eric Duminil Oct 22 at 6:59
  • 3
    To combine NaN with ==, you need NaB - not a Boolean. The fundamental idea of NaN is that it propagates through calculations, and that means it has to propagate through expressions involving booleans as well. – MSalters Oct 22 at 9:09
  • 1
    @supercat == over { NaN } is vacuously transitive, because the relation is empty – Caleth Oct 22 at 15:29
13

Don’t do that. Think about what you really want and name functions accordingly. Given a number x, there is a range of numbers that are likely equal to x (those close to x). A number is definitely greater than x if it is greater, and not in the LikelyEqual range. A number is likely greater or equal x if it is greater or equal to x or in the LikelyEqual range etc. You want these functions:

LikelyEqual
LikelyNotEqual
DefinitelyGreater
LikelyGreaterOrEqual
DefinitelyLess
LikelyLessorEqual

This solution makes it absolutely clear what your code does. Your solution is clever. Clever is rarely a good idea.

| improve this answer | |
  • 7
    I'd call it "nearly equal" or "mostly equal" not "likely". – Bergi Oct 21 at 7:34
  • Agree with Bergi. Epsilon is definitely greater than zero. Also, this does not communicate whether the values have an small absolute or relative difference. – MSalters Oct 22 at 9:11
8

Extension methods seem to be the best way to go here, so we don't confuse "exactly equal" with "almost equal." An optional precision argument should be used (give a default that is best for the general situation; it can always be overridden). So for testing "equality", have something like

public static bool ApproxEqual(this double a, double b, double precision = 0.0000000001)
{
    return Math.Abs(a - b) <= precision;
}
| improve this answer | |
  • Instead of 0.0000001 which is subject to rounding issues as well, why not epsilon instead ? – Christophe Oct 20 at 22:54
  • 7
    @Christophe because Double.Epsilon is ~5e-324, which is way beyond the floating point error ranges. Using that results in essentially overloading ==/</>. – Conrad Oct 20 at 23:12
  • 6
    In numerical simulation software, one should always analyse what precision is required when ApproxEqual is used, in the specific usage context. So I would heavily recommend against providing any default value for precision . Force the user of such a function always to think about the required precision, and make them choose a value for it deliberately. – Doc Brown Oct 21 at 5:59
  • 1
    This function is not good for the general case. Better would be a absolute and a relative tolerance (with either no default argument (as DocBrown suggests) or default argument set to zero (with a better name for the function ) ). With only absolute precision you get arbitrarily large relative errors for small numbers (e.g. comparison with 0 or anything that is smaller than precision). For large numbers this even reduces to the exact comparison. You make here an implicit assumption on the magnitude of numbers you want to compare. For "numerical calculation" use-case this cannot be made. – Andreas H. Oct 21 at 7:17
  • 8
    To apply the best, most favorable interpretation of the answerer's intention, I think this answer points out that the tolerance (whether absolute or relative or both) is something that needs to be injected into the relation comparison function (i.e. allowing customization at each use site), rather than baked into the user-defined type. That is it. It does not go into considering what would be considered an actual, "industrially robust" implementation. – rwong Oct 21 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.