Datatype confusion with XSD float, decimal, integer, double

[chgoe]

I observed the following issue in QLever (installed via PIP, version 0.5.29) after unsuccessfully trying to delete triples yielded by a CONSTRUCT query which turned out to be caused by literals being typed differently than suggested by the query result:

Inserting the following data:

INSERT DATA {
  GRAPH <http://example.org/graph> {
    <http://example.org/s> <http://example.org/p> "960000.06"^^<http://www.w3.org/2001/XMLSchema#float> .
  }
}

followed by querying for that literal:

SELECT * WHERE {
  GRAPH <http://example.org/graph> {
    <http://example.org/s> <http://example.org/p> ?o .
  }
}

will yield the literal, but typed to xsd:decimal rather than the expected xsd:float:
"960000"^^<http://www.w3.org/2001/XMLSchema#decimal>

The following CONSTRUCT query:

CONSTRUCT { ?s  ?p  ?o } WHERE {
  GRAPH <http://example.org/graph> {
    ?s ?p ?o .
  }
}

will even yield an integer literal:
<http://example.org/s> <http://example.org/p> 960000 .

Perhaps this is somehow related to #1817, as the following query also returns xsd:double?

SELECT (DATATYPE(?o) AS ?dt) { 
  GRAPH <http://example.org/graph> {
    <http://example.org/s> <http://example.org/p> ?o .
  }
}

[RobinTF]

@chgoe There are 2 things here.

1. QLever currently treats http://www.w3.org/2001/XMLSchema#float, http://www.w3.org/2001/XMLSchema#decimal and http://www.w3.org/2001/XMLSchema#double all the same. This is a problem in some edge cases with division by zero, but most of the time it doesn't matter. This might change in the future, but for the short term at least this will stay as is.
2. Construct queries are less than ideal at the moment and the problem you're observing is that the datatype is not correctly being written (or alternatively the .06 at the end is lost for some reason). This is a bug that should be fixed, however Fix export and STR result for doubles and decimals with integer values #2358 already fixed something that sound really similar to the thing you observed 3 weeks ago, so can you check if this issue still exists using the latest version?

[chgoe]

I just tried it with c4a8efb: the result for the CONSTRUCT query is unfortunately still the same

[RobinTF]

So I had a look at this and the underlying reason for this is the following quirk of C/C++:

#include <cmath>
#include <cstdio>
#include <iostream>

int main() {
    double d = 960000.06;
    std::printf("%g\n", d); // 960000 <- we're using this one
    std::printf("%f\n", d); // 960000.060000
    std::cout << d << std::endl; // 960000
}

https://godbolt.org/z/nYb14jMhW

So all of the formats are not particularly satisfying. However just fully printing the datatype should be feasible for this case.