6212
2008-11-10 11:38:41 +0000
[FO] Semantics of idiv
2009-10-16 20:50:12 +0000
1
1
1
Unclassified
XPath / XQuery / XSLT
Functions and Operators 1.0
Recommendation
PC
Windows NT
CLOSED
FIXED
P2
normal
---
1
mike
mike
public-qt-comments
oldest_to_newest
22388
0
mike
2008-11-10 11:38:41 +0000
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.)
22536
1
mike
2008-11-25 16:51:52 +0000
This was discussed on 25 Nov. There was a general feeling that losing the "Thus, ..." sentence left the previous sentence rather exposed, and insuffient to describe the semantics in an interoperable way. So we need to think about an improved formulation of the normative wording.
22539
2
mike
2008-11-25 18:35:49 +0000
Looking at the current text:
<quote>
Summary: This function backs up the "idiv" operator and performs an integer division: that is, it divides the first argument by the second, and returns the integer obtained by truncating the fractional part of the result. The division is performed so that the sign of the fractional part is the same as the sign of the dividend.
If the dividend, $arg1, is not evenly divided by the divisor, $arg2, then the quotient is the xs:integer value obtained, ignoring (truncating) any remainder that results from the division (that is, no rounding is performed). Thus, the semantics " $a idiv $b " are equivalent to " ($a div $b) cast as xs:integer " except for error situations.
</quote>
we seem to have a long sequence of separate attempts to specify the function, each trying to say the same thing in different words, but none of them achieving real precision.
I think the following text does the job more cleanly:
<quote>
Summary: This function backs up the "idiv" operator by performing an integer division.
If the divisor is (positive or negative) zero, then an error is raised [err:FOAR0001]. If either operand is NaN or if $arg1 is INF or -INF then an error is raised [err:FOAR0002].
Otherwise, subject to limits of precision and overflow/underflow conditions, the result is the largest (furthest from zero) xs:integer value $I such that fn:abs($I * $arg2) <= fn:abs($arg1) and fn:compare($I * $arg2, 0) = fn:compare($arg1, 0).
The implementation may adopt a different algorithm provided that it is equivalent to this formulation in all cases where implementation-dependent or implementation-defined behaviour does not affect the outcome, for example, the implementation-defined precision of the result of xs:decimal division.
Note:
Except in situations involving errors, loss of precision, or overflow/underflow, the result of ($a idiv $b) is the same as (($a div $b) cast as xs:integer).
The semantics of this function are different from integer division as defined in programming languages such as Java and C++.
</quote>
22780
3
mike
2008-12-17 14:15:34 +0000
This proposal was accepted (with minor editorial changes) at the telcon on 16 Dec 2008. Erratum E30 has been drafted, and the text has been incorporated into the editor's draft for the 1.1/2.1 specification.