> Hmm, am I understanding you explaination? > > Here is a rational expression: > > 9/4 * 4/3 = 3 > > With floats this ends up being close, but with rounding errors. > > >>> 2.25*1.333333 > 2.9999992500000001 > >>> > > If this is expressed as a product of 2.25b * 1.333333d the result would be an > inexact value. A binary number would be returned, instead of the decimal > number 3. Correct. > Where is Tim's "numeric context" located? In his mind. :-) I believe it is typically global per thread, but that's up to the langage binding. A Java binding for Cowlishaw's decimals apparently requires passing in a context as a third argument on each operation. > 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. > NOTE: All ·minimally conforming· processors ·must· support decimal numbers > with a minimum of 18 decimal digits (i.e., with a ·totalDigits· of 18). > However, ·minimally conforming· processors ·may· set an application-defined > limit on the maximum number of decimal digits they are prepared to support, > in which case that application-defined maximum number ·must· be clearly > documented. > - http://www.w3.org/TR/xmlschema-2/#decimal I followed the URL and found only external representation issues, nothing that can help us. --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