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

breaking change?: what do do with range equality? What is 'undefined'? #663

Open
StrayAlien opened this issue May 24, 2024 · 4 comments
Open

Comments

@StrayAlien
Copy link
Contributor

Hi all,

We have tests in 0068-feel-quality that assert stuff like this (<= 10) = (null..10] is true for ranges. Before 1.5, the missing endpoint on <=10 was null. Now it is 'undefined'. Ironically, the word 'undefined' is not actually defined in the spec so, what it means is unknown. It is a value? Not sure. It give no guidance as what happens when something is undefined.

But ... the undefined thing for ranges raises some questions.

Is (<= 10) = (null..10] now false?

What is the value of <=10.start ? I think it used to be null, but now it is undefined. Is accessing that start property now illegal? If no ... (here we go) .... is that result of <=10.start actually an now error condition and therefore returns .... null ...

See what I mean? I have a feeling that perhaps (<= 10) = (null..10] is now supposed to be false ... but <=10.start might still return null.

@StrayAlien StrayAlien changed the title breaking change?: what do do with equality range equality? What is 'undefined'? breaking change?: what do do with range equality? What is 'undefined'? May 24, 2024
@opatrascoiu
Copy link
Contributor

opatrascoiu commented Jun 20, 2024

Not sure where the confusion is coming from. The operational semantics of unary tests and ranges are well defined in Table 55: Semantics of decision table syntax. The ones for the relational operators in Tables 52, 53, and 54.

Based on the above <=5 and (null, 5] evaluate to different results hence they are not equivalent, hence cannot be equal, it would break the substitution principle.

The undefined should probably be replaced with + /- infinity so that these constructions make any sense from the mathematical point of view.

@baldimir
Copy link
Collaborator

From discussion on the meeting, this is correct: "I have a feeling that perhaps (<= 10) = (null..10] is now supposed to be false ... but <=10.start might still return null"

@StrayAlien
Copy link
Contributor Author

StrayAlien commented Jul 24, 2024

@baldimir - that was my take. BUT ... just noting that <=10.start returns null not because the start value is actually null, but because accessing start is an error condition because its value is "undefined" (whatever that is ...).

Furthermore to the range equality discussion we also have this: #667. Whereby ranges can now be represented by (say) =10 and !=10.

But, I think I may have the answer for equality .... strictly speaking, we can go back to this definition from the spec table 53:

the ranges must specify the same endpoint(s) and the same comparison operator or endpoint inclusivity flag.

I think what we've (I!) have been missing here is the "the same comparison operator" thing.

I think this tells use that a range with a comparison operator could never be equal to a range without a comparison operator. So, <=10 cannot be equal to anything except <=10. Period.

Though, as "comparison operator" is not exposed as a range property it cannot be taken into account and thus you get the following strange situation in feel:

Var expression start included start end end included
A <=10 false undefined (but ... null) 10 true
B (null..10] false null 10 true

If we compare A and B for equality (in FEEL) like:

A.start included = B.start included &&
A.start = B.start &&
A.end = B.end &&
A.end included = B.end included

The answer is true. As A.start is "undefined", accessing its value is null. And therefore it does equal B.start.
I think we can say that =10 does not equal anything but =10, and likewise for !=10.

Table "Table 42: Examples of range properties values" should probably explicitly have an example for =10 and !=10. Would it be this?

expression start included start end end included
=10 true 10 10 true
!=10 false 10 10 false

BUUUUTTT .... I think we can say that, for equality reasons, we need to take the comparison operator into account on a range if it has one and that must be part of a DMN runtime impl of = .

Hope that made sense. I'll fix up the tests to reflect the "the same comparison operator" thing.

Greg.

@StrayAlien
Copy link
Contributor Author

Furthermore ... we probably need to define / test what we would expect of the interval functions when they're presented with unary comparison ranges. For example (say):

after(=10, !=10), or after(=10, <10) ... or (say) meets(=10, >=10)

get my drift?

true, false, or null ?

The definition of how many of these functions operate depends on range start / end / inclusivity ....

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

No branches or pull requests

3 participants