#16331: Game Theory: Build capacity to solve matching games in to Sage.
-------------------------------------+-------------------------------------
Reporter: vinceknight | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: game theory | Resolution:
Keywords: Game Theory, | Merged in:
Matching Games, | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | cf09cbb3d7478df55592e86e72f335b32396c5c4
u/vinceknight/game_theory__build_capacity_to_solve_matching_games_in_to_sage_|
Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Here's some more things that come from a more detailed look:
- You've created another folder for the game theory called `gametheory`
whereas the existing folder `game_theory` should be used (also it is the
better name IMO).
- Is gambit (#16466) necessary for this ticket?
- Never have mutable attributes public (with no leading underscore `_`,
ex. `suitors` and `reviewers`). It's also good practice to not expose
internal-use attributes.
- Bipartite is one word, so change `bi_partite` to `bipartite`.
- `_dict_game` doesn't have a doctest.
- For the `__eq__` method of `_Player`, I think you're better comparing
`name`. In particular, this would guarantee hash correctness (if `x == y`,
then we must have `hash(x) == hash(y)`).
- Remove the leading underscore of `_Player` so it gets included in the
doc (at least, I think it won't get included as is), and it's the proper
convention for classes. See the following note too.
- In the `all.py`, it's not good practice to import everything in a
particular module (file) as it makes it harder to import things into the
global namespace.
- In the `__init__.py`, you don't need to `import all` (usually these
files are left blank).
- Make `_Player` inherit from `object` since new-style classes are
recommended by python (or at least remove those parentheses). Same for
`Coop_Game`.
- Rename `Coop_Game` to `CoopGame`; the latter is the proper naming
convention for classes.
- Actually, more generally in your code you've mixed the python
conventions: classes follow `CamelCase` and functions/attributes/variables
use `underscore_names`.
- `cooperativegames.py` (which probably should be renamed as
`cooperative_games.py` for easier reading) is lacking doctests. Actually,
is this redundant from `game_theory/cooperative_game.py`?
- Doc formatting:
{{{
-``name`` - Can be a string or a number. If left blank will automatically
generate an integer.
}}}
should be
{{{
- ``name`` -- a string or a number; if left blank will automatically
generate an integer
}}}
Note the punctuation, spacing, and alignment. Also change `: ::` into
`::` (this was noted by Karl on another ticket I believe).
- More on the docs, please make the short description into the affirmative
(I think this is the right word). So `Raises` to `Raise`, `Constructs` to
`Construct`, etc. It's a python convention.
I'll take another look once all of this is done.
A category-type question: Does it make sense to talk about the set of all
games on a fixed set of players? If so, is there some notion of a
morphism? I did some searching and came across [[http://www.pps.univ-
paris-diderot.fr/~mh/catgames.pdf|this article]] describing a category for
a particular class of games. So perhaps (on a future ticket) we reorganize
everything into using the category framework. This is more food for
thought.
--
Ticket URL: <http://trac.sagemath.org/ticket/16331#comment:67>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
