Axelrod-Python/Axelrod

Possibly move play method away from Player

langner opened this issue · 4 comments

It might be more natural to put play onto the game class.

@drvinceknight @langner

Post PR #1241 I'm thinking that history should be moved out of the Player class as well and be managed by the Match class.

First reason is simply efficiency / separation of concerns. A Player shouldn't need to care about tracking history and all its strategy method needs access to is the shared history of play, which all players are now tracking in the History class, so we can simply move it out and pass it in to both Players. It still makes sense to have a Player class because there are often internal variables to track, resets, etc. and it would be rather inefficient to recompute e.g. how many times a player had cooperated each round (if that's needed for the strategy), or any other strategy features.

The second reason is from a mathematical modeling standpoint. As I've described above, the history of play is a "diagonal" of the product of two free monoids on two elements, e.g. pairs of lists of C and D of equal length. A strategy is a function from this set to {C, D} that produces the next action. Our strategy transformers are wrappers on these functions that produce functions of the same type, i.e. they induce functions from the set of strategies to itself. (This is a Category and these are actually induced Functors, which I intended to writeup the details of by never did).

From that point of view, the history itself is not part of the strategy, rather just the input to the strategy function that yields the next move. Passing the history to the two Players in a match should be the job of the Match class, and the Player need not have any other information about the opponent (and generally in the literature, does not). A player could still track its own history say if it wants to detect a noisy environment but that's the exception rather than the rule. A side effect would be that the cheating strategies are no longer possible.

For various 5.0 generalizations I think this is a better starting point. For example if we want to have multiplayer games, we generalize the History class to n-players and the Match class to pass the joint history to each of the individual players as needed. Then we're not passing n-1 players into the strategy classes of Players, just the appropriate history object. Advanced players could play against variable numbers of players and so on based on the properties of the history.

WDYT?

I like the sound of this. Very clean.

Yup, sounds good to me too! 👍

A side effect would be that the cheating strategies are no longer possible.

A long coming demise.