Optional delta argument for assertAlmostEqual
Hello all, A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding. This sounds great to me as the default implementation of assertAlmostEqual has *never* been useful to me (YMMV). In fact one of the first things I do on setting up a test suite is provide a TestCase that overrides assertAlmostEqual with an implementation that uses a delta rather than rounding. The implementation would be effectively: assert abs(actual - expected) < delta This has the advantage that it allows things like: self.assertAlmostEqual(timeStamp, expected, delta=datetime.timedelta(seconds=5)) The issue is this would make the signature of assertAlmostEqual (and its negative counterpart): def assertAlmostEqual(self, first, second, places=7, msg=None, delta=None) Note that delta comes after msg, which is different to other assert methods. To put delta before msg would be backwards incompatible with existing uses passing arguments positionally. In Python 3.2 we can make delta a keyword argument. Passing both places and delta would be an error (TypeError). Anyway, unless there are strenuous objections I intend to do this. All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Sat, Mar 27, 2010 at 12:59 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Hello all,
A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding.
+1. Mark
On Fri, Mar 26, 2010 at 5:59 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Hello all,
A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding.
This sounds great to me as the default implementation of assertAlmostEqual has *never* been useful to me (YMMV). In fact one of the first things I do on setting up a test suite is provide a TestCase that overrides assertAlmostEqual with an implementation that uses a delta rather than rounding.
The implementation would be effectively:
assert abs(actual - expected) < delta
This has the advantage that it allows things like:
self.assertAlmostEqual(timeStamp, expected, delta=datetime.timedelta(seconds=5))
The issue is this would make the signature of assertAlmostEqual (and its negative counterpart):
def assertAlmostEqual(self, first, second, places=7, msg=None, delta=None)
Note that delta comes after msg, which is different to other assert methods. To put delta before msg would be backwards incompatible with existing uses passing arguments positionally. In Python 3.2 we can make delta a keyword argument. Passing both places and delta would be an error (TypeError).
Anyway, unless there are strenuous objections I intend to do this.
+1 sounds good to me.
All the best,
Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
Perhaps not just absolute but relative tolerance, e.g.: def isclose(x, y, rtol=1.e-5, atol=1.e-8): return abs(x-y) <= atol + rtol * abs(y) On Fri, Mar 26, 2010 at 7:59 PM, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
Hello all,
A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding.
This sounds great to me as the default implementation of assertAlmostEqual has *never* been useful to me (YMMV). In fact one of the first things I do on setting up a test suite is provide a TestCase that overrides assertAlmostEqual with an implementation that uses a delta rather than rounding.
The implementation would be effectively:
assert abs(actual - expected) < delta
This has the advantage that it allows things like:
self.assertAlmostEqual(timeStamp, expected, delta=datetime.timedelta(seconds=5))
The issue is this would make the signature of assertAlmostEqual (and its negative counterpart):
def assertAlmostEqual(self, first, second, places=7, msg=None, delta=None)
Note that delta comes after msg, which is different to other assert methods. To put delta before msg would be backwards incompatible with existing uses passing arguments positionally. In Python 3.2 we can make delta a keyword argument. Passing both places and delta would be an error (TypeError).
Anyway, unless there are strenuous objections I intend to do this.
All the best,
Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/charles.r.mccreary%40gmail...
-- Charles McCreary P.E. CRM Engineering 903.643.3490 - office 903.224.5701 - mobile/GV
On Sun, 28 Mar 2010 02:54:19 pm Charles McCreary wrote:
Perhaps not just absolute but relative tolerance, e.g.:
def isclose(x, y, rtol=1.e-5, atol=1.e-8): return abs(x-y) <= atol + rtol * abs(y)
I'm not sure why you add the tolerances like that. Surely a more appropriate approach is to compare the values against the tolerances individually, and return True if they meet either condition. For what it's worth, here's a recipe I wrote for approximately equal, following someone's complaint on comp.lang.python that Python has no approximately-equal operator. http://code.activestate.com/recipes/577124-approximately-equal/ Comments and criticism welcome. I've never found unittest.TestCase.assertAlmostEqual to be useful. I generally write my own comparison function, then call: assert_(compare(x, y)) as needed. I'm +0.5 on Michael's suggested change -- it will make assertAlmostEqual marginally more useful, which is a plus, but I'm not sure that absolute tolerances are better than relative. But how general do we want to be? "Almost equal" means something different to everyone.
On Fri, Mar 26, 2010 at 7:59 PM, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
Hello all,
A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding. [snip]
-- Steven D'Aprano
A good summary on floating point comparison algorithms can be found at http://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/flo... I, too, redefine almostEquals so that the comparison is more robust +1 On Sun, Mar 28, 2010 at 2:06 AM, Steven D'Aprano <steve@pearwood.info>wrote:
On Sun, 28 Mar 2010 02:54:19 pm Charles McCreary wrote:
Perhaps not just absolute but relative tolerance, e.g.:
def isclose(x, y, rtol=1.e-5, atol=1.e-8): return abs(x-y) <= atol + rtol * abs(y)
I'm not sure why you add the tolerances like that. Surely a more appropriate approach is to compare the values against the tolerances individually, and return True if they meet either condition.
For what it's worth, here's a recipe I wrote for approximately equal, following someone's complaint on comp.lang.python that Python has no approximately-equal operator.
http://code.activestate.com/recipes/577124-approximately-equal/
Comments and criticism welcome.
I've never found unittest.TestCase.assertAlmostEqual to be useful. I generally write my own comparison function, then call:
assert_(compare(x, y))
as needed. I'm +0.5 on Michael's suggested change -- it will make assertAlmostEqual marginally more useful, which is a plus, but I'm not sure that absolute tolerances are better than relative. But how general do we want to be? "Almost equal" means something different to everyone.
On Fri, Mar 26, 2010 at 7:59 PM, Michael Foord <fuzzyman@voidspace.org.uk>wrote:
Hello all,
A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding. [snip]
-- Steven D'Aprano _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/charles.r.mccreary%40gmail...
-- Charles McCreary P.E. CRM Engineering 903.643.3490 - office 903.224.5701 - mobile/GV
On Fri, Mar 26, 2010 at 8:59 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Hello all,
A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding.
This sounds great to me as the default implementation of assertAlmostEqual has *never* been useful to me (YMMV). In fact one of the first things I do on setting up a test suite is provide a TestCase that overrides assertAlmostEqual with an implementation that uses a delta rather than rounding.
The implementation would be effectively:
assert abs(actual - expected) < delta
This has the advantage that it allows things like:
self.assertAlmostEqual(timeStamp, expected, delta=datetime.timedelta(seconds=5))
The issue is this would make the signature of assertAlmostEqual (and its negative counterpart):
def assertAlmostEqual(self, first, second, places=7, msg=None, delta=None)
Note that delta comes after msg, which is different to other assert methods. To put delta before msg would be backwards incompatible with existing uses passing arguments positionally. In Python 3.2 we can make delta a keyword argument. Passing both places and delta would be an error (TypeError).
Anyway, unless there are strenuous objections I intend to do this.
All the best,
Michael
+1, this would be very helpful to me. Geremy Condra
participants (6)
-
Charles McCreary -
geremy condra -
Gregory P. Smith -
Mark Dickinson -
Michael Foord -
Steven D'Aprano