Author: Dann Corbit
Date: 21:31:19 10/25/05
Go up one level in this thread
On October 26, 2005 at 00:08:23, Uri Blass wrote:
>On October 25, 2005 at 23:31:08, Dann Corbit wrote:
>
>>On October 25, 2005 at 21:39:26, Will Singleton wrote:
>>
>>>On October 25, 2005 at 19:44:58, Dann Corbit wrote:
>>>
>>>>On October 25, 2005 at 14:56:43, Will Singleton wrote:
>>>>
>>>>>On October 25, 2005 at 12:56:43, Dann Corbit wrote:
>>>>>
>>>>>>On October 25, 2005 at 12:28:07, Lar Mader wrote:
>>>>>>
>>>>>>>I realize that this is a difficult question...
>>>>>>>
>>>>>>>I'm curious about what makes Fruit 2.2 so strong. Also, it is impressive how
>>>>>>>quickly Fabien achieved this strength. Fritz 9 and Shredder 9 seem to be close
>>>>>>>to Fruit 2.2 in strength, and yet they have been in development for a much
>>>>>>>longer time with a lot more resources. Has anyone spent any time examining the
>>>>>>>2.1 source code, or have any other insights into what this program does that
>>>>>>>makes it so effective?
>>>>>>
>>>>>>Fabien does everything well. He is a magnificent and careful programmer. He
>>>>>>obviously puts a lot of effort into making things correct. He has a lot of
>>>>>>insight to pick out what is important and concentrate on that.
>>>>>>
>>>>>>His search is excellent and innovative. He does some things that nobody else
>>>>>>does. I'm not really sure how he is able to not hash the PV and still have a
>>>>>>stupendously fast search, but that is pretty amazing.
>>>>>>
>>>>><snip>
>>>>>
>>>>>I haven't looked at Fruit's code, but I'm interested in your pv comment. What
>>>>>is the difference between storing the pv to hash, and simply playing the pv out
>>>>>of an array?
>>>>
>>>>What is more important in move ordering than being a pv node?
>>>
>>>Perhaps I wasn't clear. afaik, the purpose of storing the pv to hash is to
>>>enable the pv moves to be played first. Whether you store them to hash or to a
>>>special pv array shouldn't matter, if you recognize a node as a pv node and play
>>>the pv move.
>>>
>>>If we are in agreement on that (and perhaps I'm missing something), then are you
>>>saying that Fruit doesn't make use of its pv for move-ordering at all? I would
>>>find that unusual.
>>
>>http://chessprogramming.org/cccsearch/ccc.php?art_id=354644
>
>I only see
>No PV cut-off's in Fruit
>
>I do not see that he claims that he is not using the pv for move ordering.
Yes. I guess that he has pv nodes hashed as "normal" nodes or something like
that.
This is the code from Fruit 2.1's move ordering:
cut:
ASSERT(value_is_ok(best_value));
// move ordering
if (best_move != MoveNone) {
good_move(best_move,board,depth,height);
if (best_value >= beta && !move_is_tactical(best_move,board)) {
ASSERT(played_nb>0&&played[played_nb-1]==best_move);
for (i = 0; i < played_nb-1; i++) {
move = played[i];
ASSERT(move!=best_move);
history_bad(move,board);
}
history_good(best_move,board);
}
}
// transposition table
if (UseTrans && depth >= TransDepth) {
trans_move = best_move;
trans_depth = depth;
trans_min_value = (best_value > old_alpha) ?
value_to_trans(best_value,height) : -ValueInf;
trans_max_value = (best_value < beta) ?
value_to_trans(best_value,height) : +ValueInf;
trans_store(Trans,board->key,trans_move,trans_depth,trans_min_value,trans_max_value);
}
return best_value;
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.