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/)