[Python-ideas] Python Numbers as Human Concept Decimal System

[M.-A. Lemburg]

On 11.03.2014 12:46, Nick Coghlan wrote:
> ...[Oscar's proposal being that picking just one decimal floating
>     point precision as *the* floating point precision]...
>
> That approach buys us a couple of key benefits:
> 
> - they would be true constants, so constant folding, etc, would work
> normally, and you could tell from reading the code exactly what it
> will do, without needing to worry about the impact of thread local
> state
> - you could generally use the builtin decimal literals without
> learning anything about decimal contexts, because decimal literals
> wouldn't be context dependent (although their behaviour would be
> formally defined in terms of an IEEE decimal context, for most users
> it would just be "this is how Python decimal literals behave")
> 
> The guidance to new users would then be *don't* use the decimal
> module, use decimal literals instead. If you need more configurable
> behaviour, *then* reach for the decimal module. However, the explicit
> methods on decimal context objects should probably still be updated to
> accept both fixed and variable precision decimals under this model.

I think you are leaving out one of the most important use cases
for decimal values: data input and output.

The literals would only appear in programs. However, in most use
cases, you want to read decimal data from some source, process it
and then write it back again. This would most likely also require
using a few decimal literals, but the main source of decimals
would still be constructors that you choose when writing the
tools.

Coming back to floats and the decimal constructor:

In investment banking, for example, people usually work with floats
all the time. You only convert back to decimals at the very end of some
calculation. The reason here being either that the calculations
involve complex operations which are not available for decimals,
trying to keep error intervals small, or a combination of both.
In general, you try to use as much precision as you can afford
(in terms of memory and speed), to keep those error intervals
small.

In accounting, you often use decimals for storing data with
an (usually contractually or law based) agreed upon precision
and rounding logic. However, there situations where you have
to go to floats as well in order to run calculations, e.g.
for interest, taxes, etc.

In both situations, you want to have the decimal constructor
take the float values with full precision and only then apply
the necessary rounding to turn the value into a form which
complies with the agreed upon rules. It's also not uncommon to
add correctional bookings to address rounding issues explicitly
(e.g. when calculating VAT of a large number of individual
items).

In short: you try to prevent rounding from happening as
much as possible and when using it, you use it in a
controlled way.

Based on this, the choice to have the decimal constructor
use full precision when reading floats is a good one, even
though it may not feel right for the novice, the casual
decimal user or as human concept :-)

For decimal literals, I'd argue that if you enter a
value 1.2500d, you are expecting a decimal with 4 decimal
places precision, not 64 or 128 bits :-)

The information about the intended precision is implicit in the
literal. You see this done in exchange rates, stock prices,
prices at your grocery store, etc.

The decimals can then be transformed into ones with higher
precision during calculations and then possibly back to lower
precision, but this is an explicit decision by the system doing
the calculation.

Anyway, just throwing in some additional entropy into this
discussion. Probably not all that helpful, since you're already
converging on two possible solutions :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 11 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-04-09: PyCon 2014, Montreal, Canada ...               29 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/