# jUnit assert - what is delta?

louise rochford
Ranch Hand
Posts: 119
I'm struggling to understand the API for junit.framework.Assert - probably because my understanding of Maths terminology is weak.
assertEquals(double expected, double actual, double delta)
Asserts that two doubles are equal concerning a delta.
What is delta? I think I'm supposed to pass in a double representing the limit that the actual & expected can vary by and still be considered equal.
I can't remember where I read this or if I made it up.
Is it true? Is it usual to make the acuracy of the delta value more precise than the others, e.g. expected = 4.5, actual = 5.30, delta = 0.009?
Louise

Ernest Friedman-Hill
author and iconoclast
Marshal
Posts: 24212
35
The delta value is indeed the "error" or "uncertainty" allowed in the comparison. Comparing floating point numbers is tricky -- exact equality is hard to come by in many cases.
It's quite common for the delta to be much smaller than the actual values -- for no particular reason, I generally use 1e-8, and this works well.

Jim Yingst
Wanderer
Sheriff
Posts: 18671
I'm struggling to understand the API for junit.framework.Assert - probably because my understanding of Maths terminology is weak.
Also because the JUnit javadoc is rather poor, for such a widely used system. Fortunately the source code is available.
In this case, delta is the maximum allowed absolute difference between actual and expected value. So the test is basically

It's quite common for the delta to be much smaller than the actual values -- for no particular reason, I generally use 1e-8, and this works well.
Unless the values you're comparing are large enough that 1e-8 is below the roundoff error for the datatype. There's usually a wide range of values that can work acceptably well for delta, but it does depend on what datatype we're using and what magnitude the expected value has; there are plenty of case where 1e-8 would be completely ineffectual.
Personally I find it much easier to compare floats and doubles using a relative error. Here's a method I'd use:

Here the test is essentially

I've found that 1e-15 seems reasonable for a double; 1e-7 for a float. But higher values may legitmately be necessary in many situations, depending on what types of calculations were involved in generating a number. Error propagation in numeric calculations is probably too complex for this post, so perhaps it's best to just realize that in many cases you can just set the relative higher if you keep getting errors with a given value. The question you really need to ask is, how much accuracy do you really need? 1e-15 is an extremely small relative error for most applications; often you'd be OK with it as high as 1e-3 or even 1e-2. Depends on the situation; hard to say more.

Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34965
378
Sometimes I cast to int to get around this. (When expecting doubles with no decimal parts)

Does anyone see any problems with this approach? besides the fact that it can't be used everywhere...

Lasse Koskela
author
Sheriff
Posts: 11962
5
I think you're making your tests brittle for no real reason. It would be just as easy to provide a delta...

Ilja Preuss
author
Sheriff
Posts: 14112
Originally posted by Jeanne Boyarsky:
Sometimes I cast to int to get around this. (When expecting doubles with no decimal parts)

Does anyone see any problems with this approach?

Wouldn't the following pass? Would it be bad?

Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34965
378

Ilja Preuss
author
Sheriff
Posts: 14112
You're welcome!

Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
My favorite language ever - REXX - has a SET NUMERIC FUZZ option that sets the compare precision for numbers. I just love the name!

louise rochford
Ranch Hand
Posts: 119
Thanks for all your help guys

Eilidh Troup
Greenhorn
Posts: 1

The assertEqualsRelative didn't work when a negative value is expected. Here it is with Math.abs to fix it.