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

On 8 Jul 2008, at 18:42, Rob Shearer wrote:

> Hmmm...I think your interpretation might actually be the intent:  
> [the ˇvalue spaceˇs of all ˇprimitiveˇ datatypes are disjoint (they  
> do not share any values)](  
> I'm not crazy about their definitions (a claim about disjointness  
> isn't the same as defining multiple colors of numbers), but they  
> did seem to intend disjoint spaces.

Yep. Again, this isn't dispositive, but I do hope it makes it clear  
where I was coming from.

One reason for this, of course, is to make typing of certain  
operations easier. I.e., if you have actual floating point  
arithmetic, it can help to make it a type error to use decimals with  
it. (And vice versa, if you want to reserve binary floats for  
situations where people are aware of the issues with floating point  

> The new version of the XSchema spec is much [clearer](http:// 
>, and explicitly endorses "other  
> applications" which join the value spaces:
> For purposes of this specification, the value spaces of primitive  
> datatypes are disjoint, even in cases where the abstractions they  
> represent might be thought of as having values in common.  In the  
> order relations defined in this specification, values from  
> different value spaces are ˇincomparableˇ.  For example, the  
> numbers two and three are values in both the decimal datatype and  
> the float datatype.  In the order relation defined here, the two in  
> the decimal datatype is not less than the three in the float  
> datatype; the two values are incomparable.  Other applications  
> making use of these datatypes may choose to consider values such as  
> these comparable.


> Regardless, my experience is that users both want and expect a  
> single number line (modulo NaN and +-inf). I feel that the last  
> sentence of the above section of the new XSchema spec blesses these  
> semantics with xsd constants.

We have to be careful since that's just a working draft. But it does  
seem to be the way they're going.

> And current tools are inconsistent in their interpretation, so any  
> choice we make is going to force *some* implementation(s) to change.

Yep. For sure.

> Is anyone really still pushing for multiple number lines, one of  
> which includes Integers and one of which includes (for example)  
> floats?

It's still open. I'm still unsure where I stand. My last position was  
to drop floats and doubles entirely so as to avoid this issue :) (and  

(Some of these are user issues. I think encouraging people to use  
one, owl type might be overall better. Also, there are lots of other  
issues with floats (bounds, NaN, discreteness). Boris has a new  
proposal that's interesting:
It seems usefully influenced by some of your points. I'm not sure  
what I think about it yet.

I've not talked with other Pellet people about it yet, nor asked on  
the Pellet list. I need to think some more on it.

We also need to figure out some stuff about conformance. E.g., if we  
spec minimum sizes on integers, how should implementations handle  
larger integers in the data? How do we label stuff, etc.)

I think we, as a group, have a better understanding (I certainly do).  
But I'm not sure if we've got consensus yet. I hope you'll be willing  
to review the detailed work when it's further along.


Received on Tuesday, 8 July 2008 18:19:39 UTC