Author: Roberto Waldteufel
Date: 07:10:34 04/08/99
Go up one level in this thread
On April 08, 1999 at 09:00:22, Christophe Theron wrote: >On April 07, 1999 at 23:03:07, Roberto Waldteufel wrote: > > >>>>Wow! Tic-Tac-Toe to chess is quite a leap. >>> >>>Yeah... Imagine: from tic-tac-toe in Basic to chess in assembly! >> >>One of the nice things about my compiler (PowerBasic) is that you can freely mix >>(compiled) Basic with 32-bit assembler, including the full set of Pentium 32-bit >>instructions, all the Math coprocessor instructions and MMX instructons being >>supported as well. I find this a very pleasant tool, and in fact my most >>speed-critical code is all written in assembler within the framework of the >>Basic programming language. I never did get to grops with the ubiquitous C. > >All my speed critical code is written in C (like the rest of my program) so I >never have to program assembly code! :) > >However I sometimes take a look at what's generated, just to be sure the >compiler didn't get mad about it. > > > >>>So you do full width until QSearch? >>> >>Yes. Also Qsearch is full width but variable depth. Remember that in checkers, >>unlike chess, if you can capture then the rules insist that you *must* capture, >>so a capture-based Qsearch is necessarily full width because if any captures are >>possible, then there cannot be any legal non-capture moves. I just extend the >>search as long as there are legal captures, or as long as there is the threat of >>a capture by the other side. This latter point took a while to for me to >>realise, but it improved the quality of play quite noticeably. > >Isn't it because of the possibility of zugzwang positions everywhere, as you >stated before? In chess, we assume that in QSearch the side to move can simply >"stand pat". But here again we ignore the zugzwang problem (in other words, >everybody uses a kind of virtual "null move" in QSearch). Maybe it is the reason >why in checkers just "standing pat" in QSearch is worse...? > >In this case I don't understand why you continue the search only if there is the >threat of a capture by the other side only. Shouldn't you continue if there is >the threat of a capture, whatever side is to move? Maybe it's a performance >issue? > > > > Christophe In chess the side to move can stand pat even though there are captures available, since the ability to capture does not compel a capture to actually be made, but in checkers this is not allowed: if there is one (or more) capture available, then the side to move *must* make a capture, so standing pat is not an option. Originally I stopped the Qsearch as soon as the side to move had no captures, but I found that this led to errors if the other side was threatening a capture that could not be prevented, so now I continue the Qsearch in these cases as well, that is as long as either side has captures pending the search continues (full width). This does not add too much overhead, and the results are much more stable than before when I only extended if the side to move had captures pending without considering the other side's threats. Usually in cases where the other side threatens a capture but the side to move has no captures, the side to move can meet the threat with at least one of its available (non-capture) moves, but in cases where nothing can escape from the threat, the Qsearch now scores the position accordingly. Another point is that when captures are available, the choice of moves is extremely limited (often only one legal capture), so such extensions are much less expensive than they would be in chess. Best wishes, Roberto
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.