明白怎么回事了
上面代码不能处理P31
偶太笨啦
#define P31 0x7FFFFFFF
__declspec(naked)
DWORD __fastcallmodAdd(DWORD a, DWORD b)
{
__asm
{
add ecx, edx
mov eax, ecx
sub ecx, P31
cmovnc eax, ecx
ret
}
}
__declspec(naked)
DWORD __fastcallmodSub(DWORD a, DWORD b)
{
__asm
{
mov eax, P31
sub eax, edx
add eax, ecx
mov ecx, eax
sub ecx, P31
cmovnc eax, ecx
ret
}
}
__declspec(naked)
DWORD __fastcallmodMul(DWORD a, DWORD b)
{
__asm
{
mov eax, ecx
mul edx
shld edx, eax, 1
and eax, P31
add eax, edx
mov ecx, eax
sub ecx, P31
cmovnc eax, ecx
ret
}
}
这次应该OK了吧
Linux下面到现在找到8个结果了（共处理了约3072个文件），都在
http://bbs.emath.ac.cn/viewthread.php?tid=703&page=33&fromuid=20#pid16447
不过程序还有bug,麻烦的是windows下的程序遇到异常以后，自动被VC捕获，程序就不运行了。看来需要将异常全部阻止才可以。
呵呵
还是要调试吧
呵呵，等什么时候有空闲时再看看。
我想改你的srap
让能自动判定是否解决了当前文件
然后用wrap <start> <end>连续运算
比较好的方法是在程序finder和sfilter的main函数里面加入这样的结果
try{
//all original code comes here
}catch(...){
printf("error!!!!");
}
现在我在windows下运行的机器也总算开始出一个解了，大部分还是Linux机器找到的，还找到一个18棵树18行的结果。
解真是稀少呀。输入数据是71个数据一个文件。现在估计至少500个以上文件才出一个解,估计总共也就几百个解:lol 。然后还需要用它们来构造19棵树和20棵树的解。
呵呵
假设有1000个结果
构造19，20的树，会有多少计算时间？
如果能够将这1000个结果的坐标都求出来，那余下的应该很快。
不过估计这个方法不大行，毕竟现在求坐标我通常都是通过maxima软件辅助来做的。
所以应该还可以采用类似现在的方法去做。
1000个数据也就相当于现在十几个文件的数据量。即使那个时候产生解的比例要稍微高一些（我估计会如此，要不然解的数目太少了），哪也应该是很快的事。
所以现在这一步是主要的瓶颈