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 1794 - Casting float/double to string
Summary: Casting float/double to string
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-21 17:21 UTC by Michael Rys
Modified: 2005-09-29 12:49 UTC (History)
0 users

See Also:


Attachments

Description Michael Rys 2005-07-21 17:21:09 UTC
Since casting from float/double to string is also used in serialization, we 
need to make sure that if I have a a double value that due to the binary to 
decimal conversion will result in a number such as 0.99999999998 instead of 
1.0. 

Since users do not want 0.9999999998 in their serialization output, we should 
allow implementations to do the usual rounding.
Comment 1 Michael Kay 2005-07-21 17:43:48 UTC
If the user does the computation 1.0 - 0.000000002, then the correct answer is
0.9999999998, and we must output it as 0.9999999998. We cannot distinguish this
case from a computation that produced 0.9999999998 as a result of
binary-to-decimal conversion "errors". 

If the user wants to round the result to a certain number of decimal places,
they have the means to do so, but we should never round the result without being
asked.

Michael Kay
Comment 2 Ashok Malhotra 2005-07-21 22:48:34 UTC
Casting to string, or serialization, must represent the number as accurately as
possible.  If the user wants to round, he is free to do so. 
Comment 3 Ashok Malhotra 2005-09-12 22:19:06 UTC
In a member-only note on September 12, Michael Rys said
"After discussions at the farm, we decided to withdraw this request. We still
believe it is an issue with resolution of double values and the need to deal
with the binary floating point precision errors, but we felt that it added too
much complexity to the spec to start legalizing it."

The bug is thereby closed.