Author: Andrew Dados
Date: 23:23:13 08/10/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 Case described by Bob is one of the reasons unnecessary underpromotions happen. However I've seen many 'stupid' underpromotions when neither rook or queen checked and still program underpromoted. I think it's partly due to search score being function of alpha given to it (cutoffs, pruning, etc all depend on alpha (beta)). So a8=Q has different alpha then following it a8=R. So far I didn't see any discussion on that - Try searching any 'quiet' position with <-inf,+inf> to fixed depth and then search it with small window around returned score (with/without hashtables). It shows up that each engine for many positions has it's 'resolution': score dependancy upon alpha/beta. (see famous fail high followed by high low on research for example). -Andrew- btw.. I long time use that trick you described and don't search underpromotions is fail low was caused by capturing promoted queen (not at root though).
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.