This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2631 - [XPath] Numeric Promotion
Summary: [XPath] Numeric Promotion
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://lists.w3.org/Archives/Member/w...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-03 14:49 UTC by Michael Kay
Modified: 2006-02-14 01:22 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2006-01-03 14:49:40 UTC
This issue was raised on an internal email and is being copied here as a result
of action A-278-02. The issue reads:

In the Query test suite, test fn-distinct-values-mixed-args-012.xq is:

fn:distinct-values((xs:decimal('1.2'), xs:float('1.2')))

and the expected answer is "1.2".

This answer is valid if (xs:decimal('1.2') eq xs:float('1.2')).

But I'm having trouble deciding from the spec whether these two values are
equal. It hinges on the way promotion works.

If the decimal is promoted to a float, then the two values are equal.

If both values are promoted to doubles, then they are not equal. This is
because the float converts to the double 1.2000000476837158.

I don't think there is anything in the spec that tells us which way
promotion is supposed to work for a value comparison. It's interesting that
it makes such a dramatic difference to the result of a simple expression
like this. I suspect it's intended that the decimal should be promoted to a
float, making these test results correct (and Saxon wrong), but the spec
doesn't currently say so.


Michael Kay
Comment 1 Michael Kay 2006-01-03 15:15:42 UTC
Proposal to resolve issue 2631: under action A-278-02 I was asked to propose
wording to resolve this issue editorially.

The first difficulty is a lack of uniformity in the operator mapping table:
numeric operations are handled using a generic type "numeric" than embraces
decimal, integer, float, and double, but there is no corresponding generic type
for anyURI and string. I think it would be rather disruptive to try and fix that
now, so the solution below is a little bit asymmetric.

Proposal
========

1. In 3.5.1 Value Comparisons, add a step 5 as follows:

   5. If both the operands are numeric, or if one is of type xs:string and the
other of type xs:anyURI, apply type promotion to one of the operands as
described in B.1 Type Promotion, so that the two operands have the same
primitive type.

2. In Appendix B.2, there is explanatory text for numeric promotion applied to
arithmetic operators, but no similar explanation for comparison operators. 

2a. Add a new fourth paragraph to B.2:

   Before looking up an entry in the table below, type promotion is applied
   to the operands as described in B.1 Type Promotion. 

2b. To the paragraph starting "A numeric operator may be validly applied to an
operand of type...", add the following:

   "Where the entry for an operator with numeric operands gives a result type
other than numeric (for example idiv, which has a result type of xs:integer, or
eq, which has a result type of xs:boolean), then the result is a value of that
type, regardless of the types of the operands. For example, the result of
comparing an integer to a decimal using the eq operator is a boolean". 

Michael Kay
Comment 2 Michael Kay 2006-01-03 17:11:52 UTC
Please note that

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

is also relevant.
Comment 3 Don Chamberlin 2006-02-14 01:22:22 UTC
Mike,
On 01 Feb. 2006, the Query and XSLT working groups agreed with your suggestion 
to make editorial changes clarifying the rules for numeric promotion in value 
comparisons. Since you were present at the discussion, I am marking this 
Bugzilla entry as closed.
Regards,
Don Chamberlin