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 14934 - [QT3TS] numberformat60
Summary: [QT3TS] numberformat60
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Member-only Editors Drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Benjamin Nguyen
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-25 14:12 UTC by Tim Mills
Modified: 2012-05-18 15:20 UTC (History)
2 users (show)

See Also:

Attachments

Description Tim Mills 2011-11-25 14:12:12 UTC 
Our results differ from the expected results for text numberformat60.

Part of the test includes

format-number(1E100 div 3,'#####################')

with the corresponding part of the expected result being

3333333333333333224453896013722304246165110619355184909726539264904319486405759542029132894851563520

Our result for this part of the test is

3333333333333333000000000000000000000000000000000000000000000000000000000000000000000000000000000000

which is the conversion to a string of the double value with bit pattern (expressed as a long) 6095730106324201297.

Is the expected result correct?
Comment 1 Michael Kay 2012-05-17 22:24:27 UTC 
The expected result given certainly can't be justified by the spec; yours is much better.

(The spec does say the value should be converted to decimal, rather than directly to string. For some reaons the Java double-to-BigDecimal is producing this random set of noise, which is defeating Saxon's attempt to remove insignificant non-zero trailers.)

I'll change the test to use your result.
Comment 2 Tim Mills 2012-05-18 15:20:05 UTC 
Confirmed fixed.