RE: precision on op:numeric-divide

Damien, Per, et al,

This is a *personal* response, and not an official one.

The IEEE is responsible for an "old" standard known as IEEE 754, which 
specifies the semantics of floating point numbers and operations.  It is 
also responsible for a newer standard that some expect will replace (in 
practice) IEEE 754, called IEEE 854.  IEEE 854 adds other numeric 
facilities (notably decimal numbers) to the types specified in IEEE 754.

The  Query WG is currently investigating whether, and how, we can take 
advantage of the specifications in IEEE 854.  As you may appreciate, we do 
not want to leap into those waters without at least asking for and 
considering the XML Schema WG's thoughts on the matter.

I am unwilling to promise that any consideration of IEEE 854 will resolve 
these excellent questions about the semantics of divisions that return 
xs:decimal values, but I suspect that --- should it come to fruition --- it 
will have significant influence.

However, as far as supporting exact representation of arbitrary rational 
numbers, such as the result of dividing 1 by 3, I do not believe that there 
is any possibility that XQuery 1.0 or XPath 2.0 will support 
that.  (Frankly, I doubt that it will ever be supported in these languages, 
but I do not claim to see the future perfectly!)  There is, of course, one 
way to represent such numbers exactly, without resorting to tricks like 
pseudo-infinite precision notations: retain the numerator and denominator 
themselves, thus effectively holding "1/3" exactly.  I know of a couple of 
(very old, research) languages that do this, but they are rather 
complicated and cumbersome.

Hope this helps,
    Jim

At 20:31 2003-12-09 Tuesday, Damien Fisher wrote:

>But shouldn't the specification make it clear what the intended semantics
>are?
>
>How are people supposed to write implementation-independent queries if the
>minimum level of precision isn't guaranteed?  xs:double follows the IEEE
>standard, and hence, if someone needs to, they can make sure their code
>works on many different platforms easily.  I don't  see how this is possible
>with the xs:decimal functions (as they are currently defined).
>
>Finally, exact rationals, while perhaps desirable in some cases, can lead to
>an explosion in memory usage if not controlled carefully, since there is no
>upper bound on the precision used in the calculations.  A simple example:
>compute (1/2)^n, for some very large n.
>
>-----Original Message-----
>From: Per Bothner [mailto:per@bothner.com]
>Sent: Wednesday, 10 December 2003 2:21 PM
>To: Damien Fisher
>Cc: www-ql@w3.org
>Subject: Re: precision on op:numeric-divide
>
>Damien Fisher wrote:
> > And should rational answers always be returned exactly, even
> > if that requires an enormous amount of precision?
>
>Many language implementations (including any for full Common Lisp)
>do support exact rationals, and people seem to like that.  (They also
>support floating-point.)
>
>In the Lisp family, exact rationals are usually implemented and
>printed as simplified fractions; but using repeating decimals might
>be more useful.  E.g. op:numeric-divide(5, 3) could return a
>decimal whose literal form might be "1._6_" where digits between
>_ and _ are infinitely repeating.
>--
>         --Per Bothner
>per@bothner.com   http://per.bothner.com/

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
Oracle Corporation            Oracle Email: mailto:jim.melton@oracle.com
1930 Viscounti Drive          Standards email: mailto:jim.melton@acm.org
Sandy, UT 84093-1063              Personal email: mailto:jim@melton.name
USA                                                Fax : +1.801.942.3345
========================================================================
=  Facts are facts.  However, any opinions expressed are the opinions  =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
========================================================================

Received on Wednesday, 10 December 2003 11:05:43 UTC