ENH: action values for zero-probability infosets should be undefined

[rahulsavani]

Currently, the action value (stored in map_actionsValues) for actions at zero-probability information sets are zero. This enhancement would instead have these recorded as undefined. This may require changing the type of values of the map which is currently, via a template, either a double of Gambit.Rational, or just not populating it for the respective actions at zero-prob infosets.

[tturocy]

We'll also need to give some consideration about the best way to do this, given that C++ does not have a natural "null" value. One possibility is to raise an exception, though this will take a bit of care to ensure code that calls this currently is ready for that.

[tturocy]

@rahulsavani this is of course related to our discussion on #636 , but a slightly different issue.

We should probably raise an exception in C++ for action values and beliefs when the realisation probability of an information set is zero. We do have a ZeroDivisionError exception defined in Gambit (as a subclass of std::runtime_error. That could make sense here without needing to create a new exception (as technically you can view the problem as a divide-by-zero problem in calculating beliefs!)

In Python it's slightly less clear, because we have the option of just returning None rather than converting this to an exception.

Tagging also @edwardchalstrey1 - are there some other packages we could look to that have a similar problem, and how they solve it (in Python at least)?

[tturocy]

On further reflection, std::optional seems the way to go for this in C++, as the semantics are similar to Python's convention. Returning NaN doesn't work for us because we also need to support returning rational numbers, and we don't have a concept of NaN in our rational number class. std::optional would seem to express the intent here more clearly. It'd be straightforward then to map this to Python.

At the end of the day calling code which may deal with profiles that result in unreachable parts of the tree will have to guard against accessing undefined values somehow - whether it's going to be by checking return value or by exception handling. Throwing exceptions from inside the library seems too heavy-weight. If calling code then throws because it tries to access a std::optional that doesn't contain a value, well, that's the calling code's problem!