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 https://github.com/gambitproject/gambit/pull/608#issuecomment-3541821298)
• 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

[tturocy]

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

[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.

[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.