Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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. :(

share|improve this question
well it looks like it is too accurate ;) – ratchet freak Dec 21 '12 at 15:43
did you look at… ? – mhoran_psprep Dec 21 '12 at 15:48
There is already an answer for this question. Btw, MSDN contains an interesting snippet HasMinimalDifference – Akim Dec 21 '12 at 15:59

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 = { 
      Console.WriteLine("{0:r} = {1:r}: =:{2} ae:{3} re:{4} hmd1:{5} hmd0:{6}", 
                        values[0], values[1],  
                        AlmostEqual(values[0], values[1]),
                        ReallyEqual(values[0], values[1]),
                        HasMinimalDifference(values[0], values[1], 1),
                        HasMinimalDifference(values[0], values[1], 0));

   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 )

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 = { 

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.

share|improve this answer

From Comparing Floating Point Numbers, 2012 Edition

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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