how to compare floating point numbers?

[sfindeisen]

Hi, what is the recommended way to go about comparing floating point numbers? I am aware of @?= and @=? operators, which route to assertEqual, but this of course doesn't work. What would be nice to have is assertClose (or similar) to compare 2 floating point numbers with respect to some predefined ε, i.e.: abs(a-b) < ε. Ideally ε would be configurable (somehow). What do you think? Will you accept a patch?

[andreasabel]

Can't you use a newtype with a suitable Eq instance? (Ignoring that epsilon-distance isn't actually transitive, so it is not an equivalence relation.)

newtype Precision5 = Precision5 Double

instance Eq Precision5 where
  Precision5 x == Precision5 y = abs (x-y) < 0.00001

[sfindeisen]

Technically speaking we could get away with this, yes, but why do you consider violating Eq transitivity to be a recommended practice? Plus, this complicates client code due to the extra type.

I will be happy to implement a patch for you, if this makes sense?

[Bodigrim]

If you try using assertClose, you'll quickly discover that sometimes you want to check abs(a-b) < ε, sometimes abs((a-b)/a) < ε, sometimes both, sometimes any. It's a job for a separate opinionated package, not for the core.

[andreasabel]

Yeah, maybe defining your own assert... functions/operators on top of assertFailure might be the way to go. Unless there is a clear consensus what the most common operators would be for floats, it does not make sense to add them here.

[sfindeisen]

How about just a single, unary operator for floats: abs(x) < ε. Would it cover all the cases?

[Bodigrim]

To be honest, abs(x) < ε looks even more ad-hoc.

FWIW when it comes to this kind of tests, I find it more expressive to use QuickCheck instead hunit.

[Mikolaj]

I suppose, if we define our own operator using tasty primitives, we can then make a tasty PR from it so that tasty devs can decide without blocking us. And if not enough primitives are exposed or they don't have the desired semantics, we can complain regardless of whether the operator is for our own library or for extending Tasty.Hunit.

[sfindeisen]

We eventually came up with such a design: https://github.com/sfindeisen/horde-ad/blob/sfindeisen/fix-46/test/common/TestCommonEqEpsilon.hs , see AssertClose class and its several instances. It uses HUnit-approx. Any interest?

Right now I am polishing this up and will delete assertion messages because we don't need them in our project.

[Mikolaj]

I was actually quite surprised https://hackage.haskell.org/package/HUnit-approx could be made to work with tasty. That's either a happy coincidence or the power of good Haskell APIs. And, after @sfindeisen proved it to be the case and my world-view reconfigured, I'm now surprised it's not yet integrated with tasty. [edit: "now", not "not"]

[Bodigrim]

That's no coincedence, tasty has a modular architecture, and @UnkindPartition always argued that anything which can be implemented as a plugin and maintained independently should be a separate package, spreading load away from core maintainers.

[Mikolaj]

Plugins such as https://hackage.haskell.org/package/tasty-quickcheck and https://hackage.haskell.org/package/tasty-hunit? So would tasty-hunit-approx be a sub-plugin of https://hackage.haskell.org/package/tasty-hunit or a separate plugin of tasty?

[Bodigrim]

Probably a separate plugin, implementing a test provider for HUnit-approx.

[Mikolaj]

Thanks. If somebody ever needs the feature, stumbles upon this ticket and wants to implement the plugin, we have all the essential parts and some example code using it in our library and the meat is in HUnit-approx, so this shouldn't be too hard. Committing to maintainership may be a more serious undertaking, but the tasty API doesn't move fast these days, so that's chasing GHCs mostly, probably?