- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 05 Jan 2009 21:37:21 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6316 Andrew Eisenberg <andrew.eisenberg@us.ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.eisenberg@us.ibm.com --- Comment #1 from Andrew Eisenberg <andrew.eisenberg@us.ibm.com> 2009-01-05 21:37:20 --- I would suggest a different fix fro this problem. In our Recommendation we said: "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." I believe that this leads us to having xs:float("4") idiv xs:float("INF") return 0. Our editors draft of F&O 1.1/2.1, reflecting our resolution of Bug #6212, says: "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 $N such that fn:abs($N * $arg2) le fn:abs($arg1) and fn:compare($N * $arg2, 0) eq fn:compare($arg1, 0)." There is no value of $N, where $arg1 is not NaN, INF, or -INF and $arg2 is INF, that satisfies the expression in the second paragraph (remembering that 0 * INF is NaN and NaN le any value is false). I believe that we should change the first paragraph to say: "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]. [Insert: If $arg2 is INF or -INF, then the result is 0.]" -- 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, 5 January 2009 21:37:33 UTC