You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2015/11/16 21:31:11 UTC
[jira] [Updated] (JENA-1070) SPARQL: Cast from xsd:double to
xsd:decimal fails
[ https://issues.apache.org/jira/browse/JENA-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Seaborne updated JENA-1070:
--------------------------------
Description:
Casting from xsd:double to xsd:decimal apparently doesn't work if the xsd:double is in exponent notation. Example:
{noformat}
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT (xsd:decimal("1e0"^^xsd:double) AS ?x) WHERE {}
{noformat}
I tried running this on sparql.org. I expect this to return {{"1"^^xsd:decimal}} or {{"1.0"^^xsd:decimal}}. It returns nothing.
It returns the expected xsd:decimal values when changing the lexical form from "1e0" to "1.0" or "1", although these all represent the same legal double value.
The same problem occurs when casting to xsd:integer, or when the input is xsd:float.
I think the correct behaviour of the xsd:decimal and xsd:integer casting functions are specified in http://www.w3.org/TR/xpath-functions/#casting-to-numerics, and I read them as stating that xsd:double inputs should work.
Since pretty much any maths on xsd:double (including ROUND and FLOOR) returns xsd:double in e notation, this issue makes it very hard to produce “pretty” number output if the input contains xsd:doubles. It looks like one has to resort to truncating the e0 part with string operations.
was:
Casting from xsd:double to xsd:decimal apparently doesn't work if the xsd:double is in exponent notation. Example:
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT (xsd:decimal("1e0"^^xsd:double) AS ?x) WHERE {}
I tried running this on sparql.org. I expect this to return "1"^^xsd:decimal or "1.0"^^xsd:decimal. It returns nothing.
It returns the expected xsd:decimal values when changing the lexical form from "1e0" to "1.0" or "1", although these all represent the same legal double value.
The same problem occurs when casting to xsd:integer, or when the input is xsd:float.
I think the correct behaviour of the xsd:decimal and xsd:integer casting functions are specified in http://www.w3.org/TR/xpath-functions/#casting-to-numerics, and I read them as stating that xsd:double inputs should work.
Since pretty much any maths on xsd:double (including ROUND and FLOOR) returns xsd:double in e notation, this issue makes it very hard to produce “pretty” number output if the input contains xsd:doubles. It looks like one has to resort to truncating the e0 part with string operations.
> SPARQL: Cast from xsd:double to xsd:decimal fails
> -------------------------------------------------
>
> Key: JENA-1070
> URL: https://issues.apache.org/jira/browse/JENA-1070
> Project: Apache Jena
> Issue Type: Bug
> Reporter: Richard Cyganiak
> Priority: Minor
>
> Casting from xsd:double to xsd:decimal apparently doesn't work if the xsd:double is in exponent notation. Example:
> {noformat}
> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
> SELECT (xsd:decimal("1e0"^^xsd:double) AS ?x) WHERE {}
> {noformat}
> I tried running this on sparql.org. I expect this to return {{"1"^^xsd:decimal}} or {{"1.0"^^xsd:decimal}}. It returns nothing.
> It returns the expected xsd:decimal values when changing the lexical form from "1e0" to "1.0" or "1", although these all represent the same legal double value.
> The same problem occurs when casting to xsd:integer, or when the input is xsd:float.
> I think the correct behaviour of the xsd:decimal and xsd:integer casting functions are specified in http://www.w3.org/TR/xpath-functions/#casting-to-numerics, and I read them as stating that xsd:double inputs should work.
> Since pretty much any maths on xsd:double (including ROUND and FLOOR) returns xsd:double in e notation, this issue makes it very hard to produce “pretty” number output if the input contains xsd:doubles. It looks like one has to resort to truncating the e0 part with string operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)