Author: Fabien Letouzey
Date: 06:15:45 06/15/04
Go up one level in this thread
Hi Steve, > In this position on my 2 GHz P4 Fruit 1.0 searches to 14 ply in 18 secs and > finds the solution much sooner. Monarch 1.0 is at least one ply behind at 18 > secs and I've noticed this to be the case4 in many positions. If I may ask - > what's the secret of Fruit's ability to search deeply? Can you give us some > clues? What part of the search are you most proud of? Fruit 1.0 uses R=3 null move and extends only check evasions. Is there any need to look further? Fruit 1.5 extends all checks and single replies, following an advice from Joachim Rang (Fruit has no king safety). > Having looked at the source code you seem to be doing the following: > 1) Check at the first ply - nothing new there I first enabled that just after null moves, then I decided to enable it everywhere (without testing). > 2) Your implementation of ETC seems somewhat different. You actually make the > move (as opposed to calulate the new hash value). And then call full_leaf - > what does this do - it seems to check for leaf status otherwise return nothing? > What's the thinking here? Does Fruit get much of an Branching Factor > improvement with ETC? The implementation is as naive as I could manage, play each move on the board and try to obtain a fail low in the resulting position without playing any further move (not just with transposition cutoffs). Because it was slow I enabled ETC only for depth >= 4. More recently I tried ETC the normal way (you can see the additional functions in Fruit 1.5's source code) but the speed improvement was lower than I expected (even when using depth >= 3) and it missed some more cuts (not transposition-table related). I will test this further later but for now I kept my old code. > 3) In the Null move verification Full_Simple is called which seems to force > moves to be played i.e. no early cut-offs i.e. the opposite of Full_Simple. The point was that these had already been tested before reaching the null-move code. Also I can't call the main recursive search function from that place because it would try null move again ... I should remove that mostly-redundant function and use an extra flag parameter instead I suppose. > 4) For move ordering it looks as if Fruit has toyed with the idea of performing > a QSearch to get the best move. This seems to be disabled in Fruit 1.0 and > instead you rely on MVA/LVA and not SEE - was SEE worse for this? Move ordering has not been tested seriously. Using SEE for move ordering in the main search is now one of my priorities. > 5) Fruit seems to cut losing captures in the QSearch using SEE Yes. > So what part of Fruit 1.0, in your opinion, is contributing to such a good > branching factor? Nothing in particular I suppose. Apart from the already-mentionned choices, 4-probe hash table probably adds its own little bit ... Fabien.
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.