progsys 'is' and 'is not'

[mfjoneill]

In the progsys problems 26 of the grammars contain:

<comp_op> ::= '<'|'>'|'=='|'>='|'<='|'!='|'is'|'is not'

Since python 3.8 the inclusion of 'is' and 'is not' in comparisons to literals is throwing a Warning.
Unless there is a good reason to retain them, we should consider removing the 'is'|'is not' as choices from the non-terminal <comp_op>

[jmmcd]

Agreed. This <comp_op> is used only in <int>' '<comp_op>' '<int> and for integer comparison there is no benefit to allowing is or is not, as opposed to == and !=.

[dvpfagan]

Just wondering as the suite is based on helmuts suite if is and is not is available there we should keep it. Just a check we should do. Dave

…

On Tue 14 Dec 2021 at 19:44, James McDermott ***@***.***> wrote: Agreed. This <comp_op> is used only in <int>' '<comp_op>' '<int> and in this context there is no benefit to allowing is or is not. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#150 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTHOURJTV3AD4TBPIVXBDUQ6NADANCNFSM5KBRZVAQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[mfjoneill]

That's a good call Dave, as we want to be as consistent as is possible with the benchmark suite.

From what I can tell from the Technical Report pointed to at https://thelmuth.github.io/GECCO_2015_Benchmarks_Materials/
there is no direct equivalent to 'is' and 'is not' adopted in the original study (see Tables 8 & 9).

On this topic the technical report states:

"The question of which instructions to make available for a synthesis system to use for each problem is a complex one. It is important to not cherry pick a small set of instructions that are known to be sufficient to solve a problem; such a selection may be difficult for a real-world problem, where it might not be clear which instructions will be useful. On the other hand, using all available instructions for every problem expands the search space and may make problems more difficult than necessary. We recommend a compromise between these approaches in which one first determines which data types are likely to be useful for solving the problem and then uses all instructions that operate on those data types. For example, an instruction that compares the equality of two integers and returns a boolean would be included if the problem could potentially make use of integers and booleans. By specifying only the data type requirements for a problem, we can limit the number of instructions without cherry picking."

The grammars do include eqauality/inequality operators in the form of '==' and '!=':
<comp_op> ::= '<'|'>'|'=='|'>='|'<='|'!='

As such, I think we are safe to drop 'is' and 'is not'.