On 26 January 2015 at 11:21, Chris Barker <chris.barker@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@gmail.com | Brisbane, Australia