prePEP: Decimal data type

[Emile van Sebille]

Batista, Facundo:
> Emile van Sebille wrote:
> #- Batista, Facundo:
> #- > 4. The Context must be omnipresent, meaning that changes
> #- to it affects all
> #- >    the current and future Decimal instances.
> #-
> #- Does this imply then that there is unlimited precision being
> #- maintained
> #- under the covers?
>
> No, why?
>
> Under the cover you got:
>
> - sign
> - coefficient (just several decimal digits, fixed in quantity)
> - exponent
>

So, say I calculate gross margin percentage as (S-C)/S and that yields a
repeating post-decimal result (say (7-5)/7 or 2/7) and I save this result as
a Decimal. How will the coefficient be set such that for future calculations
with arbitrary precision I'd get the right result?  This is what I
understood when you said that changes to Context would affect current and
future Decimal instances.

What I'm hoping will result from your work is a class/type that combines the
unbounded limits of longs with post decimal precision presentable to a
selectable number of post-decimal places.

Tim says it right on the pre-decimal point side:
> Unbounded precision ("to the left" of the radix point) is what my
> old FixedPoint.py class did/does:  if you multiply two FixedPoint
> integers, the result is exact, no matter how many decimal digits the
> exact product requires.

...and Bengt Richter on the post-decimal point side:
> Of course, you could use this stuff at very high precision,
> and then implement a class with Currency properties that
> would appear to enforce precision rounding only on
> assignment, and appear to evaluate rhs expressions with
> (for practical purposes) infinite precision. IMO that might
> be easier to think about. Right hand side expressions would
> seem continuously mathematically accurate, and assignments
> would choose the discrete quantized values.

This seems a very practical compromise.  ISTM that if your Decimal
guaranteed presentation accuracy out to 14 post-decimal positions by always
maintaining internal accuracy out to 20 (or pick other bounds you're
comfortable with), that we'd have something usable for monetary
applications.  The specifics of rounding rules and such come later.

The Context still needs to be defined, but Aahz says:
> Context applies only to operations, not to Decimal instances;
> changing the Context does not affect existing instances if
> there are no operations on them.

...from which I infer that Context exists in part to limit/round calculated
results.  Even if it were possible for me, as a user of Decimal, to set
Context appropriately to achieve these ends, what if I use a library that
also changes Context?  The integrity of my calculations may be impacted.

I'd prefer to have the results of calculations accurate to known bounds that
exceed presentation and legal requirements.  The rest is defined by the
specs of the job at hand.

Hoping you pull this off!

--

Emile van Sebille
emile at fenx.com