PEP 327: Decimal Data Type

B

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
 
S

Stephen Horne

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.
 
C

Christopher Koppler

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

[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,
 
A

achrist

Stephen said:
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
 
J

Josiah Carlson

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
 
A

Aahz

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 ([email protected]) <*> 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
 
A

Aahz

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 ([email protected]) <*> 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
 
S

Stephen Horne

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.
 
B

Bengt Richter

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
 
J

Jeff Epler

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top