Author: Robert Hyatt
Date: 20:50:42 12/03/03
Go up one level in this thread
On December 03, 2003 at 20:42:57, Jeremiah Penery wrote: >On December 03, 2003 at 19:54:49, Robert Hyatt wrote: > >>On December 03, 2003 at 19:37:13, Jeremiah Penery wrote: >> >>>On December 03, 2003 at 16:22:27, Robert Hyatt wrote: >>> >>>>On December 03, 2003 at 15:54:45, Tord Romstad wrote: >>>> >>>>>On December 03, 2003 at 14:59:03, Robert Hyatt wrote: >>>>> >>>>>>=====================10 seconds per position======================== >>>>>>test results summary: >>>>>> >>>>>>total positions searched.......... 300 >>>>>>number right...................... 299 >>>>> >>>>>That's really impressive, even considering the fast hardware. The last >>>>>time I tried, I got 289/300 at 1 second/position, 293/300 at 3 seconds, >>>>>294/300 at 5 seconds, 295/300 at 10 seconds, and 298/300 at 20 seconds. >>>>> >>>>>The remaining two positions, number 100 and 230, are *never* solved. >>>>>I can let my program analyse for hours, but it still doesn't find >>>>>the solutions. In both positions, it thinks it is winning, but >>>>>never finds the right moves. >>>> >>>>I have gotten 230 in the past, but when I made some passed pawn changes of >>>>some sort, it went away. But even back then it took several minutes to choose >>>>the rook toss... >>> >>>If you compile with the #define DETECTDRAW it will find almost instantly that >>>any move other than Rb4 is a blocked position draw. :) >> >>Have you tried it already? I'll give it a whirl tonight when I get home.. >> >>Although the opteron seems to be down right now. They were installing a >>firewall, so I might be dead until tomorrow. > >Yes, I wrote that code, remember? :) Yes I remembered. :) I was specifically talking about it with respect to WAC 230. I remembered some results from some of those stupid positions with the pawn locked where one side offers a rook that should not be taken. :) I didn't know it also worked on wac 230. > This is one position that I initially used >for testing (among a great many blocked/near blocked positions) to verify that >it didn't mis-detect. It's possible that it still does occasionally, but the >benefit may outweigh that. The biggest cost is to search speed, but on a huge >majority of positions the code will have incredibly tiny impact (for instance, >if there is a knight on the board, the only cost is a single if statement). >Only on a very small class of positions will very much of the code be used, but >of course those will be the ones where the code is most helpful. :)
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.