Author: Tim Foden
Date: 00:41:24 09/29/03
Go up one level in this thread
On September 29, 2003 at 03:13:13, Johan de Koning wrote: >On September 28, 2003 at 16:00:43, Tim Foden wrote: > >>On September 26, 2003 at 18:26:17, Johan de Koning wrote: > >>>1. d4? d5? 2.g4 wins (see the earlier d4d5 run) >>>1. d4? b5! draws (see D29) >>>1. c4 mate in 19 or 18 >>>1. b4 mate in 18 >>>Assuming no bugs of course. >>> >>>... Johan >> >>:) > >That wasn't intended to be funny! Shortly after my post I did discover a bug. >Similar to yours, in the "ancient" first optimization heuristic. >/**/ if( OppoReachedRank7() ) return -MATE(d + 2); >/**/ if( OnlyMeStalemate() ) return -MATE(d ); >The first if can return a score that should be treated as an upper bound until >the stale is resolved and possibly returned a worse score. Of course it won't >affect the outcome of the game, and of course the first line became redundant >after the more aggressive full passer heuristic. > >BTW, I also tried a-h mirroring in the TT (yes, including move and ep :-). >On d4d5 and 7-7 the difference was below noise level, as expected. >On the initial position the total time improved from 1.27 to 1 day, with the >node counts of course improving a few % more. > >Not very impressive. And that's because (I guess) mirrored positions are miles >apart in the search tree and don't live long enough in the always-replace fork >of the TT. The depth-preferred fork did a good job however: the occasionally >observed current lines never started with e,f,g,h. > >Anyway, I think I'll skip the experiment with fully normalized TT entries. >(That's with inactive files removed, and the remaining files flipped/sorted >into canonical form). That would be good for a complete retrograde analysis, >but it won't beat alpha-beta on a fixed starting position. As Uri pointed out, if there are any empty files, and all pawns in groups bounded by the edge of the board and any empty files can't move, then they could be treated as not being there any more, which could improve the gain from the fully normalised TT entries in a main search?? It may also be possible to apply some form of combinatorial approach once at least one empty file has appeared, which could speed things up quite a lot I'd think. >>Thanks for this. My secondary machine (Duron 800MHz) is now free from playing >>matches for a few days, so maybe I'll run mine on it for a couple of days and >>see if I get the same result. > >Since the search is magnitudes larger than the TT, the size of the TT is pretty >important here. (I'm not going into exact models and equations right now. :-) >If your Duron has lots of RAM it's worth a try. However if it has less than >your XP1666, my guess is that 3 Duron days won't beat 1 XP night. True :) But I have 384M of RAM in the Duron, and 512M in my main machine. I think I only used 192M hash on my main machine before, and that's what I'm using on the Duron now. That said, the Duron is still hasn't started 22 ply after about 9 hours. > >Anyway, have fun but don't forget to enjoy your real work. :-) :-) >... Johan > >PS: sorry for the long blah blah. >I just wanted to put my pending thoughts on record before forgetting them. :-) No problem. I find them interesting and informative. Cheers, Tim.
This page took 0 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.