另外前面部分行的状态数目是否会小很多？有没有统计过？
另外其实程序里面用到整形数实际上应该只用到加法运算，所以简单扩充到128比特的整数也应该不难
前面部分行的状态数目一直都在剧烈增加。
当行数$n$较接近列数$m$时，增速才比较缓慢。
直到$n-m>4$时，状态数才稳定下来。
所以$n/2$行的状态数远比$n$行的状态数少。
附件是C++源代码。
在Linux系统下可能要稍加修改，比如数据类型__int64要改成long long，输出语句%I64u要改成%llu，以及输入输出文件的路径等。
#####
扩充成128比特的整数要占用更多的空间，这部分空间也要在硬盘上读写的，所以硬盘空间和运行时间都会增加。
现在开始运行10 8这个输入参数了。
为什么程序最后添加了一个scanf(&h);导致程序运行完毕后我以为还没有终止。
另外二进制文件使用fprintf和scanf读写数据比较有趣，被我改成fwrite/fread了（前面以为程序出错是由于它）
应该计算到8*5了（显示第三排，这时状态数目超过2G,好像显示溢出了，因为状态数突然变小了，这个应该对计算没有影响吧？）
你的初始状态为什么是
b=2;
b=2;
这里状态2表示什么？
是不是这些待定状态之间的连线还没有考虑进去？
将数据用hash散列到文件可能不如选择固定几个连续位置的值作为文件名更加好
由于每次添加一个格子仅改变少量位置取值，这样可以保证每个文件数据仅产生出少量文件的数据，可以改善数据缓存的效率（另外每个文件数据产生完毕即可排序压缩）
我把结果直接输出到窗口里了。
程序运行完毕之后会自动关闭窗口。
为了不让窗口关闭，最后添加一个scanf卡住。
0表示这个格子未到达过，1表示这个格子的两端都确定了，不能再次连接到该格子。
大于1的数表示这个格子已经确定了一端，另一端未确定。
我们用相同的数字表示两个格子相连。
"b=2;b=2;"表示这两个格子都已经确定了一端，并且它们是相连的。
程序的运行时间主要由读写硬盘的数据量决定，缓存的效率不是主要问题。
文件数据真正读写之前是存在缓存（内存）里面的，这个对程序效率会有影响的。
现在程序已经输出8*6和8*7的数目分别为55488142和34524432316
而且好像状态数目已经稳定下来了，看来到明天就可以得出8*10的结果
C++代码，看起来跟天书差不多。很多地方还是想不明白，需要恶补！
不知道有没有办法证明4*N的为什么无解啊。