[xquery-talk] operations on derived numeric type
Ghislain Fourny
g at 28.io
Tue Sep 3 05:28:52 PDT 2013
Hi Benito,
It makes sense -- it looks like these tests might make stronger assumptions than the spec does.
It would be great if you could file a bug against the test suite (https://www.w3.org/Bugs/Public/, under XPath / XQuery / XSLT) with a list of the involved test case names so it does not get forgotten. I think we may need to have a discussion on that.
Many thanks and kind regards,
Ghislain
On Sep 3, 2013, at 1:11 PM, Benito van der Zander <benito at benibela.de> wrote:
> Hi,
>> now tend to visualize dynamic types as blackboxes with a "does it match" API: you cannot look inside an atomic value and ask for "the" dynamic type, but you can ask "does this sequence sequence-type-match that sequence type?".
>
> Although you can get the actual type with a long typeswitch statement, if no additional schemas are loaded.
>
> Just for fun I now changed the arithmetic functions to auto cast integers of any decimal type to xs:integer and ran the old XQTS on it.
> This causes quite a few tests to fail (e.g. op-numeric-add-1)
>
> Benito
>
> On 09/02/2013 03:03 PM, Ghislain Fourny wrote:
>> Hi,
>>
>> A while ago, I also thought of the expression "an atomic value of type X" to imply that the value is annotated with that type X, i.e., that the value has "the" dynamic type X. As Mike says though, in the specification, it only really means that the value matches type X (according to the sequence/item type matching semantics).
>>
>> After several discussions around types in XQuery, I now tend to visualize dynamic types as blackboxes with a "does it match" API: you cannot look inside an atomic value and ask for "the" dynamic type, but you can ask "does this sequence sequence-type-match that sequence type?".
>>
>> Does it make sense?
>>
>> Kind regards,
>> Ghislain
>>
>>
>> On Aug 30, 2013, at 8:19 PM, Benito van der Zander<benito at benibela.de> wrote:
>>
>>> Hi,
>>>> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128).
>>> So in any case the spec says it returns a value of type x, it can also return a type derived from x.
>>>
>>> And xs:byte(1) + xs:byte(1) instance of xs:byte might also be true.
>>>
>>> I would have expected it to say that explicitly, like "which always returns an xs:integer or derived type derived from it" instead just "which always returns an xs:integer." .
>>>
>>>> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation).
>>> That sounds kind of confusing
>>>
>>>
>>> Benito
>>>
>>> On 08/30/2013 03:24 PM, Michael Kay wrote:
>>>> On 30 Aug 2013, at 12:11, Benito van der Zander wrote:
>>>>
>>>>
>>>>> Hi,
>>>>> is it true that *all* operations on types derived from the numeric types return a value of one of the four base numeric types?
>>>>> For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)).
>>>>>
>>>> Certainly for all arithmetic operations, yes. (Obviously not for operations like (a gt b).
>>>>
>>>>> What's the point of even having these sub types then?
>>>>>
>>>> In my view there's very little point in having these subtypes, but they are there in XSD so XQuery supports them.
>>>>
>>>>> And why does the XQuery 1 test suite have two different output files for the "abs(xs:byte(<e>0</e>)) instance of xs:byte" case (K2-ABSFunc-46)?
>>>>> One is "true", the other is "false"
>>>>>
>>>> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128).
>>>>
>>>> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation).
>>>>
>>>> Michael Kay
>>>> Saxonica
>>>> _______________________________________________
>>>>
>>>> talk at x-query.com
>>>> http://x-query.com/mailman/listinfo/talk
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> talk at x-query.com
>>> http://x-query.com/mailman/listinfo/talk
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
>>
>
More information about the talk
mailing list