search

comunica / sparqlee

⚙️ SPARQL expression evaluator library - Moved to @comunica/expression-evaluator
https://www.npmjs.com/package/sparqlee
14 stars 7 forks source link

Implement Type Promotion #12

Closed wschella closed 3 years ago

wschella commented 5 years ago

See https://www.w3.org/TR/xpath-31/#promotion, mostly relevant for the arithmetic operators.

wschella commented 5 years ago

This is mostly implemented, although the docs should explain the workings some more.

Edit 2021: I actually don't think this is true.

jitsedesmet commented 3 years ago

@rubensworks This issue shouldn't be closed. We still need to make sure the cast from decimal is performed. https://github.com/comunica/sparqlee/pull/103#issue-709164604

jitsedesmet commented 3 years ago

If we wish to implement type promotion completely, we should make sure we cast the decimal to double or float when promoting decimal.

jitsedesmet commented 3 years ago

I think this issue is bigger then it seems. If I understand the xsd specs correct, decimal shouldn't have any precision. This is not the case yet. I think #45 is the issue related to this. We already use non precision bound decimals in function by using Decimal.js, introduced in #44 . To be spec compliant we should extend this use. A DecimalLiteral should not hold the typedValue with a number type since number is actually a double. We should make DecimalLiteral hold a string value instead.

If we do that, this issue is a bit closer to being closed. We should then split the parseXSDFloat function from lib/util/Parsing.ts. into parseXSDFloat and parseXSDDouble. In which case the parseXSDFloat function should also check if the value is a valid IEEE single-precision 32-bit floating point like mentioned in the specs.

I think this would solve both #44 and this issue.

wschella commented 3 years ago

You are right in asserting that #45 is a prerequisite for doing numerics entirely correct, i.e. by giving decimals infinite precision. However, I think the issue of type promotion can be considered separate: we can start by making sure it works on a type level (e.g. a decimal can be used when a function expects a float).

The actual specific numeric behavior is imo less important now and can fixed later.

jitsedesmet commented 3 years ago

That part of type promotion already works. I just read that type promotion on a decimal could have a loss of precision and wanted to be sure this happens. That's why this issue is still open. But it seems like we have this loss of precision anyway because we don't represent decimals like we should.

wschella commented 3 years ago

Yes. Precision & ranges are currently not handled correctly at all and should be for another issue. So I guess we can close this?

jitsedesmet commented 3 years ago

We could but we shouldn't forget to handle it in the overloadTree when we implement precision correctly.

wschella commented 3 years ago

Ofcourse, I will repurpose #45 to talk about precision more broadly.