Package Modularization: Decoupling of games.

This document discusses the solutions / use cases of decoupling the current shapiq library into seperate sub-packages specialized for different use cases: Particularly, it revolves around the decoupling of the benchmark, game, and core code.

Use Cases

1. I want to be able to run a benchmark of black-box approximation methods to estimate concepts implemented in shapiq.
2. The The implementation of a benchmark should be quite easy. Currently its super messey with the different pre-computed configurations.
3. I want to be able to implement better and faster functionality in shapiq, which is of a high code-quality.
4. I like to see some examples of cooperative games which comes with a lot of dependencies that are not important for shapiq core.
5. I want to extend the Benchmark with new datasets and models.
6. The benchmark should be reproducible.
7. I don't want to run tests for the benchmark when I work on shaiq

Problem Statement

1. The shapiq (core) library should be lightweight in terms of dependencies. The dependencies in shapiq should only include dependencies that are needed to compute/approximate interaction scores and visualize them. (UC3)
2. The example games should be always runnable with the current implementation of shapiq. Changes in shapiq's core API design should also be reflected in the example games. (UC4)
3. The benchmark should be quite stable and be easy to extend and use for researchers providing new datasets. (UC2,UC5)
4. The code-quality of shapiq core must be very high.

Decision Table

A) Split shapiq into: shapiq_benchmark, shapiq_games, and shapiq

• We move and reimplement the benchmark logic into a separate project and repository depending on shapiq with a pinned version. If shapiq needs to introduce breaking changes, shapiq_benchmark will still work with the older version of shapiq allowing for easier reproducibility.
• We will remove the shapiq.games module and move it into a separate package shapiq_games. shapiq_games will be in the same repository as shapiq, such that breaking changes are immediately detected and need to be fixed for each PR into shapiq.
• shapiq will contain the base Game class, such that the imputes can still use the functionality.
• We will partition the tests in shapiq into a core test suite and a test suite for the example games, since example games may take way more time than the core tests.

Final Decision

We will implement Approach A.