[Python-Dev] Revised decimal type PEP

[Guido van Rossum]

> I'm trying to understand how a decimal number context would work.  Is the 
> context a variable and/or flag that defines the rounding rules and precision 
> of a number when it is used in a calculation?

Yes -- I believe advanced HP calculators have such functionality.  So
does IEEE 754 for binary floating point.

> How is it associated with a 
> number or a calculation?

As I wrote, this depends on the language binding.  I believe it's
associated with a calculation, not with a number.

> The "global per thread" description seems to 
> associate the context with threads.  Can the context be altered inside the 
> thread?  Is it possible to change the context at different levels in a 
> stackframe? 

Again, this would depend on the language.  I believe typically you can
change it but it's not stacked (you'd have to do that yourself).

> I would assume there is a default context will be used until the context is 
> changed.  If this is the case I would expect a default context would be 
> defined at startup.

Me too.

> Would it make sense to have a simple decimal type with no features that can 
> be modified (a fixed context)?

That's like providing IEEE 754 floating point without the controls.
That's what C does, but at times it's painful.  For MOST users this
would be fine, but for advanced use you need the control, and claiming
"IEEE 754 std" is unfair without the controls.

> This simple type could be extended by deriving 
> a new numerical type from the base decimal type.  This base decimal type 
> would be targeted at the newbie user.  It would have no surprises.

It's hard to avoid surprises of the kind (1/3)*3 != 1.  My calculator
gives 0.99999999, but it's still a surprise.  On the other hand for
someone who thinks they know how a calculator does it, returning 1
would be the surprise!

What kind of surprises do you specifically want to avoid?

> It would 
> have a default precision of 18 and the rules for rounding would emulate the 
> typical hand held calculator. Accountants who need special rounding rules 
> would use a derived type that allowed the default rules to be overridden.
> 
> It would be possible to round numbers of the simple based type, but it would 
> be an explicit step to remove insignificant digits.  An accounting decimal 
> type might automatically round calculations to the smallest denomination.  
> For instance, an accounting context might have automatically managed the 
> final rounding in the following calculation:
> 
> p>>> quantity = 6
> >>> tax = .06
> >>> price = 2.99
> >>> total = price * quantity * (1 + tax)
> >>> total
> 19.0164
> >>> round(total,2)
> 19.02
> >>>

Looks good to me.  This would be a nice goal to strive for.

> > > M.-A. Lemburg" suggested looking at the SQL specification for
> > > Decimal datatypes.  A decimal type is also defined as a type in
> > > XML Schema.  Since this is an XML datatype there isn't a
> > > definition for how these numbers are created.
> >
> > Do these say anything about semantics under numeric operations?
> > That would seem to be outside the realm of XML and possibly even
> > outside SQL.  So I'm not sure how these help.
> 
> You are correct that it doesn't deal with numeric operations.  It
> does define a minimum precision requirement.  I am only referencing
> it here because it is another instance where having a decimal type
> in Python would be useful and because they have set a minimum
> requirement.  Setting this minmum as a default behavior would
> probably make newbies comfortable with the language.

Good point.

--Guido van Rossum (home page: http://www.python.org/~guido/)