Command line tools: return probability distribution over terminal nodes, expected payoffs and beliefs

[skranz]

First of all, thanks to all contributors to Gambit.

I wanted to ask if it would be possible to augment the command line tools for flags that allow to show in addition to the equilibria the following elements (in a table like manner that can be easily parsed):

1. -- outcomes: the induced probabilty distribution over terminal nodes for each equilibrium
2. -- payoffs: the expected payoffs for each equilibrium
3. -- beliefs: (less important) the beliefs for each node

For example, consider the following game with 3 nodes in which player 1 moves at node 1 and player 2 at nodes 2 and 3:

              2|-------  (10,1) (Outcome 1)
      |-------*|
1     |        |-------  (0,0) (Outcome 2)
*-----|
      |       3|-------- (10,5) (Outcome 3)
      |-------*|
               |-------- (1,1)  (Outcome 4)

The output for one equilibrium in which player 1 mixes equally between the two actions in the first node could look as follows if all three flags are turned on:

NE,0.5,0.5,1,0,1,0    # Probabilities over information sets
OUT,0.5,0,0.5,0       # Probabilities over outcomes
PAY,10,3              # Expected payoffs for each player
BE,1,1,1              # Beliefs over each node in each information set

(Since all information sets are singleton, the beliefs are trivial here). In particular, the option to see the probabilities over outcomes would be really useful.

[tturocy]

This is indeed a useful idea and I have thought about doing something similar. I have been thinking in a different direction, however - rather than sticking with comma-separated I've been thinking about some other sort of formats for automated processing.

Are you thinking about probability distributions over outcomes or terminal nodes? In Gambit, these are different concepts. I don't think distributions over outcomes are (directly) implemented anywhere, but realisation probabilities for nodes certainly are.

An alternative approach would be to use the Python interface instead, which allows access to all information about computed strategy profiles (without having to worry about trying to figure out the mapping between entries in the CSV and objects in the game).

[skranz]

1. Sorry for the confusion, I meant probability distributions over terminal nodes (not outcomes)
2. Another format than csv that can be easily parsed (e.g. JSON) would, of course, also be great. I can see that csv may be not as easily parseable if the different rows for equilibrium probabilities, payoffs and probability distributions over terminal nodes have different number of columns.
3. I am currently running the Gambit command line tools from R. Interfacing R and Python is unfortunately not completely easy (even though interface packages exist) and probably has a substantial overhead compared to calling the command line tools.

[tturocy]

Certainly no need to apologise. Gambit's distinction between outcome and terminal node is quite useful, but it not the convention that all authors follow; so I wanted to be sure I understood the question.

If one wants to represent all of the data in a behaviour or strategy profile, I do think something more structured is indicated. Formats like JSON and/or YAML are logical, because most users can parse those with one line of code given a suitable library, making a lot more sense than having to write custom parsing code. The issue would be in having the right data model; once that's in place, serialisation is of course straightforward.

[stengel]

Q on the original suggestion: "easily parsed" for humans or machines? For the latter, XML seems appropriate (and we have to decide on the format), for humans some conversion from that format may be the way.

[skranz]

I mean easily parsed by a computer. Or more precisely, it shall be easy for a programmer to import the data. I guess XML, JSON and YAML would probably all do the job fine. That being said, I personally find it considerably easier to import JSON (or YAML) from R than to import XML. Probably that is because XML has too much flexibility, so one must know more about the specifics of the format than for JSON. That it is easier human readable would just be a nice side effect of JSON and YAML.

[tturocy]

I do think that stampeding towards XML or any particular format is premature. It is more important to understand what the data model is. Then, it would be trivial to export that model as XML, JSON, and YAML, with the user deciding which they prefer. I would expect JSON would be most popular followed by YAML, as they require much less coding overhead to manipulate. JSON and YAML both have native support for key-value mappings and sequences, which are the most natural way to express the information.