Bug 6316 – [FO] An error should be raised if second argument to op:numeric-integer-divide is INF or -INF

Bug 6316 - [FO] An error should be raised if second argument to op:numeric-integer-divide is INF or -INF

Summary:

[FO] An error should be raised if second argument to op:numeric-integer-divid...

Status:	CLOSED FIXED

Product:	XPath / XQuery / XSLT
Component:	Functions and Operators 1.0
Version:	Recommendation
Platform:	PC Windows XP

Importance:	P4 normal
Target Milestone:	---
Assigned To:	Michael Kay
QA Contact:	Mailing list for public feedback on specs from XSL and XML Query WGs

URL:	http://www.w3.org/TR/xpath-functions/...
Whiteboard:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2008-12-16 16:56 UTC by Henry Zongaro
Modified:	2009-01-28 20:47 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Henry Zongaro 2008-12-16 16:56:32 UTC

The third paragraph of section 6.2.6 of F&O states, "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]."

I think we need to prohibit the second operand from being positive or negative
infinity as well.  If $a is finite, but $b is not finite, there is no value of
type xs:integer that could be delivered as the result of ($a idiv $b) so that
the following relation is true.

   (($a idiv $b) * $b) + ($a mod $b) = $a

I believe the second sentence should read, "If either operand is NaN, positive
infinity or negative infinity, then an error is raised [err:FOAR0002]."

Comment 1 Andrew Eisenberg 2009-01-05 21:37:20 UTC

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.]"

Comment 2 Michael Kay 2009-01-06 16:38:39 UTC

Decided that the result of A idiv INF should be zero. This technically needs no
changes to the text, except possibly for clarification.

Comment 3 Michael Kay 2009-01-28 20:34:35 UTC

Erratum E33 has been drafted to clarify that when the second argument is INF or
-INF, the idiv operator returns zero.

I am marking this bug as fixed, if you agree please mark it closed.

Comment 4 Henry Zongaro 2009-01-28 20:47:23 UTC

I agree with the resolution.