Update tutorial 03 to replicate "Stripped down poker" example

[edwardchalstrey1]

Includes:

• @rahulsavani final commits from de-duplicate_simple_poker_game_in_test_suite branch (see discussion in remove use of poker.efg in test suite #608 (comment))
• Updated tutorial 03

Currently, the EFGs almost match, but with a couple of differences:

1. Tutorial version does not label nodes. @rahulsavani @tturocy I could add the node labels, however this raises the question of whether we'd rather demonstrate indexing with action labels (currently shown in tutorial) or via node labels, I thought based on previous discussions omitting node labels was preferred, though we could include both and explain in the tutorial that either can be used?
2. As discussed, terminal nodes reference player who won - (ok, now I'm thinking it's better to be consistent and label all nodes)

stripped_down_poker.efg:

EFG 2 R "A simple Poker game" { "Alice" "Bob" }
"Stripped-Down Poker: a simple game of one-card poker from Reiley et al (2008)."

c "" 1 "Deal" { "King" 1/2 "Queen" 1/2 } 0
p "" 1 1 "Alice has King" { "Bet" "Fold" } 0
p "" 2 1 "Bob's response" { "Call" "Fold" } 0
t "" 1 "Win Big" { 2, -2 }
t "" 2 "Win" { 1, -1 }
t "" 4 "Lose" { -1, 1 }
p "" 1 2 "Alice has Queen" { "Bet" "Fold" } 0
p "" 2 1 "Bob's response" { "Call" "Fold" } 0
t "" 3 "Lose Big" { -2, 2 }
t "" 2 "Win" { 1, -1 }
t "" 4 "Lose" { -1, 1 }

Tutorial EFG when saved:

EFG 2 R "Stripped-Down Poker: a simple game of one-card poker from Reiley et al (2008)." { "Alice" "Bob" }
""

c "" 1 "" { "King" 1/2 "Queen" 1/2 } 0
p "" 1 1 "" { "Bet" "Fold" } 0
p "" 2 1 "" { "Call" "Fold" } 0
t "" 1 "Alice wins big" { 2, -2 }
t "" 2 "Alice wins" { 1, -1 }
t "" 4 "Bob wins" { -1, 1 }
p "" 1 2 "" { "Bet" "Fold" } 0
p "" 2 1 "" { "Call" "Fold" } 0
t "" 3 "Bob wins big" { -2, 2 }
t "" 2 "Alice wins" { 1, -1 }
t "" 4 "Bob wins" { -1, 1 }

[tturocy]

Those terminal nodes don't have node labels, they have outcome labels. Outcome labels make a lot of sense.

Information set labels sometimes make sense, because they are formally equivalence classes of objects (nodes). Sometimes it's handy to stick a tag on those.

For nodes, a node is exactly equivalent to its history of actions (in a tree at least). So the value of labelling nodes is minimal in the usual case. It is better to think in terms of nodes as histories.

[edwardchalstrey1]

Those terminal nodes don't have node labels, they have outcome labels. Outcome labels make a lot of sense.

Information set labels sometimes make sense, because they are formally equivalence classes of objects (nodes). Sometimes it's handy to stick a tag on those.

For nodes, a node is exactly equivalent to its history of actions (in a tree at least). So the value of labelling nodes is minimal in the usual case. It is better to think in terms of nodes as histories.

Thanks @tturocy based on your comment then, I think the two EFGs in my comment above are close enough, marked this PR as ready for review

[rahulsavani]

Looks good. A few minor comments:

• Let's maybe call the file: 03_stripped_down_poker.ipynb (we will have other more complicated poker variants in the userguide/tutorials soon)

• We cite as "[Mye91]" in the very first sentence. Let's cite Reiley et al (2008), which we already do just after the "enumeration" of subsections. That sentence could just move up to become the new first sentence. The, we can either drop all reference to Myerson, or have a footnote-like comment that the game is similar to but different from the version from Myserson'91.

• Shall we not just unify the outcome labels of this tutorial and the game in the tests now? There are good reasons for either setup: in the tests everything is in terms of Alice, which is common in zero-sum games; in the tutorials, we use player names explicitly. I suggest to pick one, either, and just use it in both places.

• Many cells have a colon in the sentence immediately preceding it, but many do not. I like having the colon where it makes sense, so perhaps try and be more consistent and add in more of these colons wherever possible.

• The final section "Representation of numerical data of a game" is really not about this poker example anymore, though it is clearly related. Fine to keep it but it could also be separate (and possibly then expanded into a full notebook). Might as well keep it as is for now though.

[tturocy]

@rahulsavani will handle reviewing this, so I'm dropping myself off the reviewers list.

[rahulsavani]

Just a few minor comments (some I missed the first time) all for the notebook itself, two inline, the rest here:

This is crucial in games where players must make decisions without complete knowledge of their opponents' private information.

• It could be that chance moves and no player gets to know. Perhaps better to say where "without full knowledge of the state of the game"? 

Since our one-card poker game is extensive form and has two players, we can use the lcp_solve algorithm in Gambit to compute the Nash equilibria

• lcp_solve works for strategic form too, so best to only mention "has two players" here.
• lcp_solve does not find all equilibria in general, so best so say "compute a Nash equilibrium" here

one action over the other, given Alice's expected strategy.

->

• one action over the other, in expectation,  given Alice's strategy.

Every Nash Equilibrium is equivalent to an
->

• Every Nash Equilibrium is an 

[rahulsavani]

I clicked approve rather than changes requested, and can't see how to edit it now. I presume you'll make these changes or comment further.

[rahulsavani]

Before we finally merge let's also squash the commits down to one or a smallish number.

[edwardchalstrey1]

Before we finally merge let's also squash the commits down to one or a smallish number.

I think it does squash commit by default

[rahulsavani]

Before we finally merge let's also squash the commits down to one or a smallish number.

I think it does squash commit by default

There are 15 commits in this currently, and unless you do an explicit squashing of (some of) them there will still be 15 afterwards. Ted is normally doing the final merge. Previously we would often squash remotely and then force push, but we have decided to no longer do force pushes, and only do squashing on github itself. When we do merge, which I presume in this case will be done by you, I could suggest only having a handful of commits, if not one.

[tturocy]

Yes, what @edwardchalstrey1 said :)

[rahulsavani]

Oh I see, the default, "squash and merge", is to squash everything to a single commit.

And if one wants to do some squashing but still have multiple commits one can do an "interactive rebase".

Sorry for noise, I only ever did this remotely with rebase.

[rahulsavani]

Looks good to me