This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author casevh
Recipients casevh, jyasskin, mark.dickinson
Date 2009-07-07.15:45:00
SpamBayes Score 7.271961e-15
Marked as misclassified No
Message-id <>
In-reply-to <>
On Tue, Jul 7, 2009 at 1:26 AM, Mark Dickinson<> wrote:
> Mark Dickinson <> added the comment:
> I agree this should be fixed.  The conversion to float in the else
> clause seems wrong to me: it can lose precision, making two unequal
> values compare equal.  I also agree that we should be getting
> NotImplemented here.
> Do you have a patch available?

I'll upload a patch this evening.

> As an aside, I'm interested that you're implementing comparisons between
> mpf and Decimal;  how does that work?  Do you also implement binary
> arithmetic operations between mpf and Decimal?  What's the result type?

When I do binary operations (including comparison), I check the type
of both operands. If both operands are Integer (mpz, int, long), I
convert both operands to an mpz and then perform the operation.
Otherwise, if both operands are Rational (mpz, int, long, mpq,
Fraction), I convert both operands to an mpq. Finally, if both
operands appear to be a Number (mpz, int, long, mpq, Fraction, mpf,
Decimal), I convert both operands to an mpf. In the latest release of
GMPY, I always return a GMPY type (unless you are converting to float
or int/long).

To do the conversions, I just do mpq(str(Fraction)) or
mpf(str(Decimal)). I realize that the conversions aren't perfect but
are probably what a user expects. The fact that GMP uses radix 2^32 or
2^64 floating point with (randomly) either [prec+1] or [prec+2] digits
makes predictable floating point challenging. ;-) (prec =
floor(precision_in_bits/limb_size).) In GMPY 1.04, I forced all mpf
results to have [prec+1] digits but it's still messy. Time to start
working on MPFR support.
> ----------
> nosy: +jyasskin, marketdickinson
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2009-07-07 15:45:04casevhsetrecipients: + casevh, mark.dickinson, jyasskin
2009-07-07 15:45:02casevhlinkissue6431 messages
2009-07-07 15:45:01casevhcreate