Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DMN 1.5 - 'e' number equivalence #659

Merged
merged 3 commits into from
Sep 19, 2024

Conversation

StrayAlien
Copy link
Contributor

Not very exciting, but, some tests for numbers with exponents.

Without trying to replicate a while load of number tests I thought perhaps it easier just to test that the 'e' number and its not 'e' version are actually equal. Then, the rest is assumed .... we've proven it is a number ...

@baldimir
Copy link
Collaborator

@dmn-tck/contributors please review.

@SimonRinguette
Copy link
Contributor

Reviewed and test pass on the Trisotech Engine

@opatrascoiu
Copy link
Contributor

The tests for numbers with exponent are correct. However, there is a flickering test:

    <decision name="time_009" id="_time_009">
        <description>Tests FEEL expression: 'time("10:30:00+01:00") = time("10:30:00@Europe/Paris")' and expects result: 'true (boolean)'</description>
        <question>Result of FEEL expression 'time("10:30:00+01:00") = time("10:30:00@Europe/Paris")'?</question>
        <allowedAnswers>true (boolean)</allowedAnswers>
        <variable name="time_009"/>
        <literalExpression>
            <text>time("10:30:00+01:00") = time("10:30:00@Europe/Paris")</text>
        </literalExpression>
    </decision>

The offset of @Europe/Paris varies during the year (e.g. winter time vs summer time) hence the issue.

The issue with appending zone ids to time literals was discussed both here and in the RTF meeting. Here we agreed to ban the usage of zone ids for time literals. In DMN 1.6 this use case was deprecated as adding the zone id does not make sense as the date is not known.

I propose removing the test either here or in another PR.

@opatrascoiu
Copy link
Contributor

opatrascoiu commented Jun 10, 2024

Also, we need to discuss the equality tests for ranges according to the DMN 1.5 spec.

For example, range_006: (< 10) = (null..10). According to the spec, the semantics of these two is different when evaluated in the same context, e.g. 5 in X (see Table 42 in Section 10.3.2.7 Ranges). Also, according to the examples in Table 62

(< 10) is the same with (..10)

A missing/undefined endpoint is not the same as being null. When the endpoint is missing it is ignored when building the equivalent logical expression. When the endpoint is null, the result is null (error as null is compared to a comparable value)

We cannot have A = B when A and B produce different results in the same expression. It is against the substitution principle.

@baldimir
Copy link
Collaborator

From discussion on the meeting - let's remove the test with time with a timezone.

@StrayAlien
Copy link
Contributor Author

test removed

…and normal ranges to be in line with 1.5. Added a few additional tests for unary comparison range equality.
@StrayAlien
Copy link
Contributor Author

As this PR is already for the equality suite, I've amended the equality checks here for unary comparison ranges as per discussions here: #663

@StrayAlien StrayAlien changed the title 'e' number equivalence DMN 1.5 - 'e' number equivalence Jul 25, 2024
@baldimir
Copy link
Collaborator

@dmn-tck/contributors please re-review after the updates.

@opatrascoiu
Copy link
Contributor

Looks good to me.

@baldimir baldimir merged commit 3c6c8db into dmn-tck:master Sep 19, 2024
3 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants