PEP 327: Decimal Data Type

[Batista, Facundo]

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

[Aahz]

In article <40************ ***@easystreet. com>, <ac*****@easyst reet.com> 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 (aa**@pythoncra ft.com) <*> 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]

In article <6l************ *************** *****@4ax.com>,
Stephen Horne <st***@ninereed s.fsnet.co.uk> wrote:

On Fri, 30 Jan 2004 09:49:05 -0300, "Batista, Facundo"
<FB******@uniF ON.com.ar> 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 (aa**@pythoncra ft.com) <*> 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

[Stephen Horne]

On 5 Feb 2004 09:16:51 -0500, aa**@pythoncraf t.com (Aahz) wrote:

In article <6l************ *************** *****@4ax.com>,
Stephen Horne <st***@ninereed s.fsnet.co.uk> wrote:

On Fri, 30 Jan 2004 09:49:05 -0300, "Batista, Facundo"
<FB******@uni FON.com.ar> 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
presentatio n 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

[Bengt Richter]

On 5 Feb 2004 09:16:51 -0500, aa**@pythoncraf t.com (Aahz) wrote:

In article <6l************ *************** *****@4ax.com>,
Stephen Horne <st***@ninereed s.fsnet.co.uk> wrote:

On Fri, 30 Jan 2004 09:49:05 -0300, "Batista, Facundo"
<FB******@uni FON.com.ar> 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
presentatio n 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

Please clarify. What is your "n" in that?

Regards,
Bengt Richter

[Jeff Epler]

> On 5 Feb 2004 09:16:51 -0500, aa**@pythoncraf t.com (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: Please clarify. What is your "n" in that?

"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