PEP 327: Decimal Data Type

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

  1. 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
    #1
    1. Advertising

  2. 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
    #2
    1. Advertising

  3. 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
    #3
  4. Batista, Facundo

    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
    #4
  5. > 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
    #5
  6. Batista, Facundo

    Aahz Guest

    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
    #6
  7. Batista, Facundo

    Aahz Guest

    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
    #7
  8. 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
    #8
  9. 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

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

    Regards,
    Bengt Richter
     
    Bengt Richter, Feb 6, 2004
    #9
  10. Batista, Facundo

    Jeff Epler Guest

    > 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:
    > 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
     
    Jeff Epler, Feb 6, 2004
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christoph Becker-Freyseng

    PEP for new modules (I read PEP 2)

    Christoph Becker-Freyseng, Jan 15, 2004, in forum: Python
    Replies:
    3
    Views:
    381
    Gerrit Holl
    Jan 16, 2004
  2. Batista, Facundo

    RE: PEP 327: Decimal Data Type

    Batista, Facundo, Jan 30, 2004, in forum: Python
    Replies:
    15
    Views:
    506
  3. Batista, Facundo

    RE: PEP 327: Decimal Data Type

    Batista, Facundo, Feb 2, 2004, in forum: Python
    Replies:
    5
    Views:
    358
    Bengt Richter
    Feb 6, 2004
  4. Batista, Facundo

    RE: PEP 327: Decimal Data Type

    Batista, Facundo, Feb 3, 2004, in forum: Python
    Replies:
    5
    Views:
    358
    Bengt Richter
    Feb 9, 2004
  5. Gilbert Fine
    Replies:
    8
    Views:
    918
    Zentrader
    Aug 1, 2007
Loading...

Share This Page