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 1277 - clarification about semantics of +0.0 and -0.0 in
Summary: clarification about semantics of +0.0 and -0.0 in
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P4 minor
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-04-28 22:10 UTC by jameison martin
Modified: 2007-02-25 23:37 UTC (History)
0 users

See Also:


Description jameison martin 2005-04-28 22:10:14 UTC says that it has IEEE float/double
semantics as opposed to xml schema.  i'm not clear on what the
ordering/collation is of xs:float(0.0) and xs:float(-0.0) and how min()/max()
treat xs:float(0.0) and xs:float(-0.0) (not sure based on the doc and not sure
if this is specified in IEEE - there is no link to the IEEE standard provided).
given that negative zero and positive zero seem to designate different numbers,
one would expect that min({xs:float(0.0), xs:float(-0.0)}) => -0.0, but this
doesn't appear to have been stated and thus one could argue that because
xs:float(0.0) eq xs:float(-0.0), it is perfectly valid for min({xs:float(0.0),
xs:float(-0.0)}) to return either -0.0 or 0.0 (or worse still, just return one
or the other arbitrarily, as a typical impl will do by taking the first and
comparing it with the others).

it seems like sorting and min()/max() should be explicitly specified or
clarified to remove any ambiguity.
Comment 1 Paul Cotton 2005-04-28 22:22:21 UTC
There is no link given for [IEEE 754-1985] in our spec since it is not 
available online.  If you review the material at you will see that the only pointer there 
is a mechanism for buying a printed copy.  

But the page does provide several links to publically available 
material that describes both the IEEE 754 and current implementations.  
Hopefully you may find one or more of these useful.

Comment 2 Paul Cotton 2005-04-28 22:57:17 UTC
The following are my attempts to answer your two questions.

1. min({xs:float(0.0), xs:float(-0.0)}) 

Section 6.3.1 op:numeric-equal states:

"For xs:float and xs:double values, positive zero and negative zero compare 

Note as well that this function is used to implement the operators eq, le, ge, 
and ne.

Section 15.4.4 fn:min states that the following code is used to implement the 
function (after certain other cases are covered):

  "Otherwise, the result of the function is the result of the expression:

   if (every $v in $c satisfies $c[1] le $v) 
   then $c[1] 
   else fn:min(fn:subsequence($c, 2)) "

Since fn:min()'s semantics depend on the "le" operator which is defined by the 
op:numeric-equal() function, this means that negative zero and positive zero 
(as floats or doubles) compare equal.

I personally agree that the F&O spec could be clarified by giving the answer 
for the example:
min({xs:float(0.0), xs:float(-0.0)})  
My personal guess is that we will have to permit either postive zero or 
negative zero to be returned but the WGs will have to decide this.

2. ordering/collation is of xs:float(0.0) and xs:float(-0.0)

To answer your sorting question you have to refer to XQuery/XSLT since the F&O 
spec itself does not define sorting.  But Section 3.8.3 Order By and Return 
Clauses in XQuery 1.0 does sorting using the "gt" operator so positive zero 
and negative zero would again be treated as the same.  

This section then goes on to define what happens for equal values:

"If neither V1 nor V2 is greater-than the other for any pair of orderspecs for 
tuples T1 and T2, then:

- If stable is specified, the original order of T1 and T2 is preserved in the 
tuple stream.

- If stable is not specified, the order of T1 and T2 in the tuple stream is 

I think this clearly defines how ordering of negative and positive zero is 
handled in XQuery.  I assume it is as clear in XSLT 2.0.


Comment 3 jameison martin 2005-04-29 00:09:36 UTC
ok, that makes sense and is consistent. thanks for the clarification. in a way
the behavior is odd but once you go down the path that distinct values with
distinct (albeit barely discernible) behaviors are equal as per IEEE things
can't help but get a bit wierd.

in any event, a clarification in the spec would be nice.
Comment 4 Michael Kay 2005-05-10 15:32:09 UTC
Just one extra observation: for sorting, -0 and +0 compare equal, and like all
other equal sort keys, this can be resolved by adding a second sort key. So
(using XSLT notation), 

<xsl:sort select="$n"/>
<xsl:sort select="1 div $n"/>

will cause -0 to be sorted before +0.

Michael Kay
Comment 5 Ashok Malhotra 2005-05-10 19:47:07 UTC
Added example:
fn:min(xs:float(0.0E0), xs:float(-0.0Eo)) returns either positive or negative
zero -- implementation dependent.
Comment 6 Jim Melton 2007-02-25 23:37:09 UTC
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.