There are several reasonable changes to go and a superficial Java program.

There are several changes in go, which are an old problem. The superficial saying is that 3 is 19 to the power of 19, which means that every vertex on the board is in three states: free, black, and white, there are 19*19 points in total, so this result is obtained. But in fact there are not so many, because in so many States, a large part of the status is not possible, that is, there is a dead play on the disk. For example, it is impossible for the whole board to be filled with pawns, and this state is as many as the 19th power of 2.

So a long time ago, I raised the question on the forum that "there are several reasonable CHANGES TO GO games. I originally wanted to solve this problem from the perspective of pure composite mathematics, and tried to get a simple expression result. However, after half a day, there is no reasonable idea. It is certainly possible to write a program for computing, but it seems that everyone on the Forum said this is meaningless. My heart is unwilling. Recently, I finally wrote such a superficial Program (gocount. Java) by learning Java ).

The algorithm of this program is undoubtedly very direct and inefficient. It is an N * n board, enumerating all 3 ^ (N * n) situations, it is a reasonable situation to determine whether each point is a live game. If each point is a live game. The criterion for determining whether each vertex is active (corresponding to the isalive function) is a recursion: A point is alive only when it is an empty point or a point adjacent to the point is free or cool.

The program efficiency analysis is as follows:

The enumallstatus function enumerates all the conditions and executes a total of 3 ^ (N * n) times. In each execution of enumallstatus, you need to call the isvalid function (to determine whether the current situation is reasonable) and call the resetvisited function (to reset the access flag for each vertex ), execute N * n times. The isalive function (determines whether each vertex is active) also executes N * n times. The isalive function is also a recursive function. Its Recursive depth is not well estimated. I think it will probably be a number of linear order with N. Therefore, the total number of isalive executions is O (n ^ 3), which plays a major role in comparison to resetvistied. Therefore, the time complexity of the entire algorithm is O (3 ^ (N * n) * n ^ 3 ).

I calculated some results and set an N * n chessboard. If all the reasonably changed numbers are represented by V (N), then V (1) = 1, V (2) = 57, V (3) = 12675, V (4) = 24318165. on my machine, V (3) uses 125 Ms, and V (4) uses 498907 MS, which is about 8 minutes. However, if we use the time calculated for V (3) and the previous time complexity to estimate the time calculated for V (4) (ignoring the secondary and constant coefficients), the result would be 648000 Ms, it is an order of magnitude similar to the actual situation, so I feel that my estimation of time complexity is roughly accurate.

However, it is estimated that the calculation of V (5) takes about several hundred days. Another problem is that I currently use int variables to count. in Java, the maximum value of int type is 2 ^ 31-1, and it can only handle N = 4. Even if it is changed to the long type, it can only process n = 5. You can calculate it by yourself. Of course, this is a secondary issue, and inefficient algorithms are the main issue.

Another interesting thought is to examine the values of V (N)/3 ^ (N * n), that is, the ratio of reasonable changes to all changes. Based on the current results:

N = 2: V (2) = 57, 57/3 ^ 4 = 0.7037

N = 3: V (3) = 12675,126 75/3 ^ 9 = 0.6440

N = 4: V (4) = 24318165,243 18165/3 ^ 16 = 0.5649

It seems to be getting smaller and smaller, so will it eventually tend to be a constant? I feel that, if optimistic, V (N)/3 ^ (N * n) tends to be a value greater than 0.5, at least 1/3, but it is hard to find a proof. I hope someone can prove that it will not tend to be 0 first.

On the other hand, you can also help me optimize the algorithm, but the main optimization is to make the program do not need to enumerate 3 ^ (N * n) changes, otherwise the program will not be improved.