刚才没有仔细阅读他们的内容,现在看来,应该是比较正确的.
其中因子9!*72^2是很显然的,主要后面还有一个2^7比较奇怪.不过看他的介绍,这个2^7也是穷举出来的,没有利用什么特征,那么应该是正确的.不过我现在没有拿到他的源代码(里面的链接好像不能用),所以还是不能确定,不过基本上比较可信了

引用:

以下是引用[I]LIKEME[/I]在2006-3-14 10:22:09的发言：[BR]]
第6行第2列、第6行第7列、第8行第2列、第8行第7列形成了“对称格子”，因此第6行第1列只能填6。

不能这样推导吧?因为第六行和第二列都还有其他格子包含7和8的?
比如7,8落在(6,1)和(4,2)上的情况?

(6,7)=A (8,7)=a (8,2)=A (7,1)=a 所以(6,1)<>Aa 你给的那个论坛上好像对这种样式有专门的定义。那里的置顶做的好像不是很好，相整理成体系有点难找：（

[此贴子已经被作者于2006-3-14 12:02:20编辑过]

引用:

以下是引用[I]LIKEME[/I]在2006-3-14 11:52:48的发言：[BR](6,7)=A (8,7)=a (8,2)=A (7,1)=a 所以(6,1)<>Aa 你给的那个论坛上好像对这种样式有专门的定义。那里的置顶做的好像不是很好，相整理成体系有点难找：（

这下对了. http://sudoku.oubk.com/index.shtml也给出了各种方法的定义的.

我写了个暴力搜索程序,
去掉9!*72^2这个因子
程序在我的机器(Pentium IV, 2.0G)上每小时可以找到大概4*10^10个结果,所以估计3.7天可以完成穷举.
如果再做一些简单的优化工作,还可以提高3.3倍速度,不过这个意义不是很大了.

支持duz，我想验证是很有意义的。
可以考虑分块搜索，个人愿意贡献机时。（只能一小部分呦，呵呵。）

我现在有点担心程序有问题,不过直接看代码也查不出问题,其实速度不是问题. 程序main函数里面的循环里面的所有代码都可以完全并行计算的,所以如果我们有100台 机器,那么就可以将这100部分完全并行计算了. 比如你可以将循环改成 for(i=99;i<100;i++) 那么可以单单计算i==99时候的数目了. 现在我怀疑有问题是因为已经找出8.5*10^10个解了,i==0还没有计算完. 除非i==0时解特别多,不然就应该有问题了,因为平均来说,对于每个i,也就3.54*10^10个解. 现在将代码上传上来: Zh0xNDz8.zip (1.38 KB)

Zh0xNDz8.zip (1.38 KB)
数独算法
下载次数: 18

2006-3-15 11:54

[quote]以下是引用[I]duz[/I]在2006-3-15 12:00:52的发言：
我现在有点担心程序有问题,不过直接看代码也查不出问题,其实速度不是问题. 程序main函数里面的循环里面的所有代码都可以完全并行计算的,所以如果我们有100台 机器,那么就可以将这100部分完全并行计算了. 比如你可以将循环改成 for(i=99;i<100;i++) 那么可以单单计算i==99时候的数目了. 现在我怀疑有问题是因为已经找出8.5*10^10个解了,i==0还没有计算完. 除非i==0时解特别多,不然就应该有问题了,因为平均来说,对于每个i,也就3.54*10^10个解. 现在将代码上传上来: i9nkZ23d.zip (17.9 KB)

i9nkZ23d.zip (17.9 KB)
下载次数: 23

2006-3-15 13:14

[此贴子已经被作者于2006-3-15 13:14:44编辑过]

引用:

以下是引用[I]duz[/I]在2006-3-15 13:09:58的发言：[BR]]
找到程序的一个错误了,
函数sum里面的
long used2;
要改成
longlong used2;

这个在编译的时候可是一个警告错呀，呵呵。

引用:

以下是引用[I]zgglobeish[/I]在2006-3-15 13:15:12的发言：[BR]

这个在编译的时候可是一个警告错呀，呵呵。

这个不一定,同编译器有关系.我用的Linux+gcc, 这种情况编译器不报告警告的.