#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: Karl-Dieter Crisman
Authors: Vince Knight, | Work issues:
James Campbell | Commit:
Report Upstream: N/A | 9e14ff21121029f311b53d608b6a6d826ff2af88
Branch: | Stopgaps:
u/vinceknight/finishedresponsetobigreview|
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by kcrisman):
> > * Since `lrs` is an optional package, will any of the doctests in the
parser file need to be marked optional? I assume not, just checking.
(Maybe the one using the subprocess stuff?)
>
> This was indeed an oversight on our part: have added the optional tests.
Usually our practice is to mark ''only'' the doctest that would actually
fail without the optional package. (After all, testing the other stuff is
worthwhile.) Am I correct that only the stuff depending on {{{process =
Popen(['nash', g1_name, g2_name], stdout=PIPE)}}} needs to be optional?
----
> > > > 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.
>
> Cool.
>
You ''still'' have {{{``enumeration``}}} instead of
{{{``"enumeration"``}}} at one point, though you do have {{{``"lrs"``}}}
correctly there.
----
{{{
#!diff
- playing strategy `i` is given by (`(Ay)_i`)::
+ playing strategy `i` is given by the matrix/vector multiplication:
+ (`(Ay)_i`)::
}}}
And even after you move it, it is confusing. Why a colon before the
colons? What is {{{i}}}? I know but the reader may not.
----
More trivialities:
* Should {{{dictionary like interface}}} perhaps have a hyphen instead of
a space?
* Similarly, {{{A game with 1 equilibria}}} - I think the singular is
{{{equilibrium}}}.
* {{{initiating}}} probably should be {{{initializing}}}, unless this is
secret society?
* The sentence
{{{
However, if one writes down a smaller number than the other, this smaller
}}}
probably needs a blank line in front of it or the documentation will
look like a humongous paragraph. I think I mentioned this before.
----
Thinking aloud: Should
{{{
"Normal Form Game with the following utilities: {}"
}}}
instead be
{{{
"Normal Form Game with the following utilities:\n{}"
}}}
I don't know if Sage often has two-line string representations, though.
----
I'm a bit scared by the following.
{{{
#!diff
- sage: g.obtain_Nash()
- [[(1, 0, 0), (1, 0, 0)], [(0, 1, 0), (0, 1, 0)], [(0, 0, 1), (0,
0, 1)]]
+ sage: g.obtain_Nash(algorithm='enumeration')
+ [[(1, 0, 0), (1, 0, 0)]]
}}}
Shouldn't lrs and enumeration give the same Nash equilibria?
----
> > * Minor but made the code harder to understand:
> > {{{
> > for p2_strategy in range(self.players[1].num_strategies):
> > for i in range(self.players[0].num_strategies):
> > }}}
> > even though they fill exactly the same role. Same with
> > {{{
> > for p2_strategy in range(len(p2_support)):
> > for j in range(len(p1_support)):
> > }}}
>
> Have tried to clarify as suggested: let me know if it still isn't quite
right.
>
Hmm, I kind of meant the opposite - shouldn't `j` be a `p1_strategy` and
so forth? Perhaps I'm misunderstanding this. For stuff like this,
variable names that mean something are crucial. Plus, the new code still
mixes letters and `strategy`s.
----
> > * These mixed strategies
> > seem strange, but I assume correct - can you confirm they are
''exact'' answers?
>
> They were in fact incorrect but have now fixed: answers are definitely
correct now.
>
Well, I have no independent way to check that but hopefully yes!
----
> > * 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".
>
> This is adding a player with 2 strategies. Doing it twice in a row is
because we're adding two players. Tried to think of a way to make it more
verbose but couldn't come to a better conclusion than this but very open
to any suggestions.
>
Maybe at the very least in situations like
{{{
sage: g = NormalFormGame()
sage: g.add_player(2)
sage: g.add_player(2)
sage: g.add_player(2) # Creating a game with three players
}}}
you could, early in the docs, say instead
{{{
sage: g = NormalFormGame()
sage: g.add_player(2) # adding first player with two strategies
sage: g.add_player(2) # adding second player with two strategies
sage: g.add_player(2) # Creating a game with three players
}}}
or something along those lines.
----
> > * I would have expected this to list the bimatrix entries. Instead I
get a very boring list of the possible pure strategies.
> > {{{
> > sage: for key in prisoners_dilemma:
> > ....: print key
> > }}}
>
> This goes back to wanting a game to behave like a dictionary (which in
turn goes back to wanting gambit like syntax): have changed it though so
it prints things out a bit nicer.
>
Well, it doesn't print things nicer, just the doctest does. So I guess
what you are saying is that the keys must be pure strategy pairs to comply
with gambit?
----
> > * 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.
>
> Have added another sentence highlighting that this is a 'smaller'
example.
>
I still don't understand, so for sure the reader won't. You have to tell
the reader what the output ''means'', since they do not see the number TWO
in the output and if they are not a programmer they won't recognize it
from the matrices. I think here you understand the code so well that it
is just obvious to you.
----
> > * Should it be `obtain_Nash` or `obtain_nash`?
>
> Not entirely sure: I felt a bit better going with `Nash`... I would like
to keep Nash if that's not a problem.
>
Given that Sage usually lowercases even proper names most of the time
(such as Schlegel projection or Conway polynomials or Schonheim bound) I
think we need to go with `obtain_nash`. Especially because in programming
there are kind of two conventions - either `camelCase` or `camel_case`,
but not `camel_Case` and that is what it looks like, even if that is not
the intent.
----
Getting closer...
--
Ticket URL: <http://trac.sagemath.org/ticket/16954#comment:24>
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.
