# Is this a good way to compare two numbers?

If we have double numbers, let's say I want to see if some double parameter is equal to zero that is passed as double:

``````public bool AlmostEqual(double x, double y)
{
double epsilon = Math.Max(Math.Abs(x), Math.Abs(y)) * 1E-15;
return Math.Abs(x - y) <= epsilon;
}
``````

considering double shows 15 accurate digits. So do you think what I wrote is good? or it has issues?

well then I just wrote a simple method like this:

``````public bool ReallyEqual(double x, double y)
{
return (x == y);
}
``````

and then I couldn't find a case that return values of those two methods are different. they were always returning the same result. :(

Understanding the decimal format and working with a properly crafted number, it is not difficult to find two values that have differing values.

``````using System;

public class Example
{
public static void Main()
{
double[] values = {
//12345678901234567
0.10000000000000001,
0.10000000000000002
};
Console.WriteLine("{0:r} = {1:r}: =:{2} ae:{3} re:{4} hmd1:{5} hmd0:{6}",
values, values,
values.Equals(values),
AlmostEqual(values, values),
ReallyEqual(values, values),
HasMinimalDifference(values, values, 1),
HasMinimalDifference(values, values, 0));
Console.WriteLine();
}

public static bool AlmostEqual(double x, double y) {
double epsilon = Math.Max(Math.Abs(x), Math.Abs(y)) * 1E-15;
return Math.Abs(x - y) <= epsilon;
}

public static bool ReallyEqual(double x, double y) {
return (x == y);
}

public static bool HasMinimalDifference(double value1, double value2, int units) {
long lValue1 = BitConverter.DoubleToInt64Bits(value1);
long lValue2 = BitConverter.DoubleToInt64Bits(value2);

// If the signs are different, return false except for +0 and -0.
if ((lValue1 >> 63) != (lValue2 >> 63))
{
if (value1 == value2)
return true;

return false;
}

long diff = Math.Abs(lValue1 - lValue2);
Console.WriteLine("HMD: {0} {1} {2} {3}",
lValue1, lValue2, diff, units);

if (diff <= (long) units)
return true;

return false;
}
}
``````

(If you want to play with this code online, it is at https://ideone.com/fwsq5o )

There are three functions here, the Almost Equal, the Really Equal and HasMinimalDifference (from Double.Equals Method (Double) @msdn)

Note that the numbers themselves that are being tested are almost the same, and when looking at the output of the numbers from within `HasMinimalDifference` they are only different by one bit in the representation.

The output of this program is:

```HMD: 4591870180066957722 4591870180066957723 1 1
HMD: 4591870180066957722 4591870180066957723 1 0
0.1 = 0.10000000000000002: =:False ae:True re:False hmd1:True hmd0:False
```

You can see the two invocations of `HasHminimalDistance` with the two units arguments (1 and 0). Only the last number between the two is different, and if you call `HasHminimalDistance` with 0 as the third parameter it is equivalent to an expensive `.Equals`.

With these numbers:

• `Equals` is false
• `AlmostEquals` is true
• `ReallyEqual` is false
• `HasHminimalDistance` allowing for 1 unit of slop is true
• `HasHminimalDistance` allowing for 0 units of slop is false

You can get two floating point numbers that are really similar and its a question of if you want to consider them the same or similar or not. Some applications two things are the same if they are within some tolerance, other applications need exact values to be the same. The later set of applications might wish to consider exact math classes such as BigDecimal for situations where you want to to work with exact values that don't accidentally get some floating point inaccuracy rounding it and an incorrect exactly equal value propagate through the system.

One thing to consider here with the question as it is written is for comparisons with zero which deal with a rather special number - zero.

If we change the numbers we look at to:

``````  double[] values = {
//12345678901234567
0,
Double.Epsilon
};
``````

We will see:

```HMD: 0 1 1 1
HMD: 0 1 1 0
0 = 4.94065645841247E-324: =:False ae:False re:False hmd1:True hmd0:False
```

When we look at `AlmostEqual(0, Double.Epsilon)` we see that `epsilon` (the local var) has a value of 0 (`Double.Epsilon * 1E-15` == 0). Then `Math.abs(x-y)` is equal to Double.Epsilon, which is greater than 0. So for 0, the only way for this type of approach to be true is if the number is identical to 0 - not just really close.

The `HasMinimalDifference` call, however, is looking at the difference in the bits and can allow 0 and 1 (`Double.Epsilon` cast to a long) to be close enough.

• double.Epsilon is not a useful value for comparing numbers (it's the smallest possible value of double). C++'s DBL_EPSILON (about 2e-16) is simply the step between 1 and the next possible value. Similarly, see float.Epsilon (also useless) and FLT_EPSILON in C++ (about 1e-7). – Aaron Franke Sep 24 '18 at 8:52

There is no silver bullet. You have to choose wisely.

If you are comparing against zero, then relative epsilons and ULPs based comparisons are usually meaningless. You’ll need to use an absolute epsilon, whose value might be some small multiple of FLT_EPSILON and the inputs to your calculation. Maybe.

If you are comparing against a non-zero number then relative epsilons or ULPs based comparisons are probably what you want. You’ll probably want some small multiple of FLT_EPSILON for your relative epsilon, or some small number of ULPs. An absolute epsilon could be used if you knew exactly what number you were comparing against.

If you are comparing two arbitrary numbers that could be zero or non-zero then you need the kitchen sink. Good luck and God speed.

Working with floats is not trivial, so I urge you to read up more on how they work. What I quoted is part of a long series of articles explaining the intricacies and complexities of working with floats. Here's the first post. I find it more digestible than What Every Computer Scientist Should Know About Floating Point Numbers.