Implement Type Promotion about sparqlee

[wschella]

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

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

[jitsedesmet]

@rubensworks This issue shouldn't be closed. We still need to make sure the cast from decimal is performed. #103 (comment)

[jitsedesmet]

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

[jitsedesmet]

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]

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]

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]

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

[jitsedesmet]

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

[wschella]

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