Author: Jaime Benito de Valle Ruiz
Date: 19:40:52 12/25/03
Go up one level in this thread
On December 25, 2003 at 06:29:31, rasjid chan wrote: >The QS as described in Ed's article seems a little strange. >There are crucial differences with the simple QS as in TSCP :- >1) simple QS automatiaclly fails high if evaluation score > (not lazy score) >= beta. >Rebel's sets certain conditions on fail high. >2) simple QS simply calls QS if score < beta >and sets alpha to score if greater >(Ed's article did not specify setting alpha). > the more controversial element - > Rebel's QS returns score ( or lazy score) if score <= alpha > >I have now fully implemented attack tables and am testing lazy >evaluation by first calling eval() at depth == 1. My current eval() >is a little elaborate compared to the raw eval() of TSCP. >If I stay strictly to simple QS it plays normally at about the level >of TSCP. The nps is about 60000 during middle game on a P4 1.4 GH, >1/3 that of TSCP. > >Any attempt to fail low as in 2) above makes it play very >badly.I wonder if anyone has a QS that fails low on score <= alpha >and yet has a workable QS. > >I am not sure if I interpreted anything again with gross silliness. > >Rasjid Rebel's page gives only hints on how the program is structured, not on how every function is implemented. Still, it's an extremely useful webpage full of invaluable ideas for programmers (thanks, ed!!!). Something that you've probably heard before, and will hear in the future is, "it might, or might not work your your engine, so... try it!". I personally listen to all ideas, and try lots of them whenever I can, but some of them don't work for me... and some of them, well... maybe I don't fully understand how they work, who knows? The fun of programming a chess engine lies precisely in this endless trial-and-error game that is adjusting and debugging your program. I think I've reached a stage where (except for some exceptions) the future strength of my program depends on my personal decisions, and other people's advices are only good if I make radical changes to my own program. Still it's worth discussing these things with other people. The Qsearch is a quite delicate point, if you ask me: Many "respectful" programmers will tell you that you only need to consider "good captures" and "winning captures", and ignore the rest. Others will tell you that you should include checks as well. That's the choice: A Qsearch can grow out of control if you're not careful. I'm still amazed by the Chessmaster, that considers checks in Qsearch (if I'm not mistaked), and still plays an amazingly strong consistant chess without analyzing a huge-uncontrolled tree. For positions where the king's safety it's at stake, this program has "NO MATCH" (it finds the devastating move in almost no time), but it's not so 100% reliable for other positions. It's with no doubt one of the strongest programs available, but maybe this "exhaustive Qsearch" reduces its search to the point that, statistically, it becomes a slower program against other machines; who knows? As I said before, try, and decide. Among all the tests I've done, the best statistical results are when I use a smart SEE, combined with a futile algorithms to prune "useless" captures. Check extensions make my program twice or even more slower... and make it weaker. But, as I said, it's only my experience. Jaime
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.