extend methods of decimal module

[Steven D'Aprano]

On Fri, 28 Feb 2014 19:52:45 +1100, Chris Angelico wrote:

> On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>> On Fri, 28 Feb 2014 16:00:10 +1100, Chris Angelico wrote:
>>
>>> If we had some other tag, like 'd', we could actually construct a
>>> Decimal straight from the source code. Since source code is a string,
>>> it'll be constructed from that string, and it'll never go via float.
>>
>> Now that Python has a fast C implementation of Decimal, I would be
>> happy for Python 4000 to default to decimal floats, and require special
>> syntax for binary floats. Say, 0.1b if you want a binary float, and 0.1
>> for a decimal.
> 
> Maybe, but I believe the cdecimal module is still slower than typical
> floating point. 

Yes, cdecimal is about 10 times slower than binary floats.

But the point is, for most applications, that will be plenty fast enough. 
And for those where it isn't, there's always binary.


> There'd also be considerations regarding NumPy and how
> you'd go about working with an array of non-integer values, and so on.

I would expect that numpy 4000 would still use binary floats internally, 
and simply so a one-off conversion of decimals to floats when you 
initalise the array. Converting decimals to floats is no less accurate 
than converting base-ten strings to floats, so there's no loss there.

[...]
>> But for now, backwards-compatibility requires that the default floating
>> point type remains binary float. But we could maybe agitate for a
>> 1.234d Decimal literal type. Care to write a PEP?
>>
>> :-)
> 
> Heh. Strong consideration here: it would mean importing the decimal
> module on startup.
> 
>>>> t=time.time(); import decimal; time.time()-t
> 4.5000159740448
>>>> t=time.time(); import decimal; time.time()-t
> 0.0
> 
> A dummy import (when it's already loaded) is so fast that it's
> immeasurable, but four and a half seconds to load up decimal? This is
> 3.4.0b2 on Windows, btw. It was a lot quicker on my Linux box, probably
> because the OS or disk cache had the file. So maybe it wouldn't be too
> bad in practice; but it's still a cost to consider.

I would expect that by the time Python 4000 has a concrete 
implementation, that figure will be a lot lower. Either due to software 
optimisations, or just the general increase in speed in computer hardware.



>>> The question is how far Python wants to bless the Decimal type with
>>> syntax - after all, if Decimal can get a literal notation, why can't
>>> Fraction, and why can't all sorts of other types? And that's a huge
>>> can of worms.
>>
>> I like Fractions, but I don't think they're important enough for the
>> average users to require literal notation.
> 
> Yeah, but where do you draw the line? Either decimal.Decimal becomes a
> built-in type, 

That's where you draw the line. Binary floats for speed, decimals for 
compatibility with school arithmetic. (Well, mostly compatible.)


> or there needs to be a system for constructing literals
> of non-built-in types. And if Decimal becomes built-in, then why that
> and not <<insert type name here>>?

'Cos we have ten fingers and in count in decimal :-P


> Also, if Decimal becomes a built-in type, does that affect the numeric
> tower?

I don't see why whether the type is built-in or not should affect its 
position in the numeric tower. (I would expect that by the time Python 
4000 comes around, Decimal will be nicely integrated in the tower.)


-- 
Steven