Re: [Python-Dev] Mixing float and Decimal -- thread reboot
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 (but not ==, !=) between a >> complex number and another complex, float or int raise TypeError: >> > z = complex(0, 0) > z < int() >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: unorderable types: complex() < int() > z < float() >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: unorderable types: complex() < float() > z < complex() >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: unorderable types: complex() < complex() >> >> But Fraction is the odd man out: a comparison between a Fraction and >> a complex raises a TypeError for complex numbers with nonzero >> imaginary component, but returns a boolean value if the complex number >> has zero imaginary component: >> > z < Fraction() >> False > complex(0, 1) < Fraction() >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: unorderable types: complex() < Fraction() >> >> I'm tempted to call this Fraction behaviour a bug, but maybe it arises >> from the numeric integration themes of PEP 3141. Any ideas? > > I'd call it a bug. > Thanks, Jeffrey (and everyone else who answered). Fixed in r79456 (py3k) and r79455 (trunk). Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
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 attractive because it is a
> minimal change that provides a little protection for
> simple containers.
> I support either of those options.
Yes; those are the only two options I've seen that seem workable. Of
the two, I prefer the first (do nothing), but would be content with
second.
I'd be interested to know whether there's any real-life code that's
suffering as a result of nan != nan. While the nan weirdnesses
certainly exist, I'm having difficulty imagining them turning up in
real code.
Casey Duncan's point that there can't be many good uses for floats as
dict keys or set members is compelling, though there may be
type-agnostic applications that care (e.g., memoizing). Similarly,
putting floats into a list must be very common, but I'd guess that
checking whether a given float is in a list doesn't happen that often.
I suspect that (nan+container)-related oddities turn up infrequently
enough to make it not worth fixing.
By the way, for those suggesting that any operation producing a nan
raise an exception instead: Python's math module actually does go out
of its way to protect naive users from nans. You can't get a nan out
of any of the math module functions without having put a nan in in the
first place. Invalid operations like math.sqrt(-1), math.log(-1),
consistently raise ValueError rather than return a nan. Ideally I'd
like to see this behaviour extended to arithmetic as well, so that
e.g., float('inf')/float('inf') raises instead of producing
float('nan') (and similarly 1e300 * 1e300 raises OverflowError instead
of producing an infinity), but there are backwards compatibility
concerns. But even then, I'd still want it to be possible to produce
nans deliberately when necessary, e.g., by directly calling
float('nan').
Python also needs to be able to handle floating-point data generated
from other sources; for this alone it should be at least able to read
and write infinities and nans.
Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
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 same NaN object. This is attractive because it is a >>minimal change that provides a little protection for >>simple containers. >> I support either of those options. > > Yes; those are the only two options I've seen that seem workable. Of > the two, I prefer the first (do nothing), but would be content with > second. I've ended up in the same place as Mark: +1 on retaining the status quo (possibly with better warnings about the potential oddities of floating point values being placed in equality-based containers), +0 on changing NaN equality to check identity first in order to provide reflexivity under == for these two types. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optional delta argument for assertAlmostEqual
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optional delta argument for 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 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
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 attractive because it is a > minimal change that provides a little protection for > simple containers. > I support either of those options. What's the flaw in using isnan()? -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
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 minded can get their nans working as they currently do)? -1 The numeric community uses NaNs as placeholders in vectorized calculations. But is this relevant to python itself ? In Numpy, we indeed do use and support NaN, but we have much more control on what happens compared to python float objects. We can control whether invalid operations raises an exception or not, we had isnan/isfinite for a long time, and the fact that nan != nan has never been a real problem AFAIK. Nonetheless, the closer our float arrays are to Python's float type, the happier I will be. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
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 the same NaN object. This is attractive because it is a minimal change that provides a little protection for simple containers. I support either of those options. 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(). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optional delta argument for assertAlmostEqual
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 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/charles.r.mccreary%40gmail.com > -- Charles McCreary P.E. CRM Engineering 903.643.3490 - office 903.224.5701 - mobile/GV ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
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 raise an exception. Conceptually, NaN should contaminate the result and make list.__contains__() return some "unsortable", but we don't want to bend the whole language backwards just for one obscure feature, especially when we have a much better approach most of the time (exceptions). The reason why NaN's current behaviour is so disturbing is that it increases the mental load of everybody dealing with floats. When you write new code or debug a program you have to ask yourself what might happen if a NaN is produced. When maintaining existing code you have to figure out if it's written a specific way to get NaN to work right, or if it's even a fluke that NaN's work right, even if it was never intended for NaNs or never sees them on developer machines. This is all the subtlety we work so hard to avoid normally, so why make an exception here? NaNs themselves have use cases, but their subtlety doesn't. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
