We are implementing a new approach to identifying proper subgames (see #567). As part of that, there will be a more natural way of working with upgames.
Solving a game by subgames is a process that ideally should be controlled more by the user, as there are choices to be made. For example:
- The user might want to use different solution methods in different subgames. An "upgame" or "subgame difference" with just one player is of course trivial to solve and it would be overkill blindly to apply a solution method. Likewise, there are advantageous algorithms for two-player subgame differences that could be used even if the larger game has more than two players.
- The user might want to filter some subgame equilibria/outcomes.
- When proper subgames have multiple equiilbria, the process naturally lends itself to parallelisation.
The existing C++ implementation permits basically none of this, and is awkwardly implemented to boot.
Also, it is hardly exposed (only in the command-line tools of enumpure, lcp and lp.
Therefore, we're going to remove this entirely from C++. We will instead replace this with some sample codes in Python which implement the procedure to develop the idea further.
We are implementing a new approach to identifying proper subgames (see #567). As part of that, there will be a more natural way of working with upgames.
Solving a game by subgames is a process that ideally should be controlled more by the user, as there are choices to be made. For example:
The existing C++ implementation permits basically none of this, and is awkwardly implemented to boot.
Also, it is hardly exposed (only in the command-line tools of
enumpure,lcpandlp.Therefore, we're going to remove this entirely from C++. We will instead replace this with some sample codes in Python which implement the procedure to develop the idea further.