Author: Fermin Serrano
Date: 00:43:26 06/05/03
Go up one level in this thread
On June 05, 2003 at 03:28:29, Fermin Serrano wrote:
>On June 04, 2003 at 13:13:50, Robert Hyatt wrote:
>
>>On June 04, 2003 at 07:19:20, Fermin Serrano wrote:
>>
>>>I have hadache in how to avoid so many nodes spended in quiescent search.
>>>
>>>I have a new idea that came to my mind “on the fly”, and before test something I
>>>want to know other opinions and if this could be saccessful. I have not a clear
>>>concept yet, but I want to experiment samething. In qsearch, SEE is expensive,
>>>but save time in search. I was thinking that when you use other method like
>>>MVA/LVD is faster but lot of nodes are evaluated. What about if when you enter a
>>>position in qsearch with this method and in ply x+3 where x>3 of quiescent
>>>before contining, test if last 3 captures were in the same square, and if not,
>>>then you could safe return a negative score (maybe -INFINITE) because there is a
>>>big probability that move secuence would finished in a waste of time.
>>>Maybe playing with this number (3, 4 or 5 plays after enter qsearch) could bring
>>>good results.
>>>What I have in mind is playing with last square where capture was, because most
>>>time captures are solved there, of course not always, but maybe the time wasted
>>>in go around all other moves is better used in depth+1.
>>>
>>>What are you opinions?
>>
>>
>>There are several ways you can shrink the q-search.
>>
>>1. If the current alpha (lower bound) value is (say) 0, and the current
>>material score is -5 (you are a rook down in the current path) then you can
>>cull captures where you only capture a pawn, since that will still leave you
>>down -4. I do this kind of thing in Crafty with a little more refinement. I
>>have a good idea of how big the positional score can get, so if the current
>>material + the captured piece + the largest positional score is < alpha, I
>>don't bother searching since the score can't get above alpha anyway.
>>
>>2. If you are looking at a move like pxq there is no need to use SEE. pxq
>>wins material no matter _what_ happens, so for obvious captures like that you
>>can avoid any SEE computation since the captured-capturing score is still way
>>positive.
>>
>>There are other tricks as well, of course. And as you go deeper into the
>>q-search, you can afford to be more aggressive since there is already
>>_plenty_ of error in the q-search anyway.
>
>Thx. for you reply. Very instructive. The problem is that I was thinking in
>MVV/LVA context, not a SEE implementation. I tried some SEE implementations
>taking adventage of a attack table I have, but they ware very expensive and slow
>my engine a lot, maybe because I have a mailbox generator with attack tables.
>Yesterday I tried somethink about your advice, like this in my MVV/LVA
>implementation:
>if (value[pieze[move->origen]] < value[pieza[move->destino]] &&
> !check ) {
> move-sort_value = -INFINITY;
>}
>
>I were surprised that it increment nps and decrement in 2 seconds a three
>positions epd for 6 plies, and if I replace move->sort_value=-INFINITY with
>'continue;', the performance decrease a lot.
>Any way.... have the first idea I posted some sense in a MVV/LVA context?
>Thx in advance. Best regards.
uppsss.... where I put :
>if (value[pieze[move->origen]] < value[pieza[move->destino]] &&
> !check ) {
> move-sort_value = -INFINITY;
>}
I wanted to say:
if (value[pieze[move->origen]] < value[pieza[move->destino]] &&
!check && move->destino!=move_before_this->destino ) {
move-sort_value = -INFINITY;
}
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.