SPARQL sum doesn't return always the same result

[edoardoemmolo]

A select query as the following returns always a different result in the last 3-4 digits on a 8 digit number:

select (sum(?money) as ?totalMoney)
where{
?s :hasMoney ?money
}

Could it be a int to float cast problem?

[thompsonbry]

Are the underlying data integer or float? Promotion from integer to float does not occur for sum (for SPARQL) unless there are some floating point values. In general, type promotion for SPARQL leads to either xsd:decimal or xsd:integer depending on whether or not there are floating point values in the mixture.

If there are floating point values in there, then it is likely to be an artifact of parallelism (which effects the order of evaluation for the sum) and/or floating point rounding.

E.g., see https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#1070

Many problems, such as numerical integration and the numerical solution of differential equations involve computing sums with many terms. Because each addition can potentially introduce an error as large as .5 ulp, a sum involving thousands of terms can have quite a bit of rounding error.

If you want the sum to be deterministic, I suggest that you scale the data by 100 and then store it as xsd:integer. Sums over integers are deterministic. I believe that storing money as integers is standard practice for banking systems.

Bryan

On Mon, Feb 11, 2019 at 9:00 AM edoardoemmolo [email protected] wrote:

A select query as the following returns always a different result in the last 3-4 digits on a 8 digit number:

select (sum(?money) as ?totalMoney) where{ ?s :hasMoney ?money }

Could it be a int to float cast problem?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/blazegraph/database/issues/115, or mute the thread https://github.com/notifications/unsubscribe-auth/ACdv4ENzSCicxDFF8bVPIx3kNgfOWTcLks5vMaGngaJpZM4a0oQa .