prePEP: Decimal data type

Mel Wilson mwilson at the-wire.com
Sat Nov 8 10:11:31 EST 2003


In article <vqgapfommnh7db at news.supernews.com>,
"John Roth" <newsgroups at jhrothjr.com> wrote:
>My personal opinion in the matter is that setting the precision high
>enough so that you won't get into trouble is a hack, and it's a dangerous
>hack because the amount of precision needed isn't directly related to the
>data you're processing; it's something that came out of an analysis,
>probably by someone else under some other circumstances. Given
>a software implementation, there's a performance advantage to setting it as
>low
>as possible, which immediately puts things at risk if your data
>changes.

   It puzzles me.  In the COBOL days, we used to worry over
setting the sizes of our data fields large enough.  We'd set
a size we thought was ridiculously large and then worry
whether today would be the day that the company would do the
unprecedented amount of business that would blow up the
night-shift batch runs.  We escaped from that with Python's
long ints and now we're trying to invent it again.

>Fixed precision is also counter to the infinite precision we're moving
>toward with the integers; and integers are a more comfortable metaphor
>for money than floats.

>The natural implementation for fixed decimal is much simpler
>than for floating decimal. And I frankly don't think that floating
>decimal is going to get that much use outside of an accounting
>context, given that I think it's going to be a *lot* slower than
>built-in binary floating point. Especially if PyPy succeeds in
>their dream of creating a JIT for Python.

   Float decimal can nice for intermediate results because
you don't have to worry about precision limits until you
reach a point where you have a specific need for a specific
precision.  Software speed won't beat hardware speed, but a
float multiply can still be just

        return self.__class__ (self._v*other._v, self._e+other._e)

multiplying two longs and adding two ints.

Add is tougher

        v, vo, e = self._match_exp (self, other)
        return self.__class__ (v+vo, e)
...
    def _match_exp (self, other):
        v, e = self._v, self._e
        vo, eo = other._v, other._e
        de = e - eo
        if de > 0:
            v *= pow (10, de)
        elif de < 0:
            vo *= pow (10, -de)
        return v, vo, min (e, eo)


   With COBOL we had powerful declarations in the data
division and we could fully control the precision of every
intermediate result in a calculation; of course the
one-verb-per-line form also encouraged this.  In
ALGOL-flavoured languages the expression-oriented statements
make this less natural.  And Python with no variable
declarations makes this hardest of all.


    Regards.    Mel.




More information about the Python-list mailing list