hgm wrote:I always use a very generous space per ply on my move stack. Large holes in the stack hardy hurt, because memory that is not used is also not cached. Address space is not a very scarce commodity.
I agree, but you have to be careful not to extend the address space you use too much, or you'll start having TLB issues. (It's a general remark not one that necessarily applies to your example )
Arpad Rusz wrote: The max. number of captures for one side in a legal position (T.Marlow, W.Cross, 1967)
[D]r1n1n1b1/1P1P1P1P/1N1N1N2/2RnQrRq/2pKp3/3BNQbQ/k7/4Bq2 w - - 0 1
(74 white captures)
This position is interesting because is able to blow up your qsearch() !
Try it on your favorite engine
This is clearly a problem of stockfish that suggest bad order of moves.
I also wonder what is the first move that stockfish searchs in this position
I think that bxa8=Q+ that also force mate in 4 moves is the most logical move to search first because it wins more material than other moves in one ply but unfortunately I see no analysis by stockfish after some minutes so I cannot see the first move that stockfish considers but if bxa8=Q is the first move that stockfish considers I see no reason that it needs a lot of time to finish depth 1 because other captures can be pruned because they win less material after one ply.
Arpad Rusz wrote: The max. number of captures for one side in a legal position (T.Marlow, W.Cross, 1967)
[D]r1n1n1b1/1P1P1P1P/1N1N1N2/2RnQrRq/2pKp3/3BNQbQ/k7/4Bq2 w - - 0 1
(74 white captures)
This position is interesting because is able to blow up your qsearch() !
Try it on your favorite engine
I use a "recaptures only" method in my qsearch once the qsearch reaches its 5th ply. So Myrddin has no problem with this and announces mate in 4 in about one second.
Uri Blass wrote: This is clearly a problem of stockfish that suggest bad order of moves.
You really never test the statements you write, doesn't you ?
It is amazing how much self-confident (and of course wrong, but this is a direct consequence) you are. Even Bob is less blindly sure of what he writes than you. It is true that sometime he indulges in absolute statements but more often then not he tries to prove them in parallel with some sort of testing....this does not seem to happen to you
BTW I have tested your statement and now SF tries the move you suggest and anyhow it locks in that position. I needed to do a little change in the scoring of captures in movepicker.cpp as following:
// Use MVV/LVA ordering
for (MoveStack* cur = moves; cur != lastMove; cur++)
{
m = cur->move;
cur->score = pos.midgame_value_of_piece_on(move_to(m))
- pos.type_of_piece_on(move_from(m));
if (move_is_promotion(m))
cur->score += QueenValueMidgame;
}
JVMerlino wrote: I use a "recaptures only" method in my qsearch once the qsearch reaches its 5th ply.
You mean that starting from the 5th ply you use just the SEE score ?
No, only recaptures are allowed at that level, i.e. the move selection is narrowed. SEE is too blind to pins etc. I do the same thing in Gaviota from the 6th ply on.
That helps in many of these type positions, but there are many other things to take into account. For instance, a mate-in-one move could be selected first.
Arpad Rusz wrote: The max. number of captures for one side in a legal position (T.Marlow, W.Cross, 1967)
[D]r1n1n1b1/1P1P1P1P/1N1N1N2/2RnQrRq/2pKp3/3BNQbQ/k7/4Bq2 w - - 0 1
(74 white captures)
This position is interesting because is able to blow up your qsearch() !
Try it on your favorite engine
Wow, I did and it crashed Pred because my movelist can only contain 100 moves. I extended it to 200 moves and Pred found the mate in 30s. Not fast, but at least that's the only move it considers
Also, there is an half-move missing in the line... *sigh*
I plan to change all my remaining fixed arrays to dynamical ones.
JVMerlino wrote: I use a "recaptures only" method in my qsearch once the qsearch reaches its 5th ply.
You mean that starting from the 5th ply you use just the SEE score ?
No, only recaptures are allowed at that level, i.e. the move selection is narrowed. SEE is too blind to pins etc. I do the same thing in Gaviota from the 6th ply on.
That helps in many of these type positions, but there are many other things to take into account. For instance, a mate-in-one move could be selected first.
Miguel
Precisely. Only moves that capture on the target square of the previous move are considered.
If I turn this feature off, it takes 10x longer to announce mate. If I adjust to 6 plies like Miguel, it takes 3x longer.
Uri Blass wrote: This is clearly a problem of stockfish that suggest bad order of moves.
You really never test the statements you write, doesn't you ?
It is amazing how much self-confident (and of course wrong, but this is a direct consequence) you are. Even Bob is less blindly sure of what he writes than you. It is true that sometime he indulges in absolute statements but more often then not he tries to prove them in parallel with some sort of testing....this does not seem to happen to you
BTW I have tested your statement and now SF tries the move you suggest and anyhow it locks in that position. I needed to do a little change in the scoring of captures in movepicker.cpp as following:
// Use MVV/LVA ordering
for (MoveStack* cur = moves; cur != lastMove; cur++)
{
m = cur->move;
cur->score = pos.midgame_value_of_piece_on(move_to(m))
- pos.type_of_piece_on(move_from(m));
if (move_is_promotion(m))
cur->score += QueenValueMidgame;
}
I have no time to test changes in stockfish.
It does not mean that I am wrong because I did not claim something wrong.
My claim was:
"This is clearly a problem of stockfish that suggest bad order of moves."
The facts based on your post are that stockfish did not search the best move first so my guess was correct(and maybe the change that you did already made stockfish 1 elo stronger).
I understand that a bad order at the root is not the only reason that stockfish locks in that position but it does not mean that I was wrong in my claim.
Maybe I was wrong in replying you and in the future it is better if I do not reply people who treat me in the way that you did.