Author: Robert Hyatt
Date: 07:01:44 08/11/99
Go up one level in this thread
On August 11, 1999 at 01:53:35, blass uri wrote: >On August 11, 1999 at 00:24:08, Robert Hyatt wrote: > >>On August 10, 1999 at 22:03:27, Andrew Dados wrote: >> >>>On August 10, 1999 at 21:35:12, Robert Hyatt wrote: >>> >>>>On August 10, 1999 at 19:56:10, Marc Plum wrote: >>>> >>>>>A while back I ran some multiple engine tournaments within the Nimzo99 >>>>>interface. One thing that I noticed was that some programs would make >>>>>meaningless underpromotions. That is, in a position where a promoted pawn would >>>>>be immediately exchanged anyway, the computer might promote to a bishop or rook >>>>>rather than a queen. I had occasionally encountered the same thing in my own >>>>>games with computers; I also found a small number of computer games like this >>>>>when doing a database search for underpromotions. I don't have any statistics >>>>>to present; I'm just noting that this happens not infrequently. >>>>> >>>>>When a human player does this, he is probably just being whimsical, or it could >>>>>be a psychological ploy. I wonder, though, why a computer would do it. Is it >>>>>just a random thing? Does the computer reason that losing a bishop is less bad >>>>>than losing a queen, even though the resulting position is the same? Or do >>>>>computers like messing with people's minds too? >>>>> >>>>>Marc Plum >>>> >>>>Actually at times there is a valid reason. If (say) d8=Q is a check, and d8=R >>>>is not, then the program can choose whichever one maximizes the evaluation. How >>>>could they be different? Remember that one is a check and will extend the >>>>search while the other is not. So if searching one extra ply discovers >>>>something interesting, then =Q will get played. If searching one extra ply >>>>discovers something bad, then we avoid seeing the 'bad' by playing =R. >>>> >>>>Cute, eh? :) >>> >>> However there are cases when underpromotions are *totally* meaningless and >>>still made by some programs. While hashtable should prevent re-searching >>>a8=N Bxa8 because there should be score for a8=Q Bxa8, it looks like either hash >>>entry can get overwritten or some programs don't calculate exact same signatures >>>in those 2 lines. Or else? (Note that hashtable hit returns 'true' score, >>>because a8=Q was searched full-width to become PV. It can be that some programs >>>don't store 'true score' in hash so researching with 'new' bounds may produce >>>new score). >>> >>>-Andrew- >> >> >>Don't forget the 'check'. If you try a non-checking promotion first, and put >>the entry in the hash table, then search the checking move, the hash entry will >>be useless, because it will be one ply 'short' of the depth required since the >>check incs the depth. > >What is the problem to tell your program to search the promotion to queen before >searching underpromotions >and to tell it that if the right move against promotion to queen is taking the >queen then not to analyze underpromotions? > >Uri Crafty _always_ searches the =Q case first, but then it uses normal move ordering things later on, which means that =R might be better because of stalemates or whatever, and that can get remembered as the best move in this position and be searched first the next time around... I have tried special code to make it only play =Q at the root unless an underpromotion is the best thing to do...
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.