gmpy/decimal interoperation

[Alex Martelli]

As things stand now (gmpy 1.01), an instance d of decimal.Decimal cannot
transparently become an instance of any of gmpy.{mpz, mpq, mpf}, nor
vice versa (the conversions are all possible, but a bit laborious, e.g.
by explicitly going through string-forms).

I'm thinking about possible ways to fix this, in whole or in part, but,
before I spend more time on this, I was wondering if there's anybody
else who'd be interested -- if so, maybe we can discuss which
conversions should happen implicitly (e.g., if you try to sum a Decimal
and an mpz, maybe the latter should implicitly become a Decimal, just
like an int would, so that the result is a Decimal) and which ones
should only happen on explicit request (e.g., gmpy.mpf(d) should produce
an mpf instance, just as calling gmpy.mpf on an int instance would).


Alex

 

[Nick Craig-Wood]

As things stand now (gmpy 1.01), an instance d of decimal.Decimal cannot
transparently become an instance of any of gmpy.{mpz, mpq, mpf}, nor
vice versa (the conversions are all possible, but a bit laborious, e.g.
by explicitly going through string-forms).

I'm thinking about possible ways to fix this, in whole or in part, but,
before I spend more time on this, I was wondering if there's anybody
else who'd be interested

I can't ever imaging mixing the two. I use GMPY when I want fast
inifinite precision artithmetic. I'd use decimal if I wanted to do
decimal arithmetic on currency or something like that (or perhaps if I
hadn't discovered GMPY in which case I wouldn't be mixing with GMPY!)

if so, maybe we can discuss which conversions should happen
implicitly

None I'd say! Perhaps make a less laborious manual conversion
function, but I don't think implicit conversion is that useful since
decimal and gmpy are solving quite different problems.

Implicit conversions also opens the can of worms - what is the
preferred promotion type? decimal + mpf == decimal? mpf? mpq?

IMHO of course!

 

[Raymond L. Buvel]

As things stand now (gmpy 1.01), an instance d of decimal.Decimal cannot
transparently become an instance of any of gmpy.{mpz, mpq, mpf}, nor
vice versa (the conversions are all possible, but a bit laborious, e.g.
by explicitly going through string-forms).

I'm thinking about possible ways to fix this, in whole or in part, but,
before I spend more time on this, I was wondering if there's anybody
else who'd be interested -- if so, maybe we can discuss which
conversions should happen implicitly (e.g., if you try to sum a Decimal
and an mpz, maybe the latter should implicitly become a Decimal, just
like an int would, so that the result is a Decimal) and which ones
should only happen on explicit request (e.g., gmpy.mpf(d) should produce
an mpf instance, just as calling gmpy.mpf on an int instance would).


Alex

This is a bit off topic but I would like to know how you would go about
doing an implicit operation with an mpz and Decimal becoming a Decimal.
I would like to use something like this to make the float and complex
types more interoperable with mpq and cmpq in my clnum module
(http://calcrpnpy.sourceforge.net/clnumManual.html). In those cases, I
would like the mpq to degrade to float and the cmpq to degrade to
complex (right now they just raise exceptions). Seems like you need to
either modify the target type to recognize the new one or the code has
to get very complex to handle all the combinations.

Ray

 

[Alex Martelli]

This is a bit off topic but I would like to know how you would go about
doing an implicit operation with an mpz and Decimal becoming a Decimal.

I would tweak Decimal.__new__ to accept an mpz and perform an int() on
it before proceeding as it does now, for example.

I would like to use something like this to make the float and complex
types more interoperable with mpq and cmpq in my clnum module
(http://calcrpnpy.sourceforge.net/clnumManual.html). In those cases, I
would like the mpq to degrade to float and the cmpq to degrade to
complex (right now they just raise exceptions). Seems like you need to
either modify the target type to recognize the new one or the code has
to get very complex to handle all the combinations.

Modifying the target type is indeed what I had in mind (for Decimal).
As long as the target-type is Python-coded, you can substitute its
__new__ with a wrapped version. Unfortunately, float and complex
aren't; but fortunately, Python does have for these cases appropriate
special methods/slot that your SOURCE type can implement. In gmpy, I
have float 'upgraded' to mpq (with a Stern-Brocot heuristic), but it
wouldn't be any harder to have the mpq 'degrade' to float instead.


Alex