Author: scott farrell
Date: 02:44:59 12/30/03
Go up one level in this thread
On December 30, 2003 at 05:26:42, Geoff wrote: >Hi Scott > >>yeh, I think you have a bug. >> >>firstly most people implement futility pruning _before_ makemove - you are >>basically trying to save the effort of make/unmake. You have to fiddle the score >>for captures a little, if you have SEE that is easy. > >Thanks for the help. I put the futility code in after the makemove to eliminate >the illegal moves that are filtered out by makemove(). It would be a problem if >I moved it earlier I think ? > >> secondly, you are pruning the wrong moves, given you have done makeMove, >> sideToMove has reversed, and you need to reverse a/b (-beta,-alpha), so you >> need to compare to -beta _not_ alpha, if you move the code to before >> makeMove you compare to alpha. I think you are throwing away beta nodes and > not alpha nodes. > >I was fairly convinced I was correct with using Alpha here but you might be >correct. I was thinking that alpha and beta swap when you call the search >function but not for just switching sidetomove in makemove(). > >I had a quick look at razoring in Beowolf, from what I can see it prunes after >makemove() but uses alpha like I did ? That would seem to suggest I was correct >initially ? I need to have a longer think about this one it is getting confusing >now ;-) > >Anyone with a casting vote ? Should it check alpha or beta here ? I am pretty sure that I am right. As soon as you make move, and change sideToMove, you need to swap a/b as well, your lazyEval probably knows what is going on, and you might get away with just -lazyEval()+margin<alpha. You have to swap something. The correct implementation is before makeMove - by popular opinion in a previous thread about a month ago, the main objective being saving the one makeMove() Scott > > Regards Geoff
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.