[Python-ideas] Python Float Update

[Nick Coghlan]

On 2 June 2015 at 19:38, Alexander Walters <tritium-list at sdamon.com> wrote:
> I think there is another discussion to have here, and that is making Decimal
> part of the language (__builtin(s)__) vs. part of the library (which
> implementations can freely omit).  If it were part of the language, then
> maybe, just maybe, a literal syntax should be considered.

For decimal, the issues that keep it from becoming a literal are
similar to those that keep it from becoming a builtin: configurable
contexts are a core part of the decimal module's capabilities, and
making a builtin type context dependent causes various problems when
it comes to reasoning about a piece of code based on purely local
information. Those problems affect human readers regardless, but once
literals enter the mix, they affect all compile time processing as
well.

On that front, I also finally found the (mammoth) thread from last
year about the idea of using base 10 for floating point values by
default: https://mail.python.org/pipermail/python-ideas/2014-March/026436.html

One of the things we eventually realised in that thread is that the
context dependence problem, while concerning for a builtin type, is an
absolute deal breaker for literals, because it means you *can't
constant fold them* by calculating the results of expressions at
compile time and store the result directly into the code object
(https://mail.python.org/pipermail/python-ideas/2014-March/026998.html).

This problem is illustrated by asking the following question: What is
the result of "Decimal('1.0') + Decimal('1e70')"?

Correct answer? Insufficient data (since we don't know the current
decimal precision).

With the current decimal module, the configurable rounding behaviour
is something you just need to learn about as part of adopting the
module. Since that configurability is one of the main reasons for
using it over binary floating point, that's generally not a big deal.

It becomes a much bigger deal when the question being asked is: What
is the result of "1.0d + 1e70d"?

Those look like they should be numeric constants, and hence the
compiler should be able to constant fold them at compile time. That's
possible if we were to pick a single IEEE decimal type as a builtin
(either decimal64 or decimal128), but not possible if we tried to use
the current variable precision decimal type.

One of the other "fun" discrepancies introduced by the context
sensitive processing in decimals is that unary plus and minus are
context-sensitive, which means that any literal format can't express
arbitrary negative decimal values without a parser hack to treat the
minus sign as part of the trailing literal. This is one of the other
main reasons why decimal64 or decimal128 are better candidates for a
builtin decimal type than decimal.Decimal as it exists today (as well
as being potentially more amenable to hardware acceleration on some
platforms).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia