Source: Goldman Sachs ( Octavian Patrascoiu)
Currently S-FEEL / FEEL contains only one single numeric type called number that matches the semantics defined in IEEE 754-2008.
This can lead to some strange constructions, such as
perfect valid in FEEL.
It also has impact on the performance of the execution (speed).
Here is my proposal:
- keep number as an abstract type to backwards compatibility
- add a new concrete type real/float/decimal that matches the semantics of defined in IEEE 754-2008
- add a new concrete type integer
- change the signature of all built-in functions to restrict number to integer when it makes sense (e.g. index in a string and list, length of string. size of list)
- add a separate paragraph to specify the implicit conversions performed by the FEEL processor when required (e.g. function resolution). For example,
2 + 4.5 leads to a promotion 2 -> 2.0 that adding it 4.5.
If we agree in principal all start working on it.
Reported: DMN 1.1 — Wed, 6 Dec 2017 13:44 GMT
Disposition: Deferred — DMN 1.3
RTF 1.3 is ending
Thank you for reporting the issue; it is likely valid but unfortunately the DMN 1.3 revision task force ran out of time before a member was able to resolve it. The issue will be deferred to the next revision task force.
Updated: Mon, 30 Mar 2020 19:50 GMT