Go float comparison

Question

In order to compare two floats (float64) for equality in Go, my superficial understanding of IEEE 754 and binary representation of floats makes me think that this is a good solution:

func Equal(a, b float64) bool {
    ba := math.Float64bits(a)
    bb := math.Float64bits(b)
    diff := ba - bb
    if diff < 0 {
        diff = -diff
    }
    // accept one bit difference
    return diff < 2
}

The question is: Is this a more generic, more precise, and more efficient, way to compare two arbitrarily large or small floats for "almost equalness", than the old abs(diff) < epsilon hack? My reasoning being that if one allows only one bit difference in the binary representation, then the compared numbers certainly could not be any more equal, apart from strict equality, which obviously (as pointed out in the comments) can be checked with == for floats.

Note: I have edited the question to make it more clear.

Answer 1

Don't use bit representation of float64 as it don't make sense in a lot of cases. Just subtract two numbers to find out how much they differ:

package main

import (
    "fmt"
    "math"
)

const float64EqualityThreshold = 1e-9

func almostEqual(a, b float64) bool {
    return math.Abs(a - b) <= float64EqualityThreshold
}

func main() {
    a := 0.1
    b := 0.2
    fmt.Println(almostEqual(a + b, 0.3))
}

Answer 2

No, this is not the correct way compare floating-point values.

You have not actually stated your real problem—there is some reason you are trying to compare two floating-point numbers, but you have not said what it is.

Floating-point arithmetic is designed to perform approximate arithmetic. It is normal that there will be an accumulation of rounding errors in floating-point operations. These errors will generally be different when values are calculated in different ways, so floating-point arithmetic should not be expected to produce equal results.

In your example, these operations occurred:

• The decimal numeral “0.1” was converted to float64 (IEEE-754 64-bit binary floating-point). This produced the value 0.1000000000000000055511151231257827021181583404541015625, which is the closest float64 value to 0.1.

• The decimal numeral “0.2” was converted to float64. This produced 0.200000000000000011102230246251565404236316680908203125, which is the closest float64 value to 0.2.

• These were added. This produced 0.3000000000000000444089209850062616169452667236328125. In addition to the rounding errors that occurred when 0.1 and 0.2 were rounded to the nearest values in float64, this contains some additional rounding error because the exact sum cannot be represented in float64.

• The decimal numeral “0.3” was converted to float64. This produced 0.299999999999999988897769753748434595763683319091796875, which is the closest float64 value to 0.3.

As you can see, the result of adding 0.1 and 0.2 has accumulated different rounding errors from 0.3, so they are unequal. No correct test for equality will report they are equal. And, importantly, the errors that occurred in this example are specific to this example—different sequences of floating-point operations will have different errors, and the accumulated errors are not limited to the low bits of the numbers.

Some people try to compare by testing whether the difference is less than some small value. This is can be okay in some applications, but is it okay in your application? We do not know what you are trying to do, so we do not know what problems will occur. Tests that allow for a small error sometimes report incorrect results, either false positives (because they accept as equal numbers that would not be equal if computed with exact mathematics) or false negatives (because they reject equality for numbers that would be equal if computed with exact mathematics). Which of these errors is worse for your application? Will one of them cause a machine to break or a person to be harmed? Without knowing that, nobody can advise which incorrect result is acceptable, or even if either is.

Additionally, how large should the tolerance for error be? The total error that can occur in a calculation depends on the sequence of operations performed and the numbers involved. Some applications will have only a small final rounding error, and some applications can have massive errors. Nobody can give a recommendation about what value to use for the tolerance without knowing more about your specific sequence of operations. Also, the solution might not be to accept a tolerance in comparing numbers but to redesign your calculations to avoid error, or at least to reduce it.

No general solution for comparing floating-point values for “equality” exists because it is impossible for any such solution to exist.

Answer 3

In C++, I use a function (search for nearly_equal()) which in Go would look like this:

func nearlyEqual(a, b, epsilon float64) {

    // already equal?
    if(a == b) {
        return true
    }

    diff := math.Abs(a - b)
    if a == 0.0 || b == 0.0 || diff < math.SmallestNonzeroFloat64 {
        return diff < epsilon * math.SmallestNonzeroFloat64
    }

    return diff / (math.Abs(a) + math.Abs(b)) < epsilon
}

This computes a difference between input a and b then make sure the difference is under a given epsilon. The division removes the magnitude so the compare is simple.

---

The problem is that floating points use a number of bits as defined in their mantissa. What the mantissa represents depends on the exponent. So if you just compare the bits, you first need to "shift them properly". The operation above does that on the last line. The division is equivalent to a shift.

Assuming we had very large integers, we could have fixed point numbers with about 700 bits that have about 350 bits on the left of the decimal point and another 350 bits after the decimal point:

700             350               0
XXX ... XXXXXXX '.' XXXXXXX ... XXX

The float64 mantissa is 56 bits, so in that number representation above, most bits would be zeroes except for those 56 bits. If one number has those 56 bits far on the left and another with 56 bits far on the right, then those two numbers are very different and the above detects that.

With these fixed point numbers we could do something more or less like this:

// assume "fp" numbers are fixed point numbers and the shift works on those
fp_a := a << (350 + a.exponent)
fp_b := b << (350 + b.exponent)

fp_diff := math.Abs(fp_a - fp_b)

return fp_diff < fp_epsilon

The problems is that it would not be practical to implement numbers of 700 bits.