[Python-ideas] Python3.3 Decimal Library Released

[David Mertz]

Taking a look at the documentation for cdecimal itself (now part of Python
3.3) at http://www.bytereef.org/mpdecimal/benchmarks.html, it looks like
for basic add/mul operations that don't exceed the precision of floating
point, FP is more than twice as fast as optimized decimals.  Of course,
where the precision needed is more than FP handles at all, it's simply a
choice between calculating a quantity and not doing so.

This suggests to me a rather strong argument against making decimals the
*default* numeric datatype.  However, it *does* still remain overly
cumbersome to create decimals, and a literal notation for them would be
very welcomed.

It is far from clear to me that decimals are generically the *right* answer
to rounding issues (i.e. even if we don't care about the benchmark
question).  Yes, it's easier for humans who use base 10 to understand
numeric results when using them.  But the hardware on CPUs is oriented
around binary floating point representations, and pretty much every other
programming language uses BFP.  It's a nice property to have 'a+b' in
Python produce the same answer as 'a+b' in C, Ruby, Perl, Mathematica,
Haskell, Java, etc.--I'm not saying that's the only nice property one might
want, but it is one of them since data is exchanged between tools and
libraries written in different languages (or even, e.g. Python often uses
libraries written in C).

I do recognize that in Python 4000, we *could* have default literals be
decimal, and require some other literal notation for binary floating point,
and that *would* be available for calculations meant to be compatible with
outside tools.  However, I haven't seen a case presented for why decimals
are generically better as a default.

Of possible note, I happen to work in a research lab where we worry a lot
about bitwise identity of calculations, not merely about numeric stability.
 I know that is a somewhat unusual requirement, even within scientific
computing.  But it is one that exists, and it makes me think of (bitwise)
compatibility with calculations in other programming languages.



On Mon, Mar 3, 2014 at 12:12 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 3 March 2014 18:23, Zachary Ware <zachary.ware+pyideas at gmail.com>
> wrote:
> > I'm -1 on a decimal-specific math library, though.  What I would
> > rather see is a type-agnostic math library, that does what (IIRC) the
> > new statistics module does: take in numbers of any type, coerce only
> > as is strictly necessary, calculate, and return an answer of the same
> > type as the input with the goal of correctness over performance.
>
> Given that incorrect results aren't acceptable in any situation, fair
> enough, but what I'd like to see would be library functions that
> provided good performance for decimal first. If they can do so while
> remaining type-agnostic, then fine, but I'd favour decimal performance
> over the ability to calculate the sine of a rational... Ultimately,
> I'd like to feel that I pay a one-off cost for working with decimals
> (the cost of a software implementation rather than a hardware one) but
> I *don't* have to pay further because the algorithms used for decimals
> are suboptimal compared to the floating point ones. I'd say the same
> about rationals, but the set of functions involved is different (and
> basically wouldn't involve most of what's in the normal math library)
>
> Having said this, I can't actually think of a real-life domain where
> math-library functions (by which I assume we basically mean
> trancendental functions?) would be used and yet there would be a
> genuine need for decimal arithmetic rather than floating point. So
> although I'm +1 for a decimal math library in theory, I'm unsure of
> its practical value.
>
> Paul
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140303/8722d467/attachment.html>