RE: prePEP: Decimal data type

Discussion in 'Python' started by Batista, Facundo, Nov 4, 2003.

  1. 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
     
    Batista, Facundo, Nov 4, 2003
    #1
    1. Advertising

  2. 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 van Sebille, Nov 5, 2003
    #2
    1. Advertising

  3. Batista, Facundo

    Aahz Guest

    In article <bob8a4$1bmvct$-berlin.de>,
    Emile van Sebille <> 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
    Context. You can probably find additional information about this in
    Cowlishaw.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "It is easier to optimize correct code than to correct optimized code."
    --Bill Harlan
     
    Aahz, Nov 5, 2003
    #3
  4. Batista, Facundo

    Jp Calderone Guest

    On Wed, Nov 05, 2003 at 01:55:09PM -0500, Aahz wrote:
    > In article <bob8a4$1bmvct$-berlin.de>,
    > Emile van Sebille <> 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
    > Context. You can probably find additional information about this in
    > Cowlishaw.


    Enter the context stack.

    Jp
     
    Jp Calderone, Nov 5, 2003
    #4
  5. Batista, Facundo

    Aahz Guest

    In article <>,
    Jp Calderone <> wrote:
    >On Wed, Nov 05, 2003 at 01:55:09PM -0500, Aahz wrote:
    >> In article <bob8a4$1bmvct$-berlin.de>,
    >> Emile van Sebille <> 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
    >> Context. You can probably find additional information about this in
    >> 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 () <*> http://www.pythoncraft.com/

    "It is easier to optimize correct code than to correct optimized code."
    --Bill Harlan
     
    Aahz, Nov 6, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Batista, Facundo

    prePEP: Decimal data type

    Batista, Facundo, Oct 31, 2003, in forum: Python
    Replies:
    21
    Views:
    626
  2. Batista, Facundo

    RE: prePEP: Decimal data type

    Batista, Facundo, Nov 4, 2003, in forum: Python
    Replies:
    1
    Views:
    354
    Bengt Richter
    Nov 5, 2003
  3. Batista, Facundo

    RE: prePEP: Decimal data type

    Batista, Facundo, Nov 4, 2003, in forum: Python
    Replies:
    3
    Views:
    289
    Bengt Richter
    Nov 9, 2003
  4. Tim Peters

    RE: prePEP: Decimal data type

    Tim Peters, Nov 5, 2003, in forum: Python
    Replies:
    5
    Views:
    466
    Ron Adam
    Nov 8, 2003
  5. Tim Peters

    RE: prePEP: Decimal data type

    Tim Peters, Nov 6, 2003, in forum: Python
    Replies:
    6
    Views:
    337
Loading...

Share This Page