From: pat hayes <phayes@ai.uwf.edu>

Date: Sat, 30 Nov 2002 20:04:01 -0600

Message-Id: <p05111b0dba0f1546d692@[10.0.100.247]>

To: Jeremy Carroll <jjc@hplb.hpl.hp.com>

Cc: w3c-rdfcore-wg@w3.org

Date: Sat, 30 Nov 2002 20:04:01 -0600

Message-Id: <p05111b0dba0f1546d692@[10.0.100.247]>

To: Jeremy Carroll <jjc@hplb.hpl.hp.com>

Cc: w3c-rdfcore-wg@w3.org

>Brian wrote: >>This point seems to be >> subtle enough to have misled DanC. > >I am sorry Dan, I've got another one. > >Dan wrote: > >> xsd:float rdfs:subClassOf xsd:double. >> >>That is *not* datatype(xsd:float, xsd:double) entailed >>by the empty graph; the value space of float is *not* >>specified to be a subset of the value space of double. >>So there's no justification ala step 2 above. >> >>For details, see >> Floating-point datatypes are not real datatypes >> Mark Reinhold <mr@eng.sun.com> >> 5 October 1999 >>http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JanMar/0130.html > > > >Unfortunately the details describe descrepancies between the >*mappings* of the two datatypes not their *value spaces*. > >A proof of (with appropriate knowledge of datatypes). > >xsd:float rdfs:subClassOf xsd:double . > >xsd:float value space defn: >http://www.w3.org/TR/xmlschema-2/#float >[[ >The basic ˇvalue spaceˇ of float consists of the values m × 2^e, >where m is an integer whose absolute value is less than 2^24, and e >is an integer between -149 and 104, inclusive. In addition to the >basic ˇvalue spaceˇ described above, the ˇvalue spaceˇ of float also >contains the following special values: positive and negative zero, >positive and negative infinity and not-a-number. >]] > >xsd:double value space defn: >http://www.w3.org/TR/xmlschema-2/#double >[[ >The basic ˇvalue spaceˇ of double consists of the values m × 2^e, >where m is an integer whose absolute value is less than 2^53, and e >is an integer between -1075 and 970, inclusive. In addition to the >basic ˇvalue spaceˇ described above, the ˇvalue spaceˇ of double >also contains the following special values: positive and negative >zero, positive and negative infinity and not-a-number. >]] > >The special values are the same, and each of the basic values of >xsd:float is an xsd:double because if |m| < 2^24 then |m|<2^53 and >if -149 <= e <= 104 then -1075 <= e <= 970. > >QED. Not QED. It might be QED if one were justified in reading these English descriptions as mathematically definitive and written in set-theoretic terms, but one is not. They are English, not mathematics, and they can be understood in different ways. The XSD term 'value space' can be understood in various ways. I am not convinced that value spaces are sets in the usual mathematical sense, given what the XSD spec says about them. It is possible to read those paragraphs as saying that the value spaces are something like algebras or categories (or OOP classes) which are isomorphic to those sets of integers, but are themselves both distinct and disjunct, by definition of 'category' or 'algebra' (or 'class' in OOP, ie a set of methods, and subclass means inheritance.) . And I bet that many readers of the XML Schema docs, and probably some of the *authors* of those specs, do read them that way, at least intuitively. Anyone used to thinking in a strongly typed world (Java classes, eg.) would think that way naturally. They would respond to your proof: but of course saying that they are both numbers in a certain range does not mean they are literally *the same*, because things in distinct categories can never be literally *the same*. They are different *kinds* of number: these are floats, and those others are doubles. Some of them might add: numbers themselves don't *really* exist at all; there are only distinct kinds of numbers. Two different kinds of number might have the same numerical value - which is all that those words mean that misled you - but that doesn't make them literally the same thing. Reals and integers are different classes of thing, and things in distinct classes are essentially different from one another. (That last argument has been made by some writers to RDF-logic, by the way, and they were extremely stubborn about it, citing OOP practice as their authority.) In case this seems insane, bear in mind that most people, even theoretical physicists, distinguish the *complex* number zero from the real number zero, and write the former as a pair 0+0i . This is just as natural or unnatural as distinguishing the real zero from the integer zero, however, or the floating-point zero from the fixed-point zero. (It's no good saying that complex zero is two-dimensional: think of the complex plane with the real line as it x-axis, then zero is the origin, and it is the same *point* on the line and on the plane.) BTW, the fact that even 'mathematical' English prose can be read in various ways is a good illustration for why a spec needs to have a genuinely mathematical version somewhere, if only in an appendix. XML Schema spec is seriously flawed by its lack of an exact semantics, IMO. The spec kind of plays at being mathematical, but it isn't really. If it were, there would be no room for alternative interpretations. > >Moreover we see that > >xsd:int rdfs:subClassOf xsd:double . > >but not > >xsd:int rdfs:subClassOf xsd:float . > >by similar reading of the recommendation. > >(I am sorry Brian, I know you hate this. I tend to side with Dan in >principle, but also wonder about why we should want to do this. >I am not sure anyone would implement this). > >Frankly worrying about these relationships is implicit in our charter. I disagree. Our charter requires us to track XSD as closely as possible, not to rewrite or disambiguate it. If it (XSD) is unclear or ambiguous, then tracking it may be impossible. I think we have come to that point here. We will not go wrong by simply not committing ourselves on some of these topics. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spamReceived on Saturday, 30 November 2002 23:52:51 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 20:24:18 UTC
*