Author: Sune Fischer
Date: 05:10:33 08/24/03
Go up one level in this thread
On August 24, 2003 at 07:53:07, Omid David Tabibi wrote: >> >>Hmm you have not understood completely how the table works I think. > >I have understood that the tables don't work in such cases :) I tried a few different table designs, I decided on this one because it was the fastest to use for incremental updates. Other tables might have other advantages, but then again they could also be more expensive not storing the needed information to incrementally update themselves. The idea is that if you move e.g. a pawn, and nothing attacks that pawn, then you are done. A maximum of 4 bits needs xoring and you have your full table ready for next node. I think I underestimated how slow it would be in the endgame though. >>As Uri also did point out, a table lookup for SEE doesn't work with this ploy. >> >>I'm not sure such a table can even be constructed, one could compute the number >>of bits theoreticly required by a crafty type SEE. >>I suspect such a table would be huge. >> >>>>I also don't fully agree that qsearch is all about inaccuracies, think about it, >>>>all branches terminate in a qsearch, so everything sent down the tree must be >>>>garbage....? >>> >>>Until a while ago at least, Junior did not have any quiescence search at all... >> >>I think quiescence is too broad a term to say it didn't, every program faces a >>quiescence problem at the leaves, so it must have done something. > >Static SEE analysis at depth = 0 nodes... Oh, well that might be doable. On the other hand if you are going to spend thusands of hours on an evaluation function, it would be pretty silly to get the primitive capture swapoffs wrong. -S.
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.