# PEP 327: Decimal Data Type

Discussion in 'Python' started by Batista, Facundo, Jan 30, 2004.

1. ### Batista, FacundoGuest

I'm proud to announce that the PEP for Decimal Data Type is now published
under the python.org structure:

http://www.python.org/peps/pep-0327.html

This wouldn't has been possible without the help from Alex Martelli, Aahz,
Tim Peters, David Goodger and c.l.p itself.

After the pre-PEP roundups the features are almost established. There is not
agreement yet on how to create a Decimal from a float, in both explicit and
implicit constructions.

I depend on settle that to finish the test cases and actually start to work
on the code.

I'll apreciate any feedback. Thank you all in advance.

.. Facundo

Batista, Facundo, Jan 30, 2004

2. ### Stephen HorneGuest

On Fri, 30 Jan 2004 09:49:05 -0300, "Batista, Facundo"
<> wrote:

>I'll apreciate any feedback. Thank you all in advance.

My concern is that many people will use a decimal type just because it
is there, without any consideration of whether they actually need it.

95% of the time or more, all you need to do to represent money is to
use an integer and select appropriate units (pence rather than pounds,
cents rather than dollars, etc) so that the decimal point is just a
presentation issue when the value is printed/displayed but is never
needed in the internal representation.

That said, there are cases where a decimal type would be genuinely
useful. Given that, my only comment on the PEP is that a decimal
literal might be a good idea - identical to float literals but with a
'D' appended, for instance.

I wouldn't mention it now, seeing it as an issue for after the library
itself has matured and been proven, except for the issue of implicit
conversions. Having a decimal literal would add another class of
errors with implicit conversions - it would be very easy to forget the
'D' on the end of a literal, and to get an imprecise float implicitly
converted to decimal rather than the precise decimal literal that was
intended.

I don't know what the solution should be, but I do think it needs to
be considered.

--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

Stephen Horne, Jan 30, 2004

3. ### Christopher KopplerGuest

On Fri, 30 Jan 2004 16:03:55 +0000, Stephen Horne
<> wrote:

[snip]
>
>That said, there are cases where a decimal type would be genuinely
>useful. Given that, my only comment on the PEP is that a decimal
>literal might be a good idea - identical to float literals but with a
>'D' appended, for instance.

Or, maybe if money is being represented, appending a '\$'?

*ducks*

Just-couldn't-resist-ly yours,

--
Christopher

Christopher Koppler, Jan 30, 2004
4. ### Guest

Stephen Horne wrote:
>
> I don't know what the solution should be, but I do think it needs to
> be considered.
>

The C and C++ people have agreed. The next standards for those
languages, whenever they come out, are supposed to include decimal
floating point as a standard data type. The number of decimal
places required is also profuse, something up around 25-30 places,
more than current hardware, eg IBM mainframes, supports.

If python adds decimal data, it probably ought to be consistent with C
and C++. Otherwise, the C and C++ guys will have a dreadful time
writing emulation code to run on computers built to support python.

Al

, Jan 31, 2004
5. ### Josiah CarlsonGuest

> If python adds decimal data, it probably ought to be consistent with C
> and C++. Otherwise, the C and C++ guys will have a dreadful time
> writing emulation code to run on computers built to support python.

Now that's a "Python will take over the world" statement if I ever heard
one. But seriously, processor manufacturers build processors and
compilers for Fortran, C, and C++. If a manufacturer starts paying
attention to where Python is going (for things other than scripting
their build-process), I'm sure Guido would like to know.

- Josiah

Josiah Carlson, Jan 31, 2004
6. ### AahzGuest

In article <>, <> wrote:
>
>If python adds decimal data, it probably ought to be consistent with C
>and C++. Otherwise, the C and C++ guys will have a dreadful time
>writing emulation code to run on computers built to support python.

Read the PEP; Python's proposed decimal type is based on the existing
decimal standard. If C/C++ *don't* follow the standard, that's their
problem. BTW, Java uses the standard.
--
Aahz () <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

Aahz, Feb 5, 2004
7. ### AahzGuest

In article <>,
Stephen Horne <> wrote:
>On Fri, 30 Jan 2004 09:49:05 -0300, "Batista, Facundo"
><> wrote:
>>
>>I'll apreciate any feedback. Thank you all in advance.

