LVA MVV with relative Pin
Posted: Wed Feb 16, 2011 6:36 pm
First off, most of the time this LVA MVV method of ordering my capture
moves for Alphabeta works fine, because captures like B x R are usually
good moves.
But only recently my program (WHITE) had this position to play (FEN):
1r1qr1k1/5pbp/3p2p1/1B3b2/3PnN2/1QN5/PP3PPP/3R1K1R w - - 0 19
It needed 50 Seconds to find a somewhat 'playable' move (from my
engine's limited 8-ply point of view: Nfd5 - but strong engines can refute this) - which is a lot longer than usual.
Of course I'd like to know what makes this position so complicated (not
only for my program, also very strong and fast 5000-nps engines like
Stockfish, Houdini, Rybka or Deep Pharaon seem to have a hard time
with doing their 'usual' 20+ - ply searches. In addition to this they
can't tell me, whether White or Black is better, some say it's +0.70
from White's point of view, others say the opposite -0.70 etc. ...
Objectively ... well, I'm not an expert player (1800 rating), but
I'd say Black doesn't have enough compensation for the two lost
pawns ...)
Atm these are my three theories, why finding a best move
(or at least a reasonable score) for this position is so hard for the
programs (especially my own):
(1) 46 legal root moves. Maybe that's just too much and thus the tree
explodes automatically (?), no matter how I order the moves ?
(2) MVV LVA doesn't work properly here.
That B x R capture is likely to appear in thousands,
maybe millions of child nodes, as one of the first moves White will try,
thus instead of searching the best move first one of the worst moves
is searched first. And maybe that's the reason why the search takes so
long (?)
But what could be a workaround for this situation, when this
MVV LVA heuristic (which works so well most of the time) suddenly
performs worse than choosing the moves in random order ?
Are cases like this maybe worth the effort to keep incremental data
only for 'relative pins' (? Atm I do this only for 'real' pins) ?
(3) Maybe the position is so dynamic, that most hashmoves,
which are found from shallower iterations, will rarely be the best moves
at the subsequent iterations, and thus the whole node
(with the hashmove which didn't do the expected beta cutoff)
needs to be searched again ?
I'm generally wondering what can be done against this issue:
'Hashmove from previous iteration does not as many beta-cutoffs
as expected.'
Which of my amateurish theories is most likely the correct reason ?
This could help me a lot if only I knew at which parts of my program
I'll need to battle this issue. (Of course I'd like to keep on ordering
my moves with LVV MVA, because in most cases it helps a lot, ... except
here ...)
Thanks in advance for ANY tipps.
moves for Alphabeta works fine, because captures like B x R are usually
good moves.
But only recently my program (WHITE) had this position to play (FEN):
1r1qr1k1/5pbp/3p2p1/1B3b2/3PnN2/1QN5/PP3PPP/3R1K1R w - - 0 19
It needed 50 Seconds to find a somewhat 'playable' move (from my
engine's limited 8-ply point of view: Nfd5 - but strong engines can refute this) - which is a lot longer than usual.
Of course I'd like to know what makes this position so complicated (not
only for my program, also very strong and fast 5000-nps engines like
Stockfish, Houdini, Rybka or Deep Pharaon seem to have a hard time
with doing their 'usual' 20+ - ply searches. In addition to this they
can't tell me, whether White or Black is better, some say it's +0.70
from White's point of view, others say the opposite -0.70 etc. ...
Objectively ... well, I'm not an expert player (1800 rating), but
I'd say Black doesn't have enough compensation for the two lost
pawns ...)
Atm these are my three theories, why finding a best move
(or at least a reasonable score) for this position is so hard for the
programs (especially my own):
(1) 46 legal root moves. Maybe that's just too much and thus the tree
explodes automatically (?), no matter how I order the moves ?
(2) MVV LVA doesn't work properly here.
That B x R capture is likely to appear in thousands,
maybe millions of child nodes, as one of the first moves White will try,
thus instead of searching the best move first one of the worst moves
is searched first. And maybe that's the reason why the search takes so
long (?)
But what could be a workaround for this situation, when this
MVV LVA heuristic (which works so well most of the time) suddenly
performs worse than choosing the moves in random order ?
Are cases like this maybe worth the effort to keep incremental data
only for 'relative pins' (? Atm I do this only for 'real' pins) ?
(3) Maybe the position is so dynamic, that most hashmoves,
which are found from shallower iterations, will rarely be the best moves
at the subsequent iterations, and thus the whole node
(with the hashmove which didn't do the expected beta cutoff)
needs to be searched again ?
I'm generally wondering what can be done against this issue:
'Hashmove from previous iteration does not as many beta-cutoffs
as expected.'
Which of my amateurish theories is most likely the correct reason ?
This could help me a lot if only I knew at which parts of my program
I'll need to battle this issue. (Of course I'd like to keep on ordering
my moves with LVV MVA, because in most cases it helps a lot, ... except
here ...)
Thanks in advance for ANY tipps.