Conversation
tturocy
left a comment
tturocy
left a comment
There was a problem hiding this comment.
I've written a few implementation comments. However, I am coming back conceptually to the comments I made after your talk a few months ago. I'm now not sure that power (defined like this) is the concept we want, but rather its complement.
Also as a tip: The "Closes #XXX" needs to be in the commit message to auto-close an issue, not in the covering description of the PR.
| Action.precedes | ||
| Action.prob | ||
| Action.plays | ||
| Action.power |
| @property | ||
| def plays(self) -> typing.List[Node]: | ||
| """Returns a list of all terminal `Node` objects consistent with it. | ||
| """Returns a list of all terminal `Node` objects consistent with the action. |
There was a problem hiding this comment.
Simpler is just to say 'terminal nodes' rather than 'terminal Node objects'
| Node.wrap(n) for n in | ||
| self.action.deref().GetInfoset().deref().GetGame().deref().GetPlays(self.action) | ||
| ] | ||
|
|
There was a problem hiding this comment.
Docstring has not been updated.
It would be useful to write a brief explanation of what the 'veto' of an action is here - a few lines so the documentation is self-contained
| assert set(test_action.plays) == expected_set_of_plays | ||
|
|
||
|
|
||
| def test_action_veto(): |
There was a problem hiding this comment.
This explanation would be better put in the docstring of veto rather than in the tests.
|
|
||
|
|
||
| def test_action_veto(): | ||
| """Verify `action.veto` returns the action's veto |
There was a problem hiding this comment.
It would be useful to have a few test fixtures rather than a single test (see other examples throughout the test suite for setting up fixtures). In particular think about potential edge cases - e.g. actions at the root node, actions at singleton information sets versus nontrivial information sets, so on.
|
Through separate discussions events have overtaken this idea. The problem is that whether we look at powers or vetoes, explicitly creating lists or sets of nodes is going to be prohibitively expensive for even the simplest application - so these functions would be of little use to include as core functionality. |
2 participants
Implement, for a given action, its veto
Considering the implementation details of
strategy.power, it appears optimal to define firststrategy.vetoas the union of vetos of corresponding actions the strategy assigns and then generatestrategy.poweras its complement.Thus,
action.powerappears to be redundant.