Author: Heiner Marxen
Date: 19:10:10 12/25/01
Go up one level in this thread
On December 25, 2001 at 20:43:11, leonid wrote: >On December 25, 2001 at 12:51:34, Heiner Marxen wrote: > >>On December 24, 2001 at 19:46:41, leonid wrote: >> >>>On December 24, 2001 at 16:27:29, Heiner Marxen wrote: >> >>[big snip] >>>>Otherwise I did not note anything unusual in Chest's statistics. >>>>Name the missing info and I will try to provide it :-) >> >>Hello again! > >Hi! > > >>>I actually looked into all useful data of your program before even putting this >>>positions here. >> >>Oh, sorry. I'll remember that, now :-) > >Never mind! I actually looked only into branching factor and difference of speed >in initial plys. This is the most interesting and this is where I expect to try >to obtain some additional speed when finally I will come to this. For now I see >only two possibility in speeding: > >1) initial plys. > >2) usage of already found variables when switching for next depth. > >For now each time when program make search for indicated depth (even when before >it looked already into depth n-1) mine initialise all variables. Yes, I remember discussing that with you, already. Regarding ideas to speed up Chest: there are really many. Just some: - Move execution/undo could be done much faster. Moves could be coded more compact. - With only few pieces on board, an alternative coding could shrink my hash table entries to half, allowing for twice as many entries. - Detection of decisive defenses, like permanent check, or an imprisoned white king in a blocked pawn endgame. - Better defender strategies by using a kind of "eval()" like in normal playing programs - When a searched defender move fails (white did find a mate), the next defender move to search should try to not allow the exact same combination. - Force winning of the attackers last piece, like in: [D]k6r/8/8/1Q6/8/1K6/4n3/8 b - - Rb8 or Nd4+ both win the white queen, after which white cannot win any more, independant of the remaining depth. This can be detected statically (without search) with Chest's board data. Therefore defender moves like Nc1+ or Rh3+ are inferior and are to be avoided. You see, there is more to it than just tuning the last plies. There are even much fancier ideas... but I'll stop here for now. >In general, I think that our both programs could be still speeded in around 5 or >10 times. Ten times for 10 moves search. 10-fold? Well, I think it is possible, but not easily. That would be a lot of really hard work. Not really possible for an amateur, except perhaps he is very dedicated to chess programming. I for one have other interests, too. > Problem right now for you and me is >that we are, probably, not that much motivated to enter once again into deep >code rewriting. Not that much demand for mates solvers, also we both stay too >far away from almost every solver ever done. Yes, that is certainly true. Competition as well as an applauding and demanding user base is very stimulating. :-) >>> Was very surprise in finding that time of search for 5 moves was >>>less that time for 4 moves. Your time for 4 moves was 0.11 sec and for 5 only >>>0.05 sec. >> >>Oops? >>Were that timing info lines from one invocation/run, or resulting times >>from different invocations? The former would be strange, the latter is ok, >>since with so small times it may just be random inaccuracy noise. >>Or is that repeatable? > >For this position I asked your program to see only once. In other positions I >saw something like this, probably, one or two times. It is rare. Still it could >be correct. In around 15% of positions, when mate really exist, mate in N moves >deep take less time that mate N-1 moves. For Chest this cannot be (logically) correct. The first thing a mate-in-N does, is to compute the mate-in-(N-1). So the former cannot be faster. That must be a timing problem/inaccuracy. Do I miss something important? Cheers, Heiner
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.