[Bug 2675] XPath fails to evaluate the sum of a number of different xpath expressions where each xpath expr evaluates to a large double value

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2675


jim.melton@acm.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Additional Comments From jim.melton@acm.org  2006-01-06 18:53 -------
Nina, thanks for your report. 

However, I don't understand why you believe that this is a failure of the XPath
specification or the Functions & Operators specification.  Let me address your
report in two parts.  

First, you said "XPath fails to evaluate the sum of 'n' different xpath
expressions where each xpath expression evaluates to a large double value (where
n > 1)."  When I read that sentence, it sounded like you were saying that no sum
was computed at all -- in other words, that XPath (or the implementation you're
using) doesn't have the addition operator.  That is obviously not the case. 

Secondly, the use of the term "large double value" is misleading, because values
of a thousand, or a million, or even a billion, are not "large" in the value
space of [xs:]double. 

The final part of your report says that the expression "(/A/B/@ONE + /A/B/@TWO +
/A/B/@THREE) = /A/B/@TOTAL" evaluates to false, even though the value you coded
for the TOTAL attribute is obviously the sum of the values of the attributes
ONE, TWO, and THREE.  But there is a very subtle fallacy in that argument. 

As you observed in the first paragraph of your report, the values of all four of
those attributes are cast to values of type xs:double (or, if you're talking
about XPath 1.0, values of type double).  There are a great many decimal values
with a non-zero fractional component that literally do not have an exact
representation in the [xs:]double type.  The reason is that the [xs:]double type
is a floating *binary* type of limited (that is, not infinite) maximum precision. 

Every one of the values of attributes ONE, TWO, THREE, and TOTAL have a
fractional component.  Therefore, it is almost certainly the case that the
values of at least one of those attributes does not have an exact representation
in [xs:]double, which would make the sum of ONE, TWO, and THREE different in at
least the lowest-order bit from the value of TOTAL.  (Caveat: I have not
specifically determined the exact binary representation of the [xs:]double
values involved, but I'm still quite confident of my statement.)

This is an extremely well-known problem in numerical computing, going back to at
least the 1950s. 

By way of demonstrating this, let's try the same expression, but multiply each
of the attribute values by one thousand (1,000) to eliminate the fractional
components.  The new document would be:
<A>
<B ONE="7824581" TWO="522260"  THREE="1258110" TOTAL="9604951"/>
</A>

Now, when I run your XPath expression ((/A/B/@ONE + /A/B/@TWO + /A/B/@THREE) =
/A/B/@TOTAL), the answer that I get from the XPath processor I used to test this
(in Stylus Studio) returns "true"!  Try the same experiment on your processor
and let us know whether it returns "true" or "false". 

In the meanwhile, I am marking this this bug Resolved as INVALID. 

If you disagree with this resolution, you may re-open the bug and enter
additional comments, evidence, etc. 

Again, thank you for your report.

Received on Friday, 6 January 2006 18:53:10 UTC