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 29171 - [QT3TS] cbcl-numeric-idivide-008
Summary: [QT3TS] cbcl-numeric-idivide-008
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Tim Mills
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2015-10-02 13:33 UTC by Debbie Lockett
Modified: 2015-10-13 13:57 UTC (History)
2 users (show)

See Also:


Description Debbie Lockett 2015-10-02 13:33:28 UTC
cbcl-numeric-idivide-008 (in test set op-numeric-integer-divide) tests:
xs:float('1e38') idiv xs:float('1e-37')

The test expects the overflow error FOAR0002, but it seems that FOCA0002 should also be allowed (raised when trying to convert infinity to an integer). Alternatively an implementation may return a large integer as the result.
Comment 1 Michael Kay 2015-10-02 14:45:27 UTC
A little more rationale on this:

The spec of idiv (via op:numeric-integer-divide) says it returns "the largest integer such that...."

so in principle an implementation that supports 75-digit integers ought to be able to deliver a successful result.

However, the specification also allows the implementation to choose a different algorithm that might have failure conditions if limits are exceeded, and it is not prescriptive about what error codes might arise in this case. Saxon is using the perfectly reasonable algorithm of doing an xs:float division and then rounding down to an integer. In this case the xs:float division produces INF and the rounding then fails.

For what it's worth, I've experimented with a different algorithm and it produces 999999976930990075686379158893828419930518285429571090543203585326070980319, but I suspect other approaches might deliver a slightly different but equally valid result.
Comment 2 Tim Mills 2015-10-13 12:08:21 UTC
I've added FOCA0002 and a large integer (1 x 10^75).

Please mark as CLOSED if you agree with the resolution.  Otherwise, REOPEN.
Comment 3 Michael Kay 2015-10-13 13:57:56 UTC
I have further modified the "success" result to

            <error code="FOAR0002"/>
            <error code="FOCA0002"/>
               <assert>matches(string($result), '^[0-9]{75,76}$')</assert>

since I think rounding errors are acceptable (given that we allow the implementation a wide choice of algorithms). For example if you promote both floats to doubles, do the division, and then round to an integer, you won't get exactly 10^75.