#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: | ffa6d525b5e6681687642d9efc80037884823e30
u/vinceknight/16954 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by kcrisman):
Two issues from above I return to.
> > 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?
What I mean is that when you put something in quotes and double backticks,
it looks like code. You can call it support enumeration and still use
`'enumeration'` as the algorithm keyword, but then you need to make it
quite clear what the difference is. I agree that shorter is better in
this case. No double backticks (as later in the doc), not a problem.
> > 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?
What I mean is that you have some documentation in the class definition
for `NormalFormGame` that probably can just go in the initial docstring at
the very top of the file. After all, it's quite general stuff about what
games and Nash equilibria are. This also applies to #16331, as I say, but
perhaps somewhat less so since it will not be expanded in the near future.
Items new to this take on the actual file.
* `We can use Sage to find them and more importantly see if there is a` -
''please'' have someone who knows commas go through this entire file. I
don't need every Oxford comma, but the sentences are often quite run-on.
* In the following section, you may need to clarify that you mean this as
vector/matrix multiplication. Even though you then do that in Sage,
someone who is just reading it and not necessarily looking at the code may
get confused - especially those who come from a background where column
vectors and row vectors are truly separate things, never to be mixed (as
opposed to in Sage!).
{{{
We can use Sage to compute the expected utility for any mixed strategy
pair `(\sigma_1, \sigma_2)`. The payoff to player 1 is given by:
}}}
* In {{{playing strategy `i` is given by (`(Ay)_i`)}}} perhaps once again
a gentle reminder that you mean matrix times vector could be useful. Do
you think I'm being too gentle on the reader?
* `Rock-Paper-Scissors-Lizard-Spock` - I'm scared to ask... fun, but
perhaps want to put a reference in for this non-standard example.
* I am scared of the syntax `sage: f.add_player(2)`. Am I adding the
player named `2`? Am I adding two new players? And why do I do this
''twice'' in a row? Using "gambit syntax" is nice but would need to be
fully explained. By the way, this is the kind of thing that really does
do better in the "top matter".
* Can we add the ''name'' of a player, or is that a horrible idea? Just
because it might eventually get confusing with lots of players.
* A programmed example of a way to use the
{{{
sage: threegame = NormalFormGame()
sage: threegame.add_player(2)
sage: threegame.add_player(2)
sage: threegame.add_player(2)
sage: threegame[0, 0, 0][0] = 3
sage: threegame[0, 0, 0][1] = 1
sage: threegame[0, 0, 0][2] = 4
...
}}}
syntax would be nice, just like we did in the other game theory
tickets. Who is going to type all that in (accurately) by hand, anyway?
So demonstrating it's possible to do it right with a loop or something is
useful.
* The airline example is cool (actually, really interesting) but really
needs to be in top matter or at least somehow separated. Also, if there
are two paragraphs, separate them with another newline.
* In this same example, you have it that the best strategy is to say the
stuff is worth two, but you have
{{{
[[(1, 0, 0, 0, 0, 0, 0, 0, 0), (1, 0, 0, 0, 0, 0, 0, 0, 0)]]
}}}
Doubtless this corresponds to 100% choosing the first strategy, but
that is not clear since the way the problem is stated makes it sound like
there are 99 strategies or something.
* "In fact degenerate games can cause problems for most algorithm" - but
what is the problem caused in the following example? It gives a solution
that adds to 100% for each player...
--
Ticket URL: <http://trac.sagemath.org/ticket/16954#comment:14>
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.
