Gambit has always supported "information sets" for the chance player, even though this is not a part of most (all?) standard definitions of extensive form games. However the semantics of this have always been awkward, because chance is not a player (and therefore doesn't have "information" per se), and that chance moves require specified probability distributions.
We propose that we will retain this notion, but instead refer to these as chance events. Internally we do not need to make any changes - we for the moment retain the same internal data structures. What will change is the API terminology.
To this end we want to create make_chance_event(nodes, probs[, label]). This is the parallel of the new make_infoset operation (see PR #999). It will accept a collection of nodes all of which must have conformant action labels (but need not all currently be chance nodes). It also requires a specification of the probability distribution probs. This can be specified either as a list-like of numbers of the correct length (in which case they match up one-to-one with the actions in order), or a dict-like mapping action labels to numbers. In the latter case the dict-like can be sparse (in which case omitted actions are given zero probability). In both cases, probabilities must sum to one and all be nonnegative. An optional label can be specified - the rules for this label are the same as for make_infoset.
As a temporary bridge, set_chance_probs can be re-written then to call this new function. I argue that likely we will simply remove set_chance_probs as this function is arguably a semantically more clear way to express a change of probabilities if/when required.
We do not need to worry about changing the other infoset methods to run through this, as we are getting rid of those anyway.
Gambit has always supported "information sets" for the chance player, even though this is not a part of most (all?) standard definitions of extensive form games. However the semantics of this have always been awkward, because chance is not a player (and therefore doesn't have "information" per se), and that chance moves require specified probability distributions.
We propose that we will retain this notion, but instead refer to these as chance events. Internally we do not need to make any changes - we for the moment retain the same internal data structures. What will change is the API terminology.
To this end we want to create
make_chance_event(nodes, probs[, label]). This is the parallel of the newmake_infosetoperation (see PR #999). It will accept a collection of nodes all of which must have conformant action labels (but need not all currently be chance nodes). It also requires a specification of the probability distributionprobs. This can be specified either as a list-like of numbers of the correct length (in which case they match up one-to-one with the actions in order), or a dict-like mapping action labels to numbers. In the latter case the dict-like can be sparse (in which case omitted actions are given zero probability). In both cases, probabilities must sum to one and all be nonnegative. An optional label can be specified - the rules for this label are the same as formake_infoset.As a temporary bridge,
set_chance_probscan be re-written then to call this new function. I argue that likely we will simply removeset_chance_probsas this function is arguably a semantically more clear way to express a change of probabilities if/when required.We do not need to worry about changing the other infoset methods to run through this, as we are getting rid of those anyway.