Re: [DTB] issues with numeric casting/built-in functions

Jos de Bruijn wrote:
> 
> Axel Polleres wrote:
>> I think we are overshooting here and disagree that we should restrict
>> the domain. If we want to adopt/fit with XPAth/Xquery funcs and ops and
>> that was the rationale we took, we should not redefine them. We had to
>> do some tqists already, since we don't have errors, but let's not make
>> things worse/even more diverging. At some point we have to accept
>> implementation dependence in built-ins and I think following
>> XPath/XQuery keeps this within reasonable bounds.

+1

> This means the RIF language is ill-defined and there is no way to
> implement it.

If we define something precisely but no one implements it that way 
(because it differs from their library) is that any better than having 
explicit implementation dependence in the definition?

It is certainly true that Integer and Decimal are problems due this 
fudge of not requiring big num arithmetic.

> So, for casting, I propose to define the xs:decimal casting function
> such that the result of casting a string to a decimal is simply the
> number with the input string as lexical representation, and so we have
> no exception behavior.
> 
> We might define conformance such that implementations only need to
> support decimals of a particular length.

That would work so long as we include the conformance limitation.

> The problem with numeric functions are similar.  With addition,
> subtraction, and multiplication we run into the same problem.  Again, I
> propose to define the functions such that the output values are simply
> the decimals which are the result of the arithmetic operations and not
> from some implementation-dependent modification.

That would mean that only bignum type implementations are admissible, 
since even with the conformance restriction on number of digits in 
literals you can clearly have a result that requires more digits.

I wouldn't formally object to that (Java supports bignums after all) but 
it would seem preferable to define the operators in terms of a band of 
legal values (either explicitly or via the current implicit route of 
deferring to Xpath F&O).

> With division it gets a bit more complicated.  For example, there is no
> decimal that can represent the result of dividing 1 by 3, because there
> are no infinite-length decimals. If we had owl:real we could still
> properly defined the division function, although there is no syntactical
> representation for the result. I have two possible solutions for you:
> (1) We reintroduce owl:real and use it for the definition of
> numeric-divide (I think we need it only there).
> (2) We define the domain of numeric-divide such that only pairs of
> numbers a,b (if they are decimals) are included if a/b can be
> represented using a decimal. This means that if 1,3 are the arguments,
> the value of the function is not specified by DTB and is left up to the
> implementation.

(2) would be acceptable.

[In bignum package's like Java you will get an exception if you attempt 
1/3 without specifying an explicit rounding algorithm.]

Dave

Received on Tuesday, 5 May 2009 11:24:45 UTC