Float numbers comparison

24 views
Skip to first unread message

Chavdar Ivanov

unread,
Aug 10, 2020, 4:17:49 PM8/10/20
to TopBraid Suite Users
Dear all,

I have a very basic question...
I need to compare literals that are floats and tried to use two ways. 1) using sh:equals to compare 2 properties and 2) using SPARQL where I filter != different values

For the filter I tried using 
FILTER (xsd:float(?value1)!=xsd:float(?value1)).
or
FILTER (?value1!=?value1).
Both give the same outcome.

Below I listed a summary of the tests I did

I think sh:equals treats the literals as strings even though they are floats. It also gives 2 results. I thing this looks like according to the SHACL spec although I didn't if the sh:equals ignores the datatype. 

However In some cases the result form the SPARQL is kind of strange. It looks like the precision is 10-6, but for the big numbers  and when scientific form on float number is used we have something different. 

What is followed to define the difference?
If I use google calculator
100123456.1-100.123459E+06=-2.90000000596

Normally it should be OK to compare different forms of float.


1) using sh:equals in the property shape
Value1 ; value 2  ; comparisson result
1.123456 ; 1.123456 ; same
1.1234560 ; 1.1234561 ; different (sh:equals reports it twice)
31.1234560 ; 31.1234561 ;different (sh:equals reports it twice)
30    ;      30.0000001 ; different (sh:equals reports it twice)
30     ;      30.000001 ; different (sh:equals reports it twice)
100123456.0  ; 100123456.1 ; different (sh:equals reports it twice)
100123456.0  ; 100123456.0 ; same
100123456    ;  100.123456E6 ; different (sh:equals reports it twice)
100123456    ;  100.123456E+06 ; different (sh:equals reports it twice)
-0.123456789  ;  -123.456789E-3 ; different (sh:equals reports it twice)
-0.123456789  ;  -123.456789E-03 ; different (sh:equals reports it twice)
100123456.1    ;  100.123456E+06  ; different (sh:equals reports it twice)
100123456.1     ;   100.123459E+06 ; different (sh:equals reports it twice)
100123456.1     ;  100123459      ; different (sh:equals reports it twice)
100123456.1     ;  100123459.0    ; different (sh:equals reports it twice)

2) using SPARQL (in the property shape)
1.123456 ; 1.123456 ; same
1.1234560 ; 1.1234561 ; different
31.1234560 ; 31.1234561 ;different
30    ;      30.0000001 ; same
30     ;      30.000001 ; different
100123456.0  ; 100123456.1 ; same
100123456.0  ; 100123456.0 ; same
100123456    ;  100.123456E6 ; same
100123456    ;  100.123456E+06 ; same
-0.123456789  ;  -123.456789E-3 ; same
-0.123456789  ;  -123.456789E-03 ; same
100123456.1    ;  100.123456E+06  ; same
100123456.1     ;   100.123459E+06 ; same
100123456.1     ;  100123459      ; same
100123456.1     ;  100123459.0    ; same

Best regards
Chavdar 

Holger Knublauch

unread,
Aug 16, 2020, 8:13:30 PM8/16/20
to topbrai...@googlegroups.com


On 11/08/2020 06:17, Chavdar Ivanov wrote:
Dear all,

I have a very basic question...
I need to compare literals that are floats and tried to use two ways. 1) using sh:equals to compare 2 properties and 2) using SPARQL where I filter != different values

For the filter I tried using 
FILTER (xsd:float(?value1)!=xsd:float(?value1)).
or
FILTER (?value1!=?value1).
Both give the same outcome.

Below I listed a summary of the tests I did

I think sh:equals treats the literals as strings even though they are floats. It also gives 2 results. I thing this looks like according to the SHACL spec although I didn't if the sh:equals ignores the datatype.
sh:equals will compare the RDF nodes, so the datatype will make a big difference and "1"^^xsd:float will be different from "1"^^xsd:string or integer.

In SPARQL you may be better off with xsd:decimal than xsd:float, as xsd:decimal has more precision. But this is more of a SPARQL/ARQ question for which you may get more qualified help elsewhere, e.g. on jena-users.

Holger



Best regards
Chavdar 
--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/63a7e8ba-468e-4803-a1c4-31afca5d55e9n%40googlegroups.com.

Chavdar Ivanov

unread,
Aug 17, 2020, 12:36:35 AM8/17/20
to TopBraid Suite Users

Dear Holger,

 

Thanks. I will approach the other forum.

Just to clarify – yes all literals were typed literals with datatype float. So sh:equals was comparing float to float 

Did you mean that I should use xsd:decimal in the SPARQL query although in data graph it is coming as float?

Something like this

?var1 which is float in data graph

?var2 which is float in data graph

xsd:decimal(?var1)!=xsd:decimal(?var2)

 

Best regards

Chavdar 

Holger Knublauch

unread,
Aug 17, 2020, 6:59:00 PM8/17/20
to topbrai...@googlegroups.com

Since sh:equals is based on RDF node equality, values such as "1.0"^^xsd:float and "1"^^xsd:float count as distinct. Maybe that's the issue you are running into?

SPARQL does comparison by (mathematical) values, so 1.0 = 1 there.

Holger

Chavdar Ivanov

unread,
Aug 18, 2020, 12:33:18 AM8/18/20
to TopBraid Suite Users
Dear Holger,
Thanks.
Yes, I think that explains sh:equals effect.
But SPARQL is a mystery to have some that are correctly compared mathematically such as 
1.123456 ; 1.123456 ; same
1.1234560 ; 1.1234561 ; different

and some that are totally wrong such as
100123456.1     ;  100123459      ; same
100123456.1     ;  100123459.0    ; same
100123456.0  ; 100123456.1 ; same


Best regards
Chavdar 
Reply all
Reply to author
Forward
0 new messages