Author: Fermin Serrano
Date: 00:28:29 06/05/03
Go up one level in this thread
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.
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.