On Tue, Jul 7, 2009 at 1:26 AM, Mark Dickinson<report@bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm@gmail.com> 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 <report@bugs.python.org>
> <http://bugs.python.org/issue6431>
> _______________________________________
>