- From: <peiyongz@ca.ibm.com>
- Date: Wed, 6 Mar 2002 12:50:50 -0500
- To: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Hi,
The following is a couple of email exchange between Arnold, Cutt and
me, and I simply forgot to
cc the mailing list.
And as he permits, I forward them and hoping someone could comment on
this issue,
preferably some one from the Schema WG, may kindly shed some light on this,
thanks.
Regards,
Peiyong Zhang
____________________________________________
XML Parsers Development, D2-265
IBM Toronto Laboratory , 8200 Warden, Markham
Email: peiyongz@ca.ibm.com
Phone: (905)413-4088
Fax: (905)413-4854; T/L: 778-4088
----- Forwarded by PeiYong Zhang/Toronto/IBM on 03/06/2002 12:40 PM -----
"Arnold, Curt"
<Curt.Arnold@hypr To: PeiYong Zhang/Toronto/IBM@IBMCA
otech.com> cc:
Subject: RE: Clarification on Double/Float
03/06/2002 12:19
PM
Please respond to
"Arnold, Curt"
Your regexps looks good to me. It would match my expectations for other
type systems. However that is just a personal opinion.
Your table also looks reasonable, however I could also see other processors
giving a different set of results. If similar tests aren't in the Schema
datatypes test suite, I'd suggest adding them since I could see this being
an area that implementations might unintentionally differ.
The last couple of email exchanges have not been on the xml-schema@w3.org
mailing list. If you really want a definitive answer on these issues,
you'd
need a response from the WG or at least someone more authoritive. I do not
have any problems with you forwarding or quoting any of the messages in
this
thread to the mailing list, but I didn't want to that the thread there in
case you intentionally went off list.
I don't know how you are approaching floating point validation and
comparison. A couple of years ago, I experimented with lexical comparison
of floating points (in C) which resulted in a pretty substantial throughput
improvement and discussed it in
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JanMar/0135
.
html. Basically, it isn't necessary (except in very rare cases where
rounding effects come into play) to convert a lexical to a floating point
to
do the validation, you can perform the implied comparison by breaking the
lexical representation into fragments and comparing them.
At the time, someone from IBM said that you guys had some ultra-fast
floating point conversion routines and the hit wasn't as bad. I think that
I may still have the code around someplace.
> -----Original Message-----
> From: peiyongz@ca.ibm.com [mailto:peiyongz@ca.ibm.com]
> Sent: Wednesday, March 06, 2002 9:56 AM
> To: Arnold, Curt
> Subject: RE: Clarification on Double/Float
>
>
> Arnold,
>
> >Notice particularly that, at least in Java, positive zero
> and negative
> zero
> >compare equal. I don't know if there is a definitive
> statement in the
> >XML Schema datatypes section that would whether "0" would be
> acceptable
> >if you had a minExclusive="-0" facet. A naïve implementation just
> >depending on
> the
> >operator would say that it was not acceptible.
>
> I 've tested the XercescJ2 and come out with the table below:
> |------------------------+------------------------+-----------
-------------|
> |XSD:minInclusive |instance document |Result
> |
> |------------------------+------------------------+-----------
-------------|
> |-0 |-0 |OK
> |
> |------------------------+------------------------+-----------
-------------|
> |-0 |0 |OK
> |
> |------------------------+------------------------+-----------
-------------|
> |0 |-0 |fails
> |
> |------------------------+------------------------+-----------
-------------|
> |0 |0 |OK
> |
> |------------------------+------------------------+-----------
-------------|
> |XSD:minExclusive | |
> |
> |------------------------+------------------------+-----------
-------------|
> |-0 |-0 |fails
> |
> |------------------------+------------------------+-----------
-------------|
> |-0 |0 |OK
> |
> |------------------------+------------------------+-----------
-------------|
> |0 |-0 |fails
> |
> |------------------------+------------------------+-----------
-------------|
> |0 |0 |fails
> |
> |------------------------+------------------------+-----------
-------------|
>
>
>
> It seems XercesJ does differentiate "-0" and "0".
>
> Please double confirm the followings:
>
> Lexical representation for positive zero: [+]? [0]* '.'?[0]*
> negative
> zero: '-'
> [0]* '.'?[0]*
>
> thanks.
>
> Regards,
>
> Peiyong Zhang
> ____________________________________________
> XML Parsers Development, D2-265
> IBM Toronto Laboratory , 8200 Warden, Markham
>
> Email: peiyongz@ca.ibm.com
> Phone: (905)413-4088
> Fax: (905)413-4854; T/L: 778-4088
>
>
>
>
>
>
> "Arnold, Curt"
>
> <Curt.Arnold@hypr To: PeiYong
> Zhang/Toronto/IBM@IBMCA
> otech.com> cc:
>
> Subject: RE:
> Clarification on Double/Float
> 03/05/2002 07:51
>
> PM
>
> Please respond to
>
> "Arnold, Curt"
>
>
>
>
>
>
>
>
> For comparison here is the Java Language Specification on
> floating point:
>
> http://java.sun.com/docs/books/jls/second_edition/html/typesVa
> lues.doc.html#
>
> 9208
>
> Notice particularly that, at least in Java, positive zero and
> negative zero compare equal. I don't know if there is a
> definitive statement in the XML Schema datatypes section that
> would whether "0" would be acceptible if you had a
> minExclusive="-0" facet. A naïve implementation just depending on the
> > operator would say that it was not acceptible.
>
> > -----Original Message-----
> > From: peiyongz@ca.ibm.com [mailto:peiyongz@ca.ibm.com]
> > Sent: Tuesday, March 05, 2002 5:24 PM
> > To: Arnold, Curt
> > Subject: RE: Clarification on Double/Float
> >
> >
> > Arnold,
> >
> > Thanks a lot for the clarification.
> >
> > 3.2.4.1 Lexical representation
> >
> >
> > float values have a lexical representation consisting of
> a mantissa
> > followed, optionally, by the character "E" or "e", followed by an
> > exponent. The exponent ·must· be an integer. The
> mantissa must be a
> > decimal number. The representations for exponent and
> mantissa must
> > follow the lexical rules for integer and decimal. If the
> "E" or "e"
> > and
> > the following exponent are omitted, an exponent value of 0 is
> > assumed.
> >
> >
> >
> > From the section above, the mantissa is a decimal, which allows
> > leading/trailing zeros (refer to 3.2.3.1),
> > and therefore, 0002 and +0002 are all valid lexcial
> > representations for the number 2E0. Can we conclude, similarly
> > that 0000, 0.0, 00.000 and +0000, +0.0, +00.000 are all valid
> > lexcial representations for positive zero and
> > -0000, -0.0, -00.000 and -0000.00 are all valid lexcial
> > representations for negative zero as well?
> >
> > In a short, are we supposed to extend the lexical
> representation
> > for positive zero to [+]?[0]+['.'[0]+]? and
> > that of negative zero to '-'[0]+['.'[0]+]? .
>
> That would be my preferred interpretation, that all the forms
> of 0 and -0 that you previously mentioned (plus .0, -.0, 0.,
> and -0.) would be valid forms of positive or negative zero.
> However the datatypes spec has this
> phrase:
>
> "The special values positive and negative zero, positive and
> negative infinity and not-a-number have lexical
> representations 0, -0, INF, -INF and NaN, respectively."
>
> I don't believe that was intending to say that "0" is the
> only acceptible way of representing positive zero (and -0 for
> negative zero) and that all the other forms should result in
> validation errors, however that would be a possible
> interpretation. -0 would not be negative zero in Java source
> code (since it would be an integer and integers don't have a
> distinct value for -0.0).
>
>
>
>
Received on Wednesday, 6 March 2002 12:50:55 UTC