RE: ISSUE-126 (Revisit Datatypes): A new proposal for the real <-> float <-> double conundrum

Hello,

In light of our discussion at today's teleconf, I would like to put forward a new proposal for resolving the dilemma regarding the
real vs. float vs. double problem.

1. We make all of xsd:float, xsd:double, and owl:real disjoint.

2a. We make the value space of xsd:float as containing the following things:

- the special values NaN, +inf, and -inf
- the continuous range of real numbers between the real number min = -(2^24-1)*2^(-149) and the real number max = (2^24-1)*2^104,
inclusive.

2b. We make the set of constants of xsd:float exactly the same as in XML Schema. Thus, the lexical representations are INF, -INF,
NaN, and all strings of the form "manEex", where "man" is the decimal mantissa and "ex" is an integer.

By the way, I think that XML Schema specification (Section 3.2.4) is incomplete here: we should additionally say what happens in the
case of constants "manEex" for which man*10^ex is *NOT REPRESENTABLE* in the form m*2^e matching the conditions of xsd:float. The
problem is that, since we are dealing with a logical language, we need to specify how rounding is handled.

We have two options:
- we disqualify such constants as syntactically incorrect, or
- we say that such constants stand for the nearest rounded float.

3. We do the similar thing for xsd:double.

4. We would disallow the "pattern" facet for all numeric datatypes.


In this way, we've stayed true to the XML Schema specification in the sense that all datatypes are disjoint, and we provide for the
special values. The only departure from XML Schema is that we officially need not worry about the discreteness of xsd:float and
xsd:double during reasoning. I find this last point quite important: what is the point in producing a spec that nobody will
implement in its entirety?

Let me know how you feel about this.

Regards,

	Boris

Received on Wednesday, 2 July 2008 19:11:19 UTC