Re: [XSCH] My thoughts on XPath eq and current document

In-line response on transitivity issue ...


Benjamin Nguyen wrote:
> 
> Hi all,
> 
> first of all I took some time to read up in detail on XPath 2.0 [1], Nov. 
> 3rd version, looking for precise info on the eq function and type 
> promotion. From what I understand in the recommandation, there are two 
> sorts of numeric type promotion autorized : 
> 
> a) xsd:double to xsd:float
> b) xsd:decimal to xsd:float
> 
> and therefore all other that could be obtained through the use of subtype 
> substitution, such as xsd:integer to xsd:decimal to xsd:float.
> 
> I suppose that type promotion is transitive, however given the ruleset, 
> this is irrelevant.
> 
> To my point : 
> 
> during the F2F it was not clear to me the behaviour of the operator eq and 
> type promotion, I thought that eq was not transitive therefore :
> 
> 1.3^^xsd:decimal eq 1.3^^xsd:float would convert the decimal to float and 
> compare, then return TRUE (pardon my lapse of inverted commas here, and 
> in what follows)
> 
> whereas
> 
> 1.3^^xsd:float eq 1.3^^xsd:decimal would be unable to convert, therefore 
> return FALSE.
> 
> I was wrong on that point (my bad), which is why I voted "does not 
> entail". In fact, type promotion looks for  the first type to which all 
> types can be promoted to, and does the  comparison, my understanding is 
> now that the xs:decimal would be promoted to float, then compared, 
> whatever the order.
> 
> Now :
> 
> this means in fact that comparisons in bewteen types are in reality made 
> within the xsd:float space, since xsd:decimal (xsd:integer) and xsd:double 
> can all be promoted to xs:float
> 
> Example :
> 
> 1.3^^xsd:decimal eq? 1.3^^xsd:float is evaluated in the following way :
> 
> a) 1.3^^xsd:decimal is an exact value
> b) 1.3^^xsd:decimal is promoted to 1.3^^xsd:float 
> c) 1.3^^xsd:float is evaluated to 1.2999999523^^xsd:float
> d) both compare equal -> return TRUE
> 
> Same with 1.3^^xsd:double eq? 1.3^^xsd:float
> 
> a) 1.3^^xsd:double is evaluated to 1.299999999999999822^^xsd:double
> b) 1.299999999999999822^^xsd:double is promoted to 
> 1.299999999999999822^^xsd:float
> c) 1.299999999999999822^^xsd:float is evaluated to 1.2999999523^^xsd:float
> d) 1.3^^xsd:float is evaluated to 1.2999999523^^xsd:float
> e) both compare equal -> return TRUE
> 
> Therefore :
> 
> with this insight, I feel it compelling to adopt the XPath 2.0 eq 
> (pink in document) approach.
> 
> However :
> 
> I disagree with some phrasing in the current [2] document, which I find 
> misleading such as claiming that "eq is non-transitive"
> 
> The example given to support the non-transitive claim is :
> 
> 3.2^^xsd:float eq 3.20000000000000000001^^xsd:decimal
> 
> but not
> 
> 3.2^^xsd:decimal eq 3.20000000000000000001^^xsd:decimal
> 
> I do not understand why this is "non-transitive", 

The usual definition of transitivity is:

x ~ y and y ~ z implies x ~ z

If eq were transitive, then
since:

"3.2"^^xsd:decimal eq "3.2"^^xsd:float
and
  "3.2"^^xsd:float eq "3.20000000000000000001"^^xsd:decimal

we would have

"3.2"^^xsd:decimal eq "3.20000000000000000001"^^xsd:decimal

Since this last eq does not hold, eq is not transitive.

Since eq is not transitive it is not an equivalence relation and does 
not divide the set of all values into equivalence classes.

Since such a division is necessary (at least implicitly) for most common 
implementation techniques in RDF and OWL, some indication of how to 
approximate eq with an equivalence relation would need to be given.




if one adopts the vision
> (which I think is correct) of xsd:float = an interval and xsd:decimal = a 
> point. With such an interpretation, eq can be seen as a polymorphic 
> operator meaning "equals"  in the xsd:float (interval) world (see Allen 
> [3]), meaning "=" in the xsd:decimal (point) world, and meaning "during" 
> if one compares xsd:decimal eq xsd:float or "contains" if one compares 
> xsd:float eq xsd:decimal.
> 
> I suggest adopting these semantics for RDF and OWL eq. This means that the 
> ENTAILMENT is non-transitive, since :
> 
> eg:car eg:engineSizeInLitres "1.3"^^xs:double
> 
> ENTAILS
> 
> eg:car eg:engineSizeInLitres "1.3"^^xsd:float
> 
> But
> 
> eg:car eg:engineSizeInLitres "1.3"^^xsd:float
> 
> DOES NOT ENTAIL 
> 
> eg:car eg:engineSizeInLitres "1.3"^^xsd:double
> 
> Seems to me pretty straightforward and logical.

That may make some sense, but is not XPath eq.

> 
> So after some thought, I'd like to change my vote to _entails_ making it 
> clear that 1.3^^xsd:float IN REALITY means "any float within 2^-24 of 
> the decimal 1.2999999523", and 1.3^^xsd:double means : "any float within 
> 2^-53 of the decimal 1.299999999999999822".
> 

That's not an implausible position.
My main difficulty with it is merely that it is a new position, which in 
some way I was trying to avoid.

For instance, we have no idea about its implementation cost.

Jeremy


> Easy to understand xsd:float does not entail xsd:double
> 
> __
> In brief :
> 
> Advantages : clear interval semantics, full XPath 2.0 compatibility, 
> better entailment
> Disadvantages : none
> __
> 
> Regards,
> 
> BN
> 
> 
> [1] http://www.w3.org/TR/xpath20/
> [2] http://www.w3.org/TR/swbp-xsch-datatypes/
> [3] http://www.cert.fr/dcsd/THESES/fabiani/manuscrit_fabiani/img173.gif
>

Received on Wednesday, 16 November 2005 15:56:20 UTC