jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Cyganiak (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JENA-153) Query bug for large integers
Date Wed, 02 Nov 2011 17:05:32 GMT

    [ https://issues.apache.org/jira/browse/JENA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142306#comment-13142306
] 

Richard Cyganiak commented on JENA-153:
---------------------------------------

I think you're right Damian. Very large xsd:integer literals can be *returned* just fine:

SELECT (10000000000000000000) {}
    => "10000000000000000000" ^^<http://www.w3.org/2001/XMLSchema#integer>

But any *arithmetic*, including comparison, seems to be done on a limited-size representation
of the integer:

SELECT (10000000000000000000+0) {}
    => "-8446744073709551616" ^^<http://www.w3.org/2001/XMLSchema#integer>
SELECT (10000000000000000000=-8446744073709551616) {}
    => true

Now I guess this just means that ARQ keeps around the lexical form of literals that have been
provided, uh, literally in the query, and uses it when returning the literal directly as a
query result; but ARQ uses a different representation, based on the datatype, for arithmetics:

SELECT (007) {}
    => "007" ^^<http://www.w3.org/2001/XMLSchema#integer>
SELECT (007+0) {}
    => "7" ^^<http://www.w3.org/2001/XMLSchema#integer>

And this different representation appears to be java.lang.Long:

SELECT (9223372036854775807+0) {}
    => "9223372036854775807" ^^<http://www.w3.org/2001/XMLSchema#integer>
SELECT (9223372036854775808+0) {}
    => "-9223372036854775808" ^^<http://www.w3.org/2001/XMLSchema#integer>

So any value larger than 9223372036854775807 will overflow.

XSD requires support for integers up to ±10^16 in a minimally conforming processor, so using
only long internally is ok. But then it also says:

[[
When the datatype validity of a value or literal is uncertain because it exceeds the capacity
of a partial implementation, the literal or value must not be treated as invalid, and the
unsupported value must not be quietly changed to a supported value.
]]
http://www.w3.org/TR/xmlschema11-2/#partial-implementation

So that seems to be a clear bug – it should either do the correct arithmetic, or raise an
exception at *some* point.

I'm surprised to find that arithmetic doesn't use Java's BigIntegers. I found this in the
docs:

[[
When parsing an xsd:integer the Java value object used will be an Integer, Long or BigInteger
depending on the size of the specific value being represented.
]]
http://openjena.org/how-to/typedLiterals.html
                
> Query bug for large integers
> ----------------------------
>
>                 Key: JENA-153
>                 URL: https://issues.apache.org/jira/browse/JENA-153
>             Project: Jena
>          Issue Type: Bug
>          Components: ARQ, Jena
>            Reporter: Richard Cyganiak
>            Priority: Minor
>
> ARQ handles small xsd:integers fine, and it handles large xsd:integers fine, but there
seems to be some weirdness going on with integers of ~20 digits:
> ASK {FILTER (200000/2=100000)} => true
> ASK {FILTER (20000000/2=10000000)} => true
> ASK {FILTER (2000000000/2=1000000000)} => true
> ASK {FILTER (200000000000/2=100000000000)} => true
> ASK {FILTER (20000000000000/2=10000000000000)} => true
> ASK {FILTER (2000000000000000/2=1000000000000000)} => true
> ASK {FILTER (200000000000000000/2=100000000000000000)} => true
> ASK {FILTER (20000000000000000000/2=10000000000000000000)} => ***false***
> ASK {FILTER (2000000000000000000000/2=1000000000000000000000)} => true
> ASK {FILTER (200000000000000000000000/2=100000000000000000000000)} => true
> ASK {FILTER (20000000000000000000000000/2=10000000000000000000000000)} => true
> These were all tested in http://sparql.org/sparql.html with an arbitrary target graph
URI.
> It works fine again if dividend and quotient are changed to xsd:decimal:
> ASK {FILTER (20000000000000000000.0/2=10000000000000000000.0)} => true
> I guess this may have something to do with Java's native long being used for xsd:integers
of some size, and BigInteger for others?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message