[Python-Dev] Mixing float and Decimal -- thread reboot (original) (raw)
Mark Dickinson dickinsm at gmail.com
Sat Mar 27 12:12:02 CET 2010
- Previous message: [Python-Dev] Mixing float and Decimal -- thread reboot
- Next message: [Python-Dev] Mixing float and Decimal -- thread reboot
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson <dickinsm at gmail.com> 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
- Previous message: [Python-Dev] Mixing float and Decimal -- thread reboot
- Next message: [Python-Dev] Mixing float and Decimal -- thread reboot
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]