On Sat, Mar 27, 2010 at 18:27, Robert Kern wrote:
> On 2010-03-27 13:36 , Adam Olsen wrote:
>> What's the flaw in using isnan()?
>
> There are implicit comparisons being done inside list.__contains__() and
> other such methods. They do not, and should not, know about isnan().
Those methods should
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 2010-03-27 13:36 , Adam Olsen wrote:
On Fri, Mar 26, 2010 at 17:16, Raymond Hettinger
wrote:
Of the ideas I've seen in this thread, only two look reasonable:
* Do nothing. This is attractive because it doesn't break anything.
* Have float.__eq__(x, y) return True whenever x and y are
t
On 2010-03-27 00:32 , David Cournapeau wrote:
On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger
wrote:
On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
How about raising an exception instead of creating nans in the first place,
except maybe within specific contexts (so that the IEEE-754 min
On Fri, Mar 26, 2010 at 17:16, Raymond Hettinger
wrote:
> Of the ideas I've seen in this thread, only two look reasonable:
> * Do nothing. This is attractive because it doesn't break anything.
> * Have float.__eq__(x, y) return True whenever x and y are
> the same NaN object. This is attracti
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
___
Mark Dickinson wrote:
> On Fri, Mar 26, 2010 at 11:16 PM, Raymond Hettinger
> wrote:
>> Of the ideas I've seen in this thread, only two look reasonable:
>> * Do nothing. This is attractive because it doesn't break anything.
>> * Have float.__eq__(x, y) return True whenever x and y are
>>the s
On Fri, Mar 26, 2010 at 11:16 PM, Raymond Hettinger
wrote:
> Of the ideas I've seen in this thread, only two look reasonable:
> * Do nothing. This is attractive because it doesn't break anything.
> * Have float.__eq__(x, y) return True whenever x and y are
> the same NaN object. This is attra
On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin wrote:
> On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson wrote:
>> Slight change of topic. I've been implementing the extra comparisons
>> required for the Decimal type and found an anomaly while testing.
>> Currently in py3k, order comparisons (b
10 matches
Mail list logo