>
>My concern is that many people will use a decimal type just because it
>is there, without any consideration of whether they actually need it.
>
>95% of the time or more, all you need to do to represent money is to
>use an integer and select appropriate units (pence rather than pounds,
>cents rather than dollars, etc) so that the decimal point is just a
>presentation issue when the value is printed/displayed but is never
>needed in the internal representation.

The problem lies precisely in that representation. For starters, a
binary integer is O(n^2) for conversion to decimal printing. Then
there's the question about multi-currency conversions, or interest
rates, or ....
--
Aahz () <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

Aahz, Feb 5, 2004
8. ### Stephen HorneGuest

On 5 Feb 2004 09:16:51 -0500, (Aahz) wrote:

>In article <>,
>Stephen Horne <> wrote:
>>On Fri, 30 Jan 2004 09:49:05 -0300, "Batista, Facundo"
>><> wrote:
>>>
>>>I'll apreciate any feedback. Thank you all in advance.

>>
>>My concern is that many people will use a decimal type just because it
>>is there, without any consideration of whether they actually need it.
>>
>>95% of the time or more, all you need to do to represent money is to
>>use an integer and select appropriate units (pence rather than pounds,
>>cents rather than dollars, etc) so that the decimal point is just a
>>presentation issue when the value is printed/displayed but is never
>>needed in the internal representation.

>
>The problem lies precisely in that representation. For starters, a
>binary integer is O(n^2) for conversion to decimal printing.

In practice, there is an upper limit to the size of number that occurs
in any financial use, and of course we are not talking about tens of
digits let alone hundreds, meaning that the conversion is most
sensibly treated as O(1) for each number converted.

Anyway, speeding up the presentation of results makes little sense if
you slow down all the arithmetic operations to do it.

> Then
>there's the question about multi-currency conversions, or interest
>rates, or ....

Admittedly needing better than penny precision, but still fixed
precision (ie suiting an integer representation with an implicit scale
factor) and the results are rounded.

I work with a company that writes accounting software. We don't need
to worry about currency conversions, but we do need to worry about
interest and other cases where fractional pennies seem to be implied
(rates for taxes, allowances etc) and basically the fractional pennies
are never really an issue - you do have to be careful with the
rounding rules, but that applies whatever representation you use.

--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

Stephen Horne, Feb 6, 2004
9. ### Bengt RichterGuest

On 5 Feb 2004 09:16:51 -0500, (Aahz) wrote:

>In article <>,
>Stephen Horne <> wrote:
>>On Fri, 30 Jan 2004 09:49:05 -0300, "Batista, Facundo"
>><> wrote:
>>>
>>>I'll apreciate any feedback. Thank you all in advance.

>>
>>My concern is that many people will use a decimal type just because it
>>is there, without any consideration of whether they actually need it.
>>
>>95% of the time or more, all you need to do to represent money is to
>>use an integer and select appropriate units (pence rather than pounds,
>>cents rather than dollars, etc) so that the decimal point is just a
>>presentation issue when the value is printed/displayed but is never
>>needed in the internal representation.

>
>The problem lies precisely in that representation. For starters, a
>binary integer is O(n^2) for conversion to decimal printing. Then

Regards,
Bengt Richter

Bengt Richter, Feb 6, 2004
10. ### Jeff EplerGuest

> On 5 Feb 2004 09:16:51 -0500, (Aahz) wrote:
> >The problem lies precisely in that representation. For starters, a
> >binary integer is O(n^2) for conversion to decimal printing. Then

On Fri, Feb 06, 2004 at 06:56:03PM +0000, Bengt Richter wrote:

"n" is the number of digits in the number, in this case.

A standard way to convert to base 10 looks like this:
def base10(i):
digits = []
while i:
i, b = divmod(i, 10)
digits.append(b)
digits.reverse()
return digits
Each divmod() takes from O(n) down to O(1) (O(log i) for each successive
value of i), and the loop runs n times (i is shortened by one digit each
time). This is a typical n^2 algorithm, much like bubble sort where the
outer loop runs n times and an inner loop runs 1-to-n times.

Jeff

Jeff Epler, Feb 6, 2004