> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4