Velocity Reviews > RE: prePEP: Decimal data type

# RE: prePEP: Decimal data type

Batista, Facundo
Guest
Posts: n/a

 11-04-2003
Emile van Sebille wrote:

#- > 3. To exist a Context. The context represents the user-selectable
#- > parameters
#- > and rules which govern the results of arithmetic
#- operations. In the
#- > context the user defines:
#- >
#- > - what will happen with the exceptional conditions.
#- > - what precision will be used
#- > - what rounding method will be used
#- >
#- > 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

.. Facundo

Emile van Sebille
Guest
Posts: n/a

 11-05-2003
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
http://www.velocityreviews.com/forums/(E-Mail Removed)

Aahz
Guest
Posts: n/a

 11-05-2003
In article <bob8a4\$1bmvct\$(E-Mail Removed)-berlin.de>,
Emile van Sebille <(E-Mail Removed)> wrote:
>
>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.

That's correct. There needs to be a social convention that libraries
intended for use by other people *CANNOT* muck with Context, and if they
do so for their own internal calculations, they must save and restore
Cowlishaw.
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

Jp Calderone
Guest
Posts: n/a

 11-05-2003
On Wed, Nov 05, 2003 at 01:55:09PM -0500, Aahz wrote:
> In article <bob8a4\$1bmvct\$(E-Mail Removed)-berlin.de>,
> Emile van Sebille <(E-Mail Removed)> wrote:
> >
> >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.

>
> That's correct. There needs to be a social convention that libraries
> intended for use by other people *CANNOT* muck with Context, and if they
> do so for their own internal calculations, they must save and restore
> Cowlishaw.

Enter the context stack.

Jp

Aahz
Guest
Posts: n/a

 11-06-2003
In article <(E-Mail Removed)>,
Jp Calderone <(E-Mail Removed)> wrote:
>On Wed, Nov 05, 2003 at 01:55:09PM -0500, Aahz wrote:
>> In article <bob8a4\$1bmvct\$(E-Mail Removed)-berlin.de>,
>> Emile van Sebille <(E-Mail Removed)> wrote:
>>>
>>>...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.

>>
>> That's correct. There needs to be a social convention that libraries
>> intended for use by other people *CANNOT* muck with Context, and if they
>> do so for their own internal calculations, they must save and restore
>> Cowlishaw.

>
> Enter the context stack.

Well, sure. And it won't be hard to add given that Decimal will already
need to track thread-specific Context. But modules changing Context
will still need to explicitly push and pop Context because usually you
will just want to replace the current Context.
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan