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

Please check, wheter the following reformulation of the Section 3.5 of DTB
   http://www.w3.org/2005/rules/wiki/DTB#Numeric_Functions

works for resolving the issue on numeric functions.

Axel (apologies for late edits)

Jos de Bruijn wrote:
> XPath functions and operators essentially says that each implementation
> can decide for itself which length for decimals it supports.  For
> example, implementation A could support decimals of length 16, while
> implementation B supports decimals of length 20.  In addition, each
> implementation can use its own rounding algorithm for representing
> numbers that need larger decimals.  For example, implementation A could
> truncate numbers, while implementation B rounds them.
> 
> this poses problems for us when defining things like casting functions
> and arithmetic operations.
> for example, according to XPath casting a string
> "0.1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"
> to a decimal results either in an error or a decimal of some length
> (given by the implementation) that is obtained from the number
> corresponding to the string by some arbitrary rounding algorithm.
> 
> It is not possible for us to define this kind of behavior in DTB,
> because functions are defined as functions: you have some input values
> that define an output value.
> In addition, it is really bad for interchange, since some
> implementations do something, while other implementations do something
> else, and you get no warning.
> 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.
> 
> 
> 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.
> 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.
> 
> I think these are crucial issues and we need to have at least an idea of
> where we want to go before DTB can go to last call. Otherwise, it will
> not be possible to make any RIF implementations.
> 
> 
> Best, Jos


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Monday, 11 May 2009 19:48:19 UTC