queries involving calculations with large numbers return incorrect results unless scientific notation is used

[Chris]

As a bug report, I've found that SPARQL queries that perform
calculations return incorrect results when the number is completely
written out (3600000000), while correct results are given when
scientific notation is used (3.6E9).

I'm running 4store 1.1.2 with Raptor version 2.0.2 and Rasqal version
0.9.25, and tested this using 4s-query as shown below.

Best regards,

Chris

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX prop: <http://enipedia.tudelft.nl/wiki/Property:>
PREFIX cat: <http://enipedia.tudelft.nl/wiki/Category:>
select ?energy ((?energy / 3600000000) as ?energy_MWh) where {
<http://enipedia.tudelft.nl/wiki/Makung_Powerplant>
prop:Energyoutput-23J ?energy .
} #EOQ

?energy ?energy_MWh
"16599599986720"^^<http://www.w3.org/2001/XMLSchema#double>
"-23885.4"^^<http://www.w3.org/2001/XMLSchema#double>
#EOR

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX prop: <http://enipedia.tudelft.nl/wiki/Property:>
PREFIX cat: <http://enipedia.tudelft.nl/wiki/Category:>
select ?energy ((?energy / 3.6E9) as ?energy_MWh) where {
<http://enipedia.tudelft.nl/wiki/Makung_Powerplant>
prop:Energyoutput-23J ?energy .
} #EOQ

?energy ?energy_MWh
"16599599986720"^^<http://www.w3.org/2001/XMLSchema#double>
"4611"^^<http://www.w3.org/2001/XMLSchema#double>
#EOR

[Mischa Tuffield]

Hi Chris, 

On 7 Apr 2011, at 23:53, Chris wrote:

As a bug report, I've found that SPARQL queries that perform
calculations return incorrect results when the number is completely
written out (3600000000), while correct results are given when
scientific notation is used (3.6E9).

So, I am very rusty on this stuff but iirc 3.6E9 = 3.6 x 10^9 right which is the number you posted above. 

 3 600 000 000

https://encrypted.google.com/search?hl=en&client=firefox&hs=jMe&rls={moz%3AdistributionID}%3A{moz%3Alocale}%3A{moz%3Aofficial}&q=3.6x+10^9&aq=f&aqi=h1&aql=&oq= 

Mischa 

--
You received this message because you are subscribed to the Google Groups "4store-support" group.
To post to this group, send email to 4store-...@googlegroups.com.
To unsubscribe from this group, send email to 4store-suppor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/4store-support?hl=en.

[Cezary Biernacki]

Hi,

I believe that problem is caused by integer handling in 4-store. 3600000000 is considered as an integer, but outside limit handled correctly by 4-store. 3.6E9 on the other hand is recognized as an double and uses floating point aritmethic which is handles much larger values (however with limited precision). You can force doubles by addin ".0" to numbers, e.g. 3600000000.0 or explicitly declaring type "3600000000"^^<http://www.w3.org/2001/XMLSchema#double>.

Cezary

On Fri, Apr 8, 2011 at 12:53 AM, Chris <c_b...@yahoo.com> wrote:

As a bug report, I've found that SPARQL queries that perform
calculations return incorrect results when the number is completely
written out (3600000000), while correct results are given when
scientific notation is used (3.6E9).

I'm running 4store 1.1.2 with Raptor version 2.0.2 and Rasqal version
0.9.25, and tested this using 4s-query as shown below.

[...]

 

[Mischa Tuffield]

<snip/>

On 8 Apr 2011, at 00:26, Cezary Biernacki wrote:

Hi,

I believe that problem is caused by integer handling in 4-store. 3600000000 is considered as an integer, but outside limit handled correctly by 4-store. 3.6E9 on the other hand is recognized as an double and uses floating point aritmethic which is handles much larger values (however with limited precision). You can force doubles by addin ".0" to numbers, e.g. 3600000000.0 or explicitly declaring type "3600000000"^^<http://www.w3.org/2001/XMLSchema#double>.

Cezary

:) I should just go to bed ...

On Fri, Apr 8, 2011 at 12:53 AM, Chris <c_b...@yahoo.com> wrote:

As a bug report, I've found that SPARQL queries that perform
calculations return incorrect results when the number is completely
written out (3600000000), while correct results are given when
scientific notation is used (3.6E9).

I'm running 4store 1.1.2 with Raptor version 2.0.2 and Rasqal version
0.9.25, and tested this using 4s-query as shown below.

[...]

 

[Steve Harris]

Yes, that's because operations involving integer division get promoted to the XSD Decimal datatype, and 4store's decimal implementation is not very good at division.

There's a series approximation that's used to calculate 1/x, and it introduces rounding errors.

int / int -> decimal
float / float -> float

There's a todo item to try and drop in one of the free arbitrary precision libraries, but it introduces complex memory management issues.

- Steve

[Steve Harris]

Not quite, it's the XSD Decimal handling that's the problem.

incidentally, 36 is an Integer, 36.0 is a Decimal, 36.0e0 is a Floating point number, in SPARQL.

4store's Integers are good up to 9*10^18.

Decimals are fine for addition, and multiplication, but don't divide correctly. The problem code is at

https://github.com/garlik/4store/blob/master/src/frontend/decimal.c#L516

Probably someone who's better at numerical methods than me could fix it. 

- Steve