From: Dave Reynolds <der@hplb.hpl.hp.com>

Date: Sun, 15 Feb 2009 10:26:51 +0000

Message-ID: <4997EDEB.6080901@hplb.hpl.hp.com>

To: Sandro Hawke <sandro@w3.org>

CC: public-rif-wg@w3.org

Date: Sun, 15 Feb 2009 10:26:51 +0000

Message-ID: <4997EDEB.6080901@hplb.hpl.hp.com>

To: Sandro Hawke <sandro@w3.org>

CC: public-rif-wg@w3.org

Alan Ruttenberg via Sandro Hawke wrote: > I would note that there are further issues that will complicate the > RIF implementation that result from the way the functional calls on > the numeric operators are defined in the xpath specification. > > 1) http://www.w3.org/TR/xpath20/#mapping > > A numeric operator may be validly applied to an operand of type AT if > type AT can be converted to any of the four numeric types by a > combination of type promotion and subtype substitution. If the result > type of an operator is listed as numeric, it means "the first type in > the ordered list (xs:integer, xs:decimal, xs:float, xs:double) into > which all operands can be converted by subtype substitution and type > promotion." As an example, suppose that the type hatsize is derived > from xs:integer and the type shoesize is derived from xs:float. Then > if the + operator is invoked with operands of type hatsize and > shoesize, it returns a result of type xs:float. Similarly, if + is > invoked with two operands of type hatsize it returns a result of type > xs:integer. > > By my read, this sanctions implementations to do any type promotion > they wish to do in applying numeric operators, for example to coerce > integer arguments to float arguments before doing computations. This does not follow. The type promotion rules are well defined and there is no implementation latitude that I can see - [1] defines the overloading of add, [2] defines the type promotions that are allowed to match the overloaded add signatures, the promotion operation themselves are defined in terms of cast and [3] defines that cast algorithm. This all adds up to predicable, well specified behaviour. > Given > examples such as above this means that if RIF relies on such > operators, ontologies would be consistent in some implementations and > inconsistent in others, independent of anything the OWL working group > can do. I don't believe this is correct. Is there a specific example which illustrates such an implementation dependence of the type promotion/casting? > 2) http://www.w3.org/TR/xpath-functions/#op.numeric > > For xs:decimal values the number of digits of precision returned by > the numeric operators is ·implementation-defined·. If the number of > digits in the result exceeds the number of digits that the > implementation supports, the result is truncated or rounded in an > ·implementation-defined· manner. > > This also leads to the possibility of consistency of an ontology > varying from implementation to implementation, should RIF extend OWL > by using rule with operators such as addition. Agreed and already raised by Jos. However surely OWL already has xsd:decimal and xsd:integer and so already has this problem. This problem is not specific to the operators but is part of the definition of xsd:decimal. A "minimally conformant" implementation [4] is allowed to limit the precision of representation of decimals, so even reading in then writing out an OWL ontology which exceeds that limit will reveal implementation dependency. > 3) http://www.w3.org/TR/xpath-functions/#func-numeric-add says: > > op:numeric-add($arg1 as numeric, $arg2 as numeric) as numeric > > Summary: Backs up the "+" operator and returns the arithmetic sum of > its operands: ($arg1 + $arg2). > > Of course this definition is incorrect. The results of numeric > addition as applied to floats and decimals may only be an > approximation of the arithmetic sum. I see no accurate definition of > numeric-add. Disagree for decimals. The operation is well defined for conformant, as opposed to minimally conformant, implementations of xsd:decimal. For minimally conformant ones then agreed, the difference between truncation and rounding is underspecified. This seems eminently solvable to me (for example by requiring RIF conformant implementations to to be fully not minimally conformant XSD implementations). For float/double agreed, but I don't see there is an alternative which meets our goal of low implementation barrier. For example, Java differs subtlety from IEEE 754 in not supporting all the traps and the associated default policy for those traps [*]. > My take on this: RIF justifies the choice of making xs:float and > xs:decimal disjoint on the basis that this is needed in order for > implementations of RIF to be based on existing implementation of xpath > operators. The consequences of this choice for OWL go beyond simply > making the types disjoint but bring addition constraints on types of > facet values and additional complexity due to the possibility of > implementation dependent results for the numeric operators. The > adoption of xpath operators brings forward a number of issues that seem > inadequately considered and this choice may turn out to be unworkable, > in practice, even for RIF. > > In order for OWL to be precisely defined we need to base our > specification on the mathematical properties of numbers, not the > properties of implementations. If one excludes minimally conformant xsd:decimal implementations then the xsd:decimal hierarchy is well specified and corresponds to the mathematical definition for both RIF and OWL. The issues only arise with floating point numbers and by definition those are about implementation issues and not mathematical abstractions. I would have thought the right approach for OWL would be to eschew floating point altogether or to keep them at arms length by having them in disjoint value spaces in which case if RIF wants to also define operations over them then that's RIF's problem. Dave [1] http://www.w3.org/TR/xpath20/#mapping [2] http://www.w3.org/TR/xpath20/#promotion [3] http://www.w3.org/TR/xpath-functions/#casting-to-numerics [4] http://www.w3.org/TR/xmlschema-2/#decimal [*] This is not an area I've tracked so if Java has resolved the differences with IEEE 754 then this example might be false. My limited knowledge of these issues comes from skimming articles like: http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf :-)Received on Sunday, 15 February 2009 10:27:38 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 17:07:53 UTC
*