The implementation of (Bayesian) action graph games integrated into Gambit represents numerical data in floating point. This is rather deeply baked into the implementation, and would take a substantial refactoring or rewrite to address. Ideally this should be done in due course. However, as an immediate action, we must clarify the typing logic to avoid unexpected behaviour. Specifically:
- Actually, for floating-point calculations, the existing implementation is completely fine and indeed very useful.
- The problem arises in allow calculations using rational precision, as this involves some implicit (and in some places rather dodgy) casting back to rationals. No good can come of this.
This issue suggests the following changes can remedy this:
- Remove support for rational-precision mixed strategy profiles. Indeed the implementation should be de-templated at this time to avoid the temptation of creating them. (The implementation is not careful with type-casting so even at best it would need to be re-written to support rationals.)
- To pure behaviour profiles, we would need to add a
GetPayoffDouble. This would allow one to iterate the strategic form of an AGG if one wanted. But calling GetPayoff to get a Rational on these games would raise an exception. to_arrays in Python and similar functions can be adjusted to export a floating-point output when called on a (B)AGG.
- As an implication, rational-precision algorithms would not be supported (lp, lcp, enummixed), as these depend on getting rational-precision game data.
- We would need to do a bit of thinking about
simpdiv. On the one hand this is naturally an algorithm we think about using rational precision calculations, and that is how it is implemented. But a floating-point version used only for (B)AGGs might be possible. (Are there potential numerical issues in simpdiv due to rounding?)
Note that the big win for (B)AGGs is in calculating payoffs to (totally) mixed strategies. So arguably, if a user had to synthesise rational-precision versions of a game for now to use lp/lcp/enummixed it might not be that bad, at least for now. The alternative is surprising results - see the discussion in PR #859 which initiated the thinking about numerical data types and (B)AGGs.
The implementation of (Bayesian) action graph games integrated into Gambit represents numerical data in floating point. This is rather deeply baked into the implementation, and would take a substantial refactoring or rewrite to address. Ideally this should be done in due course. However, as an immediate action, we must clarify the typing logic to avoid unexpected behaviour. Specifically:
This issue suggests the following changes can remedy this:
GetPayoffDouble. This would allow one to iterate the strategic form of an AGG if one wanted. But callingGetPayoffto get a Rational on these games would raise an exception.to_arraysin Python and similar functions can be adjusted to export a floating-point output when called on a (B)AGG.simpdiv. On the one hand this is naturally an algorithm we think about using rational precision calculations, and that is how it is implemented. But a floating-point version used only for (B)AGGs might be possible. (Are there potential numerical issues insimpdivdue to rounding?)Note that the big win for (B)AGGs is in calculating payoffs to (totally) mixed strategies. So arguably, if a user had to synthesise rational-precision versions of a game for now to use
lp/lcp/enummixedit might not be that bad, at least for now. The alternative is surprising results - see the discussion in PR #859 which initiated the thinking about numerical data types and (B)AGGs.