[ENH] CN2 Rules: prefer equality (with optional restriction) for categorical variables

[janezd]

Issue

Fixes #7120.

Description of changes

I haven't written any tests -- because there are none so far, so I would consider this as a separate project.

As for documentation: can do, but after we agree about this PR.

Includes

• Code changes
• Tests
• Documentation

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.77%. Comparing base (5eb97b8) to head (e4b9fff).
⚠️ Report is 60 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #7128   +/-   ##
=======================================
  Coverage   88.77%   88.77%           
=======================================
  Files         334      334           
  Lines       73671    73695   +24     
=======================================
+ Hits        65402    65425   +23     
- Misses       8269     8270    +1     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[markotoplak]

Some tests are in Orange/tests/test_rules.py and Orange/widgets/model/tests/test_owrulesclassification.py

[markotoplak]

I think I may have a more elegant solution to the original problem. When the best rule among a set of rules is chosen, it is, among the ones with the same quality score, always the first.

Now, if we just change the rule generation order... Currently it loops per value, and then per operator. If we change it to loop per operator and then per value, the selection algorithm downstream will prefer the == operator.

This approach gives the same result for the zoo dataset as with the new option selected. Here is my changed code:

-                for val in np.unique(X[:, i]):
+                for op in disc_operators:
                     possible_selectors += (
                         Selector(column=i, op=op, value=val)
-                        for op in disc_operators)
+                        for val in np.unique(X[:, i]))

The bad thing is that this approach it is not backward compatible (different rules would be induced with the same settings).

[janezd]

Thanks for a great find. I'd keep both.

• Per OP, rules using inequality are less "actionable"; even if the attribute has five values, we should let the user prohibit inequality.
• But your suggestion would give priority to equality, and should always be enabled. I don't care too much about the lost backward compatibility here.

[markotoplak]

* But your suggestion would give priority to equality, and should always be enabled. I don't care too much about the lost backward compatibility here.

I also don't think compatibility is an issue here.