There is a huge disparity among top programs in the number of plies of quies which include non-capturing checks. I believe that SF only looks at 1 (PV) or 2(nonPV) plies (as currently does Komodo), while Rybka, Ippo, Critter, and Ivanhoe look at quite a few, I believe 5 (PV) or 7(nonPV) in the case of Ivanhoe if the score is not too bad. Presumably all of these authors have "checked" this out (sorry for pun) and have found that the numbers they use are best or at least near-optimal.
My question is this: what characteristics of the programs make it reasonable to look at so many plies of checks in the case of Rybka/Ippo etc. and unreasonable in the case of Stockfish and Komodo? Since Ivanhoe and Stockfish are open-source, perhaps I should limit the discussion to those two programs. What fundamental difference between Stockfish and Ivanhoe accounts for this enormous disparity in number of plies of checks?
checks in quies
Moderators: hgm, Rebel, chrisw
-
- Posts: 1334
- Joined: Sun Jul 17, 2011 11:14 am
Re: checks in quies
IvanHoe is quite a tactical engine - so I'd presume that to be able to evaluate long sequences of checks - potentially leading to a mate sequence - would give IvanHoe an advantage.
Stockfish is quite positional - and optimised for speed and <fruit> pure playing strength. </fruit> I'd presume that the low amount of checks is because the branching factor would shoot up dramatically.
I'll play around with this feature of FruitFly and see what it does.
Just my two pence. (I don't use cents)
Matthew:out
Stockfish is quite positional - and optimised for speed and <fruit> pure playing strength. </fruit> I'd presume that the low amount of checks is because the branching factor would shoot up dramatically.
I'll play around with this feature of FruitFly and see what it does.
Just my two pence. (I don't use cents)
Matthew:out
Some believe in the almighty dollar.
I believe in the almighty printf statement.
I believe in the almighty printf statement.
-
- Posts: 10307
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: checks in quies
I do not understand why do you consider stockfish to be positional engine.ZirconiumX wrote:IvanHoe is quite a tactical engine - so I'd presume that to be able to evaluate long sequences of checks - potentially leading to a mate sequence - would give IvanHoe an advantage.
Stockfish is quite positional - and optimised for speed and <fruit> pure playing strength. </fruit> I'd presume that the low amount of checks is because the branching factor would shoot up dramatically.
I'll play around with this feature of FruitFly and see what it does.
Just my two pence. (I don't use cents)
Matthew:out
Do you think that stockfish's relative advantage to IvanHoe is in the evaluation and not in the search?
-
- Posts: 10307
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: checks in quies
I do not know but I can guess that order of moves in the qsearch is important.lkaufman wrote:There is a huge disparity among top programs in the number of plies of quies which include non-capturing checks. I believe that SF only looks at 1 (PV) or 2(nonPV) plies (as currently does Komodo), while Rybka, Ippo, Critter, and Ivanhoe look at quite a few, I believe 5 (PV) or 7(nonPV) in the case of Ivanhoe if the score is not too bad. Presumably all of these authors have "checked" this out (sorry for pun) and have found that the numbers they use are best or at least near-optimal.
My question is this: what characteristics of the programs make it reasonable to look at so many plies of checks in the case of Rybka/Ippo etc. and unreasonable in the case of Stockfish and Komodo? Since Ivanhoe and Stockfish are open-source, perhaps I should limit the discussion to those two programs. What fundamental difference between Stockfish and Ivanhoe accounts for this enormous disparity in number of plies of checks?
If the order of moves in the qsearch is better in IvanHoe then it means that it can search more plies at smaller price.
Note that I did not look at the source code to compare order of moves in IvanHoe and Stockfish.
Edit:Another idea is that maybe stockfish does less pruning in the qsearch.
-
- Posts: 481
- Joined: Thu Apr 16, 2009 12:00 pm
- Location: Slovakia, EU
Re: checks in quies
I think you are wrong.lkaufman wrote:I believe 5 (PV) or 7(nonPV) in the case of Ivanhoe if the score is not too bad.
Old Ippolit did 4 plies in PV, 2 plies in nonPV.
Latest Ivanhoe (46h) does 7 plies in PV, 2 plies in nonPV.
PV (qsearch_pv.c line 191):
Code: Select all
if (depth >= -5 && POS0->Value >= ALPHA - (16 << (depth + 5)))
Non-PV (qsearch.c line 139):
Code: Select all
#if 1 /* discuss? */
if (depth >= -1 && POS0->Value >= VALUE - (100 + (12 << (depth + 4))))
#else
if (depth >= -4 && POS0->Value >= VALUE - (16 << (depth + 4)))
#endif
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: checks in quies
Yes, I missed that the "else" in non-pv was remarked out. I'm still a novice at reading code, but much better than three months ago since I now actually write simple code for Komodo.
Still, 7 moves in PV and 2 in non-PV vs. 2 in PV and 1 in non-PV is a huge difference. Can you comment on why Ivanhoe finds it worthwhile to do this while SF does not?
Still, 7 moves in PV and 2 in non-PV vs. 2 in PV and 1 in non-PV is a huge difference. Can you comment on why Ivanhoe finds it worthwhile to do this while SF does not?
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: checks in quies
The purpose of adding checks to the q-search is to cover up for tactical errors induced due to pruning near the tips. Null-move as one example, but also reductions and actual pruning. So you prune/reduce like crazy until you get to depth=0, then you make the q-search a little more accurate to try to cover up for some of the tactical issues such selectivity causes.lkaufman wrote:There is a huge disparity among top programs in the number of plies of quies which include non-capturing checks. I believe that SF only looks at 1 (PV) or 2(nonPV) plies (as currently does Komodo), while Rybka, Ippo, Critter, and Ivanhoe look at quite a few, I believe 5 (PV) or 7(nonPV) in the case of Ivanhoe if the score is not too bad. Presumably all of these authors have "checked" this out (sorry for pun) and have found that the numbers they use are best or at least near-optimal.
My question is this: what characteristics of the programs make it reasonable to look at so many plies of checks in the case of Rybka/Ippo etc. and unreasonable in the case of Stockfish and Komodo? Since Ivanhoe and Stockfish are open-source, perhaps I should limit the discussion to those two programs. What fundamental difference between Stockfish and Ivanhoe accounts for this enormous disparity in number of plies of checks?
I am not convinced 7 is EVER the right number however. The q-search is so full of errors, it makes no sense to add just checks and think that fixes everything. Most of the time a check is not the best move, so you just undo all that saving you created with the pruning...
We did 4 in Cray Blitz after some tuning. I've tried 4 in Crafty and found it to be weaker, but then I can test far more accurately today than back when we were working on CB...
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: checks in quies
I find this a most surprising comment. I simply don't see how adding checks in quies will help in any way to make up for missing a move before quies. Furthermore your answer suggests that programs that do no pruning at all cannot benefit from checks in quies, but I'm pretty sure that old full-width programs like the Spracklens' Fidelity programs did benefit from one ply of checks in quies.bob wrote:[
The purpose of adding checks to the q-search is to cover up for tactical errors induced due to pruning near the tips..
However, if you are right, this would explain the puzzle. The Ippo-related programs look at fewer moves on the last few ply than SF, so according to your theory they would offset this by more quies checks. But I just don't see how that would help.
-
- Posts: 481
- Joined: Thu Apr 16, 2009 12:00 pm
- Location: Slovakia, EU
Re: checks in quies
AFAIK Stockfish does 2 plies of checks in both PV and non-PV nodes.lkaufman wrote: Still, 7 moves in PV and 2 in non-PV vs. 2 in PV and 1 in non-PV is a huge difference. Can you comment on why Ivanhoe finds it worthwhile to do this while SF does not?
1) Non-pv nodes: programs don't really differ here
2) pv nodes: IMO it is not worthwhile what Ivanhoe does. I guess the intention was to compensate for doing LMR in pv nodes (original Ippolit did not).
And there are other things to consider. Whether QS nodes are hashed or not? Are there additional conditions besides depth? (is_check_dangerous() in Stockfish, eval being close to scout in Ivanhoe). Another important thing is how many evasion moves are considered (avoiding QS tree explosion).
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: checks in quies
You are a queen up but you cannot avoid a mate in two. Then, you nullmove and get away from the threat because you truncate the line that mates you (despite you give a move extra to the opponent). However, if you include at least checks in the first ply, you get mated even if you nullmove. Nullmove is an example of pruning.lkaufman wrote:I find this a most surprising comment. I simply don't see how adding checks in quies will help in any way to make up for missing a move before quies. Furthermore your answer suggests that programs that do no pruning at all cannot benefit from checks in quies, but I'm pretty sure that old full-width programs like the Spracklens' Fidelity programs did benefit from one ply of checks in quies.bob wrote:[
The purpose of adding checks to the q-search is to cover up for tactical errors induced due to pruning near the tips..
However, if you are right, this would explain the puzzle. The Ippo-related programs look at fewer moves on the last few ply than SF, so according to your theory they would offset this by more quies checks. But I just don't see how that would help.
Including checks at least in the first ply makes a better transition between the search and q-search.
Miguel