[Python-Dev] Re: Re: Decimal type question [Prothon]

[Mark Hahn]

On Mon, 9 Aug 2004 14:20:15 -0400, Tim Peters wrote:

> [Mark Hahn]
>> Forgive me if I'm being a pest,
> 
> Nope, not at all.
> 
>> but no one has commented on the real reason I asked the question.  What
>> does everyone think of the idea of having these three built-in numeric types?
> 
> It depends on your goals for Prothon, and also on the relative
> performance of the various numeric implementations.  Semantically, it
> would be nicest if Python used the IBM decimal type for everything by
> default (whether spelled 123, 123.0, or 123e0).  

Are you sure you mean that?  I have been assuming that there is a
fundamental need for an integer type that has no fraction.  There are many
places like indexing where you semantically want integers.  I think if
speed were no issue I'd still have integers and decimal floats.

> That's not gonna
> happen, both because of backward compatibility, and because our
> implementation of that type is "too slow".
> 
> I don't know how fast or slow the .NET Decimal type is on its own, let
> alone compared to whatever implementations of bigints and binary
> floats you're using.  Speed may or may not matter to your target
> audience (although, in reality, you'll have multiple audiences, each
> with their own irrational demands <wink>).

I'm already planning on using Jim's IronPython implementation of your
BigInts so I might as well port your Decimal code over for the Prothon
Decimal also.  The only thing I've ever stolen from Python for Prothon was
your bigint code so I might as well be consistent in my thievery. :-)

>> 1) An Int implemented with infinite precision integer (Python Longs) with
>> the constant/__str__ form of +-NN such as 0, -123, 173_394, etc.
>>
>> 2) A Decimal implemented with the .Net decimal float (or the IBM decimal if
>> the .Net decimal sucks too much) with the constant/__str__ form of +-NN.NN
>> such as 0.0, -123.0, 173_394.0, 173394.912786765, etc.
>>
>> 3) A binary Float implemented with the hardware floating point with the
>> constant/__str__ form of +-NN.NN+-eNN such as 0e0, -123e0, 173.39e+3,
>> 2.35e-78, etc.
> 
> Sounds decent to me, although the IBM flavor of decimal is a full
> floating-point type, and some apps will definitely want to use it for
> 6.02e23 thingies instead of the native binary Float.  Maybe use "d" as
> a "decimal float" exponent marker.

I would hate to mess up my "pure" scheme but it makes sense.  Will do.

>> There would be no automatic conversion except the / operator would convert
>> from Int to Decimal and the Math module would convert Int and Decimal
>> values to Float for almost all functions (except simple ones like abs, min,
>> max).
> 
> Int * Decimal will be very common in financial apps, and the latter
> are a prime use case for Decimal ("OK, they bought 200 copies of
> 'Programming Prothon' at 39.98 each", etc).  Numeric auto-conversions
> that don't lose information are usually helpful.

When I wrote that I was thinking of no automatic conversion from Decimal to
Float.  Conversion from Int to Decimal would make sense as you suggest.

Thanks very much.  I think I have a handle on the issues now.  To
summarize, .Net sucks (no big surprise). :-)