Override equality for floating point values in Scala

Question

Note: Bear with me, I'm not asking how to override equals or how to create a custom method to compare floating point values.

Scala is very nice in allowing comparison of objects by value, and by providing a series of tools to do so with little code. In particular, case classes, tuples and allowing comparison of entire collections.

I've often call methods that do intensive computations and generate o non-trivial data structure to return and I can then write a unit test that given a certain input will call the method and then compare the results against a hardcoded value. For instance:

def compute() =
{
   // do a lot of computations here to produce the set below...
   Set(('a', 1), ('b', 3))
}

val A = compute()
val equal = A == Set(('a', 1), ('b', 3))  
// equal = true

This is a bare-bones example and I'm omitting here any code from specific test libraries, etc. Given that floating point values are not reliably compared with equals, the following, and rather equivalent example, fails:

def compute() =
{
   // do a lot of computations here to produce the set below...
   Set(('a', 1.0/3.0), ('b', 3.1))
}

val A = compute()
val equal2 = A == Set(('a', 0.33333), ('b', 3.1))  // Use some arbitrary precision here
// equal2 = false

What I would want is to have a way to make all floating-point comparisons in that call to use an arbitrary level of precision. But note that I don't control (or want to alter in any way) either Set or Double.

I tried defining an implicit conversion from double to a new class and then overloading that class to return true. I could then use instances of that class in my hardcoded validations.

implicit class DoubleAprox(d: Double)
{
   override def hashCode = d.hashCode()
   override def equals(other : Any) : Boolean = other match {
      case that : Double => (d - that).abs < 1e-5
      case _ => false
   }
}

val equals3 = DoubleAprox(1.0/3.0) == 0.33333  // true
val equals4 = 1.33333 == DoubleAprox(1.0/3.0)  // false

But as you can see, it breaks symmetry. Given that I'm then comparing more complex data-structures (sets, tuples, case classes), I have no way to define a priori if equals() will be called on the left or the right. Seems like I'm bound to traverse all the structures and then do single floating-point comparisons on the branches... So, the question is: is there any way to do this at all??

---

As a side note: I gave a good read to an entire chapter on object equality and several blogs, but they only provides solutions for inheritance problems and requires you to basically own all classes involved and change all of them. And all of it seems rather convoluted given what it is trying to solve.

Seems to me that equality is one of those things that is fundamentally broken in Java due to the method having to be added to each class and permanently overridden time and again. What seems more intuitive to me would be to have comparison methods that the compiler can find. Say, you would provide equals(DoubleAprox, Double) and it would be used every time you want to compare 2 objects of those classes.

Answer 1

I think that changing the meaning of equality to mean anything fuzzy is a bad idea. See my comments in Equals for case class with floating point fields for why.

However, it can make sense to do this in a very limited scope, e.g. for testing. I think for numerical problems you should consider using the spire library as a dependency. It contains a large amount of useful things. Among them a type class for equality and mechanisms to derive type class instances for composite types (collections, tuples, etc) based on the type class instances for the individual scalar types.

Since as you observe, equality in the java world is fundamentally broken, they are using other operators (=== for type safe equality).

Here is an example how you would redefine equality for a limited scope to get fuzzy equality for comparing test results:

// import the machinery for operators like === (when an Eq type class instance is in scope)
import spire.syntax.all._

object Test extends App {
  // redefine the equality for double, just in this scope, to mean fuzzy equali
  implicit object FuzzyDoubleEq extends spire.algebra.Eq[Double] {
    def eqv(a:Double, b:Double) = (a-b).abs < 1e-5
  }

  // this passes. === looks up the Eq instance for Double in the implicit scope. And 
  // since we have not imported the default instance but defined our own, this will
  // find the Eq instance defined above and use its eqv method
  require(0.0 === 0.000001)

  // import automatic generation of type class instances for tuples based on type class instances of the scalars
  // if there is an Eq available for each scalar type of the tuple, this will also make an Eq instance available for the tuple
  import spire.std.tuples._
  require((0.0, 0.0) === (0.000001, 0.0)) // works also for tuples containing doubles

  // import automatic generation of type class instances for arrays based on type class instances of the scalars
  // if there is an Eq instance for the element type of the array, there will also be one for the entire array
  import spire.std.array._
  require(Array(0.0,1.0) === Array(0.000001, 1.0)) // and for arrays of doubles

  import spire.std.seq._
  require(Seq(1.0, 0.0) === Seq(1.000000001, 0.0))
}

Answer 2

Java equals is indeed not as principled as it should be - people who are very bothered about this use something like Scalaz' Equal and ===. But even that assumes a symmetry of the types involved; I think you would have to write a custom typeclass to allow comparing heterogeneous types.

It's quite easy to write a new typeclass and have instances recursively derived for case classes, using Shapeless' automatic type class instance derivation. I'm not sure that extends to a two-parameter typeclass though. You might find it best to create distinct EqualityLHS and EqualityRHS typeclasses, and then your own equality method for comparing A: EqualityLHS and B: EqualityRHS, which could be pimped onto A as an operator if desired. (Of course it should be possible to extend the technique generically to support two-parameter typeclasses in full generality rather than needing such workarounds, and I'm sure shapeless would greatly appreciate such a contribution).

Best of luck - hopefully this gives you enough to find the rest of the answer yourself. What you want to do is by no means trivial, but with the help of modern Scala techniques it should be very much within the realms of possibility.