On Fri, Mar 26, 2010 at 8:59 PM, Michael Foord
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 defa
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/floating_point_comparison.html
I, too, redefine almostEquals so that the comparison is more robust
+1
On Sun, Mar 28, 2010 at 2:06 AM, Steven D'Aprano
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 t
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 wrote:
> Hello all,
>
> A user has suggested an optional argument to
> unittest.TestCase.assertAlmostEqual
On Fri, Mar 26, 2010 at 5:59 PM, Michael Foord
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 defa
On Sat, Mar 27, 2010 at 12:59 AM, Michael Foord
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
___
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 usefu
