[Bug 6212] New: [FO] Semantics of idiv

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

           Summary: [FO] Semantics of idiv
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


In section 6.2.5 it is stated:

Thus, the semantics " $a idiv $b " are equivalent to " ($a div $b) cast as
xs:integer " except for error situations.

It's not clear whether this statement is intended to be normative. The use of
"Thus" suggests that the authors believe it to be an inevitable consequence of
what has already been stated. But it is not: if it is taken as normative, then
it means that the "division" referred to in the previous sentences must be
performed in exactly the same way as the "div" operator, with the same
implementation-defined limits on precision and the same handling of
overflow/underflow. In particular if $a and $b are integers, then it is
necessary to perform a decimal division to create a decimal with an
implementation-defined number of decimal places, and then truncate, which might
in borderline cases produce a different result than doing an integer division
producing an integer result directly.

Proposal: replace the above sentence with a Note:

Note: this means that the expression "$a idiv $b" gives the same result as "($a
div $b) cast as xs:integer" except possibly in situations involving errors,
overflow/underflow, or loss of precision. 

(This bug report arises from a thread started by Andrew Welch on xsl-list at
mulberrytech.com, which is archived at
http://markmail.org/message/7hocwtuflviaeld4. The thread includes an example
where the two expressions produce different results.)


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 10 November 2008 11:38:51 UTC