#16954: Game Theory: Build class for normal form games as well as ability to
obtain
Nash equilibria
-------------------------------------+-------------------------------------
Reporter: vinceknight | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: game theory | Resolution:
Keywords: Game Theory, | Merged in:
Normal Form Games | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | 33861c9b7b01abd3641bc9ddb64973965b1a93c3
u/vinceknight/16954 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by vinceknight):
I'd written a response to this yesterday and then lost it by pressing the
wrong button: woops!
So here goes again: just my initial thoughts before I start working on it
:)
Replying to [comment:5 kcrisman]:
> It's always easier to nitpick than test, because I don't have to think
about branches or start Sage. Plus, I can see it will really take some
time to go through the representation/algorithm stuff. So here goes.
> * Dumb question:
> {{{
> from sage.misc.package import is_package_installed
> }}}
> Is that really necessary in `all.py`? It does make sense in the other
files.
Will see if works without and remove (might be a relic from when we were
figuring out what we were doing).
>
> * minor
> {{{
> + Normal form games, also referred to as strategic form games are
used to
> + model situations where agents/players make strategic choices the
outcome
> + of which depends on the strategic choices of all players involved.
> }}}
> maybe a few commas here
> {{{
> + Normal form games, also referred to as strategic form games, are
used to
> + model situations where agents/players make strategic choices, the
outcome
> + of which depends on the strategic choices of all players involved.
> }}}
>
> * I'll let "modelled" pass since you are based in the UK ;-)
Not at all precious about it, will look through the rest of Sage and align
the UK/US spelling :)
> * I'll let you figure these out
> {{{
> Amy prefers to player video games
> Gambit has it's own Python api
> }}}
Thanks.
> * You have things like {{{game: ::}}} several times. Typically Sage
code where a colon would be appropriate before a doctest is just
{{{game::}}} even though I suppose you are right that it might not look as
good in built doc.
Thanks, that's a simple one to fix: will do :)
> * In your opening discussion, there is a discrepancy over `1.0` and `1`
in the results of the Battle of the Sexes, also with `3/4` versus `0.75`.
I don't know which is preferable.
I'll take a look, this might also be a relic with gambit as gambit output
only as floats. I'll clear it up.
> * Sage should always be capitalized `Sage` not `sage`.
Woops.
> * You may want to switch to Python 3 formatting in your example of
printing the Nash equilibria utilities.
I'll need to look in to what that is but will do.
> * By the way, both here and in #16331, I'm wondering whether a lot of
the (great) documentation you have for the main games maybe belongs (also)
in the initial docstring. The reason is that this is what is at the top
of the html/pdf documentation. But maybe these are such short files that
the main game appears at the top anyway. Though for this ticket the
starting documentation is SO long I think that really a lot of it should
be at the top - and hopefully there will be some easy way for someone at
the command line or notebook to then ask for that top bit.
Not too sure I understand (apologies). Are you saying to move the docs we
wrote in the library (before any code kicks in) in to the docs for
`NormalFormGame`?
> * https://github.com/tturocy/gambit/tree/sage_integration probably not
necessary to have the link currently.
Thanks (and sorry for not picking this up myself).
> * I think it gets lost here that although you are correct that such
games are technically two matrices, they are nearly universally
represented as one matrix with two elements in each position. I'm not
sure how to resolve this, but it should be thought about. This comes up
in the LaTeX method in particular, though also the documentation.
This was a long discussion. We wanted to allow for both inputs for two
player games: a bi matrix as well as two matrices.
At one point we were going to work on creating a bi matrix class
(inheriting/copying the Sage matrix class) and this is currently an
'enhancement' issue on our github repo (https://github.com/theref/sage-
game-theory/issues/52).
We decided to leave it as it is for now as I think to create a bi matrix
class (and to get it right) is not something worth rushing.
I certainly wouldn't want to get rid of the option to input games as two
matrices as I think I slightly disagree about how universal the bi-matrix
representation is as you do find the two matrix representation in papers
and text books. In fact it can be argued that it's (from a pedagogic)
point of view a 'better' representation as it links easilier to ideas
regarding the underlying linear programming approaches.
So in essence I'd like to leave it as it is for now but with a view (over
the next year or so) to work on a nice bi-matrix class... What do you
think?
> * Similarly, one should think very carefully about the default
''string'' representation of the game being
> {{{
> {(0, 1): [1, 1], (1, 0): [0, 0], (0, 0): [3, 2], (1, 1): [2, 3]}
> }}}
This is in fact completely analogous to the gambit representation of games
and is something we concentrated on (with a view to further gambit
integration later on). We thought about the gambit representation quite
critically and realised that it is actually the 'best' way when it comes
to generalising to games with more than 2 players (which will hopefully at
some point be implemented as alluded to in the docs). So again, I think
this is worth keeping as it is (although very open to discussing it if I'm
missing something).
> rather than some matrix-y thing. We have lots of ways to print stuff
like that in tables and matrices in Sage. That doesn't mean that
internally it can't be a dict, of course!
> * I just love that you are including the plots of the utility functions.
This is so typical for pedagogy and will make this really useful. I'm
cc:ing Greg Bard, who has done this in the past himself, for any comments
he may have on this.
Thanks, this is actually from the time you mentioned it in our first video
call quite a while ago now :)
> * Input a single matrix creates zero-sum - then implicitly two players
is assumed? But I bet we want to be able to eventually assume
representation of at least three players, even if we can't solve them yet.
Yes but in that case the input structures would have to be 'gambit'-y like
the one example of a 3 player game (which is not solved) in the docs.
> * {{{bonus/malus}}} - I've never heard of a "malus" but I like it even
if it isn't a word, it should be, perfect Latinate creation.
I think it might be a French word (I went to high school there so I do
that sometimes...).
> * ALL METHODS must have documentation. Even private double underscore
ones.
On it :) (sorry for being sloppy/lazy)
> * Where did the examples from {{{_repr_}}} go? Same for
{{{payoff_matrices}}}.
Will look for them.
> * I have a similar question about adding players with default strategies
as on the other ticket. What purpose does `_generateutilities` perform?
(And why isn't it `_generate_utilities`?)
Will reflect on this.
> * {{{algorithm='enumeration'}}} or not? You have in one spot
{{{``"support enumeration"``}}} which sounds horrible.
Not too sure I understand. 'support enumeration' is the actual name of the
algorithm which is what we need to pass as an argument (so have shorted to
`enumeration`) like we could also pass `lrs`. Would `support_enumeration`
be any better?
> * Why is parser.py a separate file? Are you planning on adding more
stuff here that is used in general in other types of games (i.e., not
normal form)? Don't forget to doctest that too...
This was a separate file as we also need to parse the gambit output, so
once I work on #16333 there will be another parsing method in there (and
will indeed aim to do the same of other types of games further down the
line). Will add doctests...
> Have fun! All this said, this is clearly very well-organized and I'm
looking forward to seeing this in Sage. Naturally along with Gambit
compatibility :)
Thanks :) Will start working on it on my flight home.
--
Ticket URL: <http://trac.sagemath.org/ticket/16954#comment:7>
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.
