You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
System-dependent behaviour of enumpoly on 2x2x2.nfg #591
On the standard game 2x2x2.nfg (the example from McKelvey-McLennan with nine equilibria, the maximum number possible in a game of that size), there are two totally mixed equilibria.
When running gambit_enumpoly on the full support, at the starting point of the search (the centroid), the system of equations has a singular Jacobian.
This was previously noted in for example #474. The fix for that resolved missing one of the equilibria on Windows.
However we have observed that the profile order on Windows is sometimes different from on other platforms (see #589). In the Github action on that issue, it was noted that the order on Windows does not seem to be deterministic - both totally-mixed equilibria are found, but the order is different on different runs. As this is in principle a deterministic algorithm, this behaviour is surprising.
At present, what is suspected here is the following:
There is a point in the system of equations for the full support where the Jacobian is singular.
The implementation of the solution finder is not very sophisticated. In particular, it explicitly inverts the matrix.
Further, the current matrix inversion implementation uses Gaussian elimination.
In short, there's definitely numerical instability near such a point, and from that it is easy to suspect that the consequences of the way this is implemented may be system-dependent. This seems to be a reasonable hypothesis, but hasn't been verified.
In any event, the places in which matrix inversion is being done should be looked at. Further at the moment, this is the only place where Matrix<T>::Inverse is being used.
Activity
tturocy commentedon Jan 15, 2026
At present, what is suspected here is the following:
In short, there's definitely numerical instability near such a point, and from that it is easy to suspect that the consequences of the way this is implemented may be system-dependent. This seems to be a reasonable hypothesis, but hasn't been verified.
In any event, the places in which matrix inversion is being done should be looked at. Further at the moment, this is the only place where
Matrix<T>::Inverseis being used.Addresses two sources of inconsistency in the output of `enumpoly` (#…