checks in quies

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, bob, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
lkaufman
Posts: 4340
Joined: Sun Jan 10, 2010 5:15 am
Location: Maryland USA
Contact:

checks in quies

Post by lkaufman » Thu Mar 22, 2012 3:18 am

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?

ZirconiumX
Posts: 1327
Joined: Sun Jul 17, 2011 9:14 am

Re: checks in quies

Post by ZirconiumX » Thu Mar 22, 2012 7:14 am

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
Some believe in the almighty dollar.

I believe in the almighty printf statement.

Uri Blass
Posts: 8796
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: checks in quies

Post by Uri Blass » Thu Mar 22, 2012 9:52 am

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
I do not understand why do you consider stockfish to be positional engine.

Do you think that stockfish's relative advantage to IvanHoe is in the evaluation and not in the search?

Uri Blass
Posts: 8796
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: checks in quies

Post by Uri Blass » Thu Mar 22, 2012 9:56 am

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 do not know but I can guess that order of moves in the qsearch is important.
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.

User avatar
rvida
Posts: 481
Joined: Thu Apr 16, 2009 10:00 am
Location: Slovakia, EU

Re: checks in quies

Post by rvida » Thu Mar 22, 2012 2:27 pm

lkaufman wrote:I believe 5 (PV) or 7(nonPV) in the case of Ivanhoe if the score is not too bad.
I think you are wrong.

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 &#40;depth >= -5 && POS0->Value >= ALPHA - &#40;16 << &#40;depth + 5&#41;))
in this function the depth counts form 1 downwards. Checks are tried at depths 1,0,-1,-2,-3,-4,-5.

Non-PV (qsearch.c line 139):

Code: Select all

#if 1 /* discuss? */
  if &#40;depth >= -1 && POS0->Value >= VALUE - &#40;100 + &#40;12 << &#40;depth + 4&#41;)))
#else
  if &#40;depth >= -4 && POS0->Value >= VALUE - &#40;16 << &#40;depth + 4&#41;))
#endif
here the depth counts from 0 downwards, and note that only the first condition is active. Checks are tried only at depths 0 and -1.

lkaufman
Posts: 4340
Joined: Sun Jan 10, 2010 5:15 am
Location: Maryland USA
Contact:

Re: checks in quies

Post by lkaufman » Thu Mar 22, 2012 2:46 pm

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?

bob
Posts: 20918
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: checks in quies

Post by bob » Thu Mar 22, 2012 3:07 pm

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?
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.

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...

lkaufman
Posts: 4340
Joined: Sun Jan 10, 2010 5:15 am
Location: Maryland USA
Contact:

Re: checks in quies

Post by lkaufman » Thu Mar 22, 2012 3:39 pm

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..
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.
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.

User avatar
rvida
Posts: 481
Joined: Thu Apr 16, 2009 10:00 am
Location: Slovakia, EU

Re: checks in quies

Post by rvida » Thu Mar 22, 2012 4:00 pm

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?
AFAIK Stockfish does 2 plies of checks in both PV and non-PV nodes.

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).

User avatar
michiguel
Posts: 6401
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: checks in quies

Post by michiguel » Thu Mar 22, 2012 4:14 pm

lkaufman wrote:
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..
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.
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.
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.

Including checks at least in the first ply makes a better transition between the search and q-search.

Miguel

Post Reply