Symmetry and Data Augmentation

[Scienfitz]

Implements #621

New: A Symmetry class which is part of baybe Surrogates. Three distinct symmetries are included, for more info check the userguide and for a demonstration of the effect see the new example. The ability to perform data augmentation has been included for all symmetries.

I have left some initial comments on design questions that are still open or where I am kind of indifferent and just had to choose one. Feel free to leave an opinion there first so the large-scale design picture can be finalized independent of small comments.

TODO

• CHANGELOG (after architecture is logged in)
• Remember to compress finalized svg picture

Other Notes
Symmetries and constraints are conceptually so similar that they should probably have the same interface. The design here has been done from scratch completely ignoring the constraint interface because it is already known to be not optimal and needs refactoring.

• There is no overarching shared attribute parameters or similar because some symmetries allow single and some multiple such parameters. Instead the parameters are treated like the objectives treat target(s)
• Contrary to dependency constraint, dependency symmetry can only hold 1 set of dependencies. The constraint should be refactored to look the same.
• There is one exception I made but I'm open to still changing it

[AVHopp]

@Scienfitz just to make sure - I guess since this is marked as a draft, you do not require a PR review for now, right? Is there anything else that we can assist with?

[Scienfitz]

@AVHopp yes exactly and it will always be like that for PR's that I open in draft: Ignore until requested or asked in any other way

[Scienfitz]

So far this is a large monolith of a file. Large part of this is validation, so I can see how this is just split up into

• symmetries
  • symmetries.base
  • symmetries.core
  • symmetries.validation

However this would require outsourcing the content of the validate_searchspace_context, so they would effectively become empty hulls calling a utility imported from symmetries.validation. I also like the closeness of the Raises section and the functional content to the actual class. So Im not sure if I should outsource the validations.

[Scienfitz]

This is the only exception where I did still somewhat follow the design of the corresponding constraint. Because all cosntraints share parameters this symmetry requires to specify copermuted_groups as separate attribute. But actually all the groups could be combined into a single attribute.

Instead of parameter_names=["a1", "a2"] and copermuted_groups=[["b1", "b2"],["c1","c2"]] we would have permutation_groups = [["a1","a2"], ["b1", "b2"], ["c1","c2"]]. This is certainly more lgical but maybe a bit less userfirendly if there is really just 1 group.

This would have as consequence that we need to (re)define what the parameters property even should contain or whether it should even be dropped.

In the absence of opinions this wills tay as it is.

[Scienfitz]

Important: Validation so far is only part of the recommend call here in the recommenders. Validation has not been included in the Campaign yet. This is due to two factors

• To properly validate the symmetries and searchspace compatibility there needs to be a mechanism that can iterate over all possible recommenders of a metarecommender. Otherwise this upfront validation already fails for the two phase recommender if the second recommender has symmetries
• There would be double validation with campaign and recommend call so the context info of whether validation was already performed needs to be passed somewhere. Likely fixable with settings mechanism not yet available

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull Request Overview

Copilot reviewed 27 out of 29 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.