Enhance Verification Constraints

[gkirgizov]

This enhancement is requested by BAMT & EPDE users. Rationale: some domains work a lot with custom constraints on valid solutions. Examples are EPDE and molecular search (drug design). Making them more usable and, possibly, effective, can facilitate general-purpose application of GOLEM.

The idea is that intuitive & straightforward general-purpose constraints on the search space is an important feature of GOLEM optimizer. So the issue is to make it better.

---

Things to consider:

• We can have constraints on different stages of optimization:

  • 'early' constraints (that define search space before optimization, like graph depth or available nodes)
  • 'intermediate' constraints (that restrict which mutations can be applied and to which nodes; currently it's handled by optional ChangeAdvisor)
  • 'late' constraints (that are applied on mutated and evaluated graphs)

  So, maybe it makes sense to somehow generalize this machinery behind one interface?

• Constraints can work on different representations of the graph & its properties

  Sometimes constraints can be defined on matrix form of graph, sometimes on its spectral properties, sometimes on domain graph and sometimes on graph structure. We can consider a mechanism to get a required representation in verification rule.

[gkirgizov]

Some thoughts on this after some investigation:

• Most of the literature talks about numerical constraints on genotype space; not boolean verification rules. Reference for pymoo with several approaches to handle numerical constraints: https://pymoo.org/constraints/index.html. We can incorporate something like this into Objective, like eps-Constraint logic, but this seems like a new feature and is orthogonal to the original issue.
• We can't really do something much more efficient with boolean functions. We either apply them or not.
• The only thought I have to do rules somewhat more efficient is to try fail-fast: apply verification rules in order with first those that are more likely to fail, then those that rarely fail. For this we only need to collect counts on how often and which rules do fail.

That's regarding efficiency. And I wait for feedback about usability.

[gkirgizov]

Another thought:

• Choice of basic structural constraints (like DAG / cycles and one-root / multi-root) can influence choice of allowed operators. Some mutations can add cycles if it is allowed, and some crossovers can be specialzed either for DAGs (like in FEDOT) or for cycles (e.g. for molecule search).