game_theory: Add support_enumeration

[oyamad]

Implement "support enumeration", a simple and inefficient algorithm that computes all mixed-action Nash equilibria of a non-degenerate 2-player game.

1. Jit-compiled if Numba >= 0.28 is installed. Fallback to a non-jit version otherwise.

2. The algorithm is to check for all the size-k support pairs for k = 1, ..., min(m, n) whether there is a Nash equilibrium with the given support by solving a linear equation of the indifference conditions, where m and n are the numbers of actions of players 0 and 1, respectively. Note that if m = n, there are (2n choose n - 1) such pairs (for example, 184,755 pairs if n = 10).

3. In solving the linear equation in _indiff_mixed_action, I could have done like

   try:
      sol = np.linalg.solve(A, b)
   except np.linalg.LinAlgError:
      return False

   but Numba does not support try-except, so singularity is explicitly checked by singular values in is_singular, where SVD is only supported by Numba 0.28.

4. An algorithm is needed to enumerate all supports from the given action set, preferably from small to large ones. next_k_array converts the given array of k elements into the integer with the corresponding k set bits in binary representation, and gets the next integer with k bits computed by "Gosper's hack" in next_k_combination (copy-pasted from Wikipedia), and then converts it back to the corresponding k-array. I am not sure if this is the most efficient.

[coveralls]

Coverage decreased (-1.4%) to 85.264% when pulling c45ea5d on supp_enum into 8fd28e3 on master.

[oyamad]

Rebased with #264.

[oyamad]

Numba 0.26.0 versus 0.28.1

A = np.eye(n)
g = NormalFormGame(A)
%timeit support_enumeration(g)

• 0.26.0
  • n = 8: 719 ms
  • n = 9: 2.48 s
  • n = 10: 8.64 s
• 0.28.1
  • n = 8: 71 ms
  • n = 9: 286 ms
  • n = 10: 1.11 s

[oyamad]

Identity matrix was not a good test case.

bimatrix = np.random.rand(n, n, 2)
g = NormalFormGame(bimatrix)
%timeit support_enumeration(g)

• 0.26.0
  • n = 8: 1.02 s
  • n = 9: 3.91 s
  • n = 10: 16.5 s
• 0.28.1
  • n = 8: 118 ms
  • n = 9: 469 ms
  • n = 10: 1.92 s

[oyamad]

Just noticed that Anaconda 4.2.0 had already been released (changelog) which includes Numba 0.28.1. What is our policy regarding the versions of dependent libraries?

[coveralls]

Coverage decreased (-1.4%) to 85.375% when pulling 15c3d91 on supp_enum into 120ab73 on master.

[coveralls]

Coverage decreased (-1.4%) to 85.375% when pulling 15c3d91 on supp_enum into 120ab73 on master.

[oyamad]

Rebased on master.
@mmcky Would you mind merging this too? Thanks!

[mmcky]

@oyamad. Good question. I think our main policy is to try and keep up with the latest anaconda release. To this end I am currently setting up a daily build check against the latest anaconda to our internal build server to get notifications of failures due to ecosystem upgrades.

[oyamad]

I can revert the commit "Add fallback for Numba < 0.28" to target the version of Numba included in the latest Anaconda. Or we could leave it for a future PR.

[mmcky]

@oyamad No need to revert.
This allows it to be run for those that haven't upgraded to the latest so is robust in that sense.
Perhaps though we should add a warning message in the conditional that if numba is < 0.28 that upgrading numba will improve performance. What do you think?

[oyamad]

Good idea. I am going to add a warning message.

[mmcky]

Great - Thanks

[oyamad]

Let me not add a warning this time, as the situation is complicated now. conda update numba will install 0.29.0, but this version has a bug as reported in #269. conda update numba=0.28.1 or conda update anaconda would work, but it looks a bit too much. Let's leave this as is until Numba 0.30 is released. EDIT: Let's not add a warning until Numba 0.30 is released, and please merge this as is.

[mmcky]

@oyamad Ok -- I see the numba PR status is ready for review so it shouldn't be long to wait I suppose.

re: numba in general -- as long as code "runs" error free -- but is slower until a certain release I am happy to merge a PR. However as I read it -- in this case numba=0.29 current version will cause an error which is why travis is currently 0.28.1. So I agree with your assessment.

[oyamad]

Sorry, my last comment was misleading. I corrected it (bottom line: please merge this PR whenever you are ready). Thanks.

[mmcky]

Ah I see. Thanks @oyamad. Will merge this into master.