[Python-ideas] Python Float Update

Andrew Barnert abarnert at yahoo.com
Tue Jun 2 00:15:16 CEST 2015

On Jun 1, 2015, at 10:24, Nicholas Chammas <nicholas.chammas at gmail.com> wrote:
> Well, I learned a lot about decimals today. :)
> On Mon, Jun 1, 2015 at 3:08 AM, Nick Coghlan ncoghlan at gmail.com wrote:
> In a world of binary computers, no programming language is free of
> those constraints - if you choose decimal literals as your default,
> you take a big performance hit, because computers are designed as
> binary systems. (Some languages, like IBM’s REXX, do choose to use
> decimal integers by default)
> I guess it’s a non-trivial tradeoff. But I would lean towards considering people likely to be affected by the performance hit as doing something “not common”. Like, if they are doing that many calculations that it matters, perhaps it makes sense to ask them to explicitly ask for floats vs. decimals, in exchange for giving the majority who wouldn’t notice a performance difference a better user experience.
> On Mon, Jun 1, 2015 at 10:58 AM, Steven D’Aprano steve at pearwood.info wrote:
> I wish this myth about Decimals would die, because it isn’t true.
> Your email had a lot of interesting information about decimals that would make a good blog post, actually. Writing one up will perhaps help kill this myth in the long run :)
> In the past, I’ve found that people are very resistant to this fact, so
> I’m going to show a few examples of how Decimals violate the fundamental
> laws of mathematics just as floats do.
> How many of your examples are inherent limitations of decimals vs. problems that can be improved upon?
> Admittedly, the only place where I’ve played with decimals extensively is on Microsoft’s SQL Server (where they are the default literal). I’ve stumbled in the past on my own decimal gotchas, but looking at your examples and trying them on SQL Server I suspect that most of the problems you show are problems of precision and scale.
> Perhaps Python needs better rules for how precision and scale are affected by calculations (here are SQL Server’s, for example), or better defaults when they are not specified?
> Anyway, here’s what happens on SQL Server for some of the examples you provided.
> Adding 100:
> py> from decimal import Decimal as D
> py> x = D(10)**30
> py> x == x + 100 # should be False
> True
> DECLARE @x DECIMAL(38,0) = '1' + REPLICATE(0, 30);
> IF @x = @x + 100
>   SELECT 'equal' AS adding_100
>   SELECT 'not equal' AS adding_100
> Gives “not equal”. Leaving out the precision when declaring @x (i.e. going with the default precision of 18) immediately yields an understandable data truncation error.
Obviously if you know the maximum precision needed before you start and explicitly set it to something big enough (or 7 places bigger than needed) you won't have any problem. Steven chose a low precision just to make the problems easy to see and understand; he could just as easily have constructed examples for a precision of 18.

Unfortunately, even in cases where it is both possible and sufficiently efficient to work out and set the precision high enough to make all of your calculations exact, that's not something most people know how to do reliably. In the fully general case, it's as hard as calculating error propagation.

As for the error: Python's decimal flags that too; the difference is that the flag is ignored by default. You can change it to warn or error instead. Maybe the solution is to make that easier--possibly just changing the docs. If you read the whole thing you will eventually learn that the default context ignores most such errors, but a one-liner gets you a different context that acts like SQL Server, but who reads the whole module docs (especially when they already believe they understand how decimal arithmetic works)? Maybe moving that up near the top would be useful?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150601/b25f7a0b/attachment-0001.html>

More information about the Python-ideas mailing list