[Python-ideas] PEP 485: A Function for testing approximate equality

[Nick Coghlan]

On 26 January 2015 at 11:21, Chris Barker <chris.barker at noaa.gov> wrote:
> I think I addressed most of these issues in the summary note I jsut posted,
> but a few specific comments:
>
>
>> Unfortunately, I don't think we can change assertAlmostEqual. If we
>> change the implementation, tests which were passing may fail, and tests
>> which were failing may pass.
>
>
> Agreed -- would have thought that was off the table. And ti's really a
> different test than the proposal -- it is an absolute_tolerance test, but
> where the tolerance is specified in number of decimal digits after the
> decimal point (or an optional specific delta) -- not really that useful ,
> but I guess if you have assertTrue(), then why not?

Since Python 3.2, unittest.assertAlmostEqual has also supported a
"delta=value" keyword argument to specify an absolute tolerance
directly, rather than using a number of decimal places. It's mutually
exclusive with the default "places" argument.

I may be missing something, but is there a reason that couldn't be
adjusted to also accept a "error_ratio" keyword argument that was
mutually exclusive with the other two ("places" and "delta")? With the
keyword arguments all being about different ways to specify the error
tolerance, I think it would be reasonable to leave that implicit
rather than mentioning it in each name.

The "places=N" argument could also potentially be adjusted to be a
shorthand for "delta=10e-N" rather than its current definition.

The mutual exclusion between "error_ratio" and "delta" would require
some adjustment to handle values that may be near zero, but it's not
clear to me that there's a generally applicable answer to how best to
handle that, so it seems advisable to avoid trying to guess.

Regards,
Nick.

P.S. I considered suggesting just "ratio", but that's ambiguous in a
way that "delta" isn't: "ratio" could be referring to the ratio of the
two numbers, rather than the ratio of the error to the magnitude of
the expected value.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia