This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I'm struggling to understand the API for junit.framework.Assert - probably because my understanding of Maths terminology is weak. The javadocs state: 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? Thansk in advance, Louise
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.
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.
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?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus