[Python-Dev] Mixing float and Decimal -- thread reboot

[Guido van Rossum]

On Mon, Mar 22, 2010 at 10:26 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:
>>
>> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>>
>>   Decimal + float --> Decimal
>>
>> If everybody associated with the Decimal implementation wants this I
>> won't stop you; as I repeatedly said my intuition about this one (as
>> opposed to the other two above) is very weak.
>>
>> That's my vote.
>> I believe Nick chimed-in in agreement.
>> Mark, do you concur?
>
> Yes;  Decimal + float -> Decimal works for me; the greater flexibility
> of the Decimal type is the main plus for me.  I don't think my own
> intuition is particularly strong here, either.  It would be
> interesting to hear from major users of the decimal module (I have to
> confess to not actually using it myself very much).

You're unlikely to hear from them here... :-( Though maybe Raymond qualifies.

> I argued earlier for Decimal + float -> Decimal on the basis that the
> float->Decimal conversion can be done exactly;  but having thought
> about Decimal + Fraction it's no longer clear to me that this makes
> sense.  Having Decimal + float -> Decimal round the float using the
> current Decimal context still seems like a reasonable option.

So now we have a second-order decision to make -- whether
Decimal+float should convert the float to Decimal using the current
context's precision, or do it exactly. I think we should just follow
Decimal.from_float() here, which AFAIK does the conversion exactly --
the operation will already round properly if needed, and I don't think
it is a good idea to round twice in the same operation. (Even though
this is what long+float does -- but the situation is different there
since float has no variable precision.)

> Just for the record, I'd also prefer Decimal + Fraction -> Decimal.

I think that is pretty much uncontested. Though there are second-order
details to decide here too: Fraction + float converts the Fraction to
a float first and then just adds the floats; but but Fraction /
Decimal cannot always be computed exactly as a Decimal so here I'd
suggest rounding first because we have to in some cases (it's better
to be consistent, except for comparisons, which should always be done
exactly if at all possible).

> I don't want to let the abstractions of the numeric tower get in the
> way of the practicalities:  we should modify the abstractions if
> necessary!  In particular, it's not clear to me that all numeric types
> have to be comparable with each other.  It might make sense for
> Decimal + complex mixed-type operations to be disallowed, for example.

One of the reasons for having a numeric tower is actually that unless
you do at least comparisons right, you get into inconsistencies like a
== b, b ==c, a != c (and similar for orderings). Of course complex
doesn't play along with the orderings, but it does play along with ==.

Real and Complex are distinct stations in the numeric tower, and the
tower defines mixed Real-Complex operations as returning Complex
results, but it allows raising exceptions as well. Since Decimal(-1)
** Decimal('0.5') already raises an exception instead of returning a
complex number, I'm fine with following that example -- complex
numbers are definitely a specialty area.

PS. PEP 3141 defines some miscellaneous operations that any number in
the numeric tower ought to implement, e.g. x.imag, x.real and
x.conjugate().

-- 
--Guido van Rossum (python.org/~guido)