pv in qsearch

Discussion of chess software programming and technical issues.

Moderator: Ras

User avatar
stevemulligan
Posts: 117
Joined: Wed Jul 20, 2011 2:54 pm
Location: Ottawa, Canada

pv in qsearch

Post by stevemulligan »

I'm experiencing difficulty getting a full PV in qsearch because of Standing Pat. From what I've read this is normal and StandPat avoids helps qsearch settle down much faster.

If I remove Standing Pat from my qsearch is it going to cause major problems? I can get the full PV without it, and I really like seeing the full list of moves that were examined. How much slower is qsearch going to be without standing pat?
Aleks Peshkov
Posts: 974
Joined: Sun Nov 19, 2006 9:16 pm
Location: Russia
Full name: Aleks Peshkov

Re: pv in qsearch

Post by Aleks Peshkov »

Chess is not checkers, without stand pad Qsearch has no sense.
User avatar
stevemulligan
Posts: 117
Joined: Wed Jul 20, 2011 2:54 pm
Location: Ottawa, Canada

Re: pv in qsearch

Post by stevemulligan »

I don't understand what you mean. It still avoids the horizon effect if I search all captures until there are none left.

It seems a lot slower without standing pat, just wondering if its going to be like 100 times slower or 2x...

Is there another way to get the full PV? A score without a PV makes no sense to me, especially since I'm starting to work on my eval
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: pv in qsearch

Post by Evert »

stevemulligan wrote:I don't understand what you mean. It still avoids the horizon effect if I search all captures until there are none left.
In chess captures are not compulsory, unlike checkers. Therefore it makes no sense to force bad captures in qsearch to reach a "quiet" position. The position is already quiet when there are no good captures.
Stand pat in qsearch is perfectly safe, but there are of course different ways to implement it. I think the most common is to take an immediate cutoff if the stand pat (or null move) fails high, but you can still search all captures and only accept the stand pat score if they all fail low. That'll be slower though and probably costs more than it gives.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: pv in qsearch

Post by Evert »

stevemulligan wrote:I'm experiencing difficulty getting a full PV in qsearch because of Standing Pat. From what I've read this is normal and StandPat avoids helps qsearch settle down much faster.
How is it causing a problem?
The PV should terminate on the last ply where there was a good capture, so with the stand pat (null move). Do you expect something else? Or is it doing something else?
User avatar
stevemulligan
Posts: 117
Joined: Wed Jul 20, 2011 2:54 pm
Location: Ottawa, Canada

Re: pv in qsearch

Post by stevemulligan »

Evert wrote: How is it causing a problem?
The PV should terminate on the last ply where there was a good capture, so with the stand pat (null move). Do you expect something else? Or is it doing something else?
Most of the time I see a lot more valid moves compared to captures, so I figured it wouldn't be that bad. 18 black moves, 2 black captures.. I guess since the eval is called at each ply in qsearch it gets really really slow without standing pat.

It's a problem for me on WAC.002

8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - -

On the 2nd ply I know my engine takes this line: c4c3 b2c3 (b3c3) (d2d3) (c3d3) (moves in brackets are qsearch moves)

When I stand pat I get c4c3 b2c3 (b3c3) because there are never any alpha cuts on the last two moves and that's how I generate my PV.

The stand pat code is called near top of qsearch after board eval (my engine is based on the tutorial on chessbin.com)

Code: Select all

if (examineBoard.Score >= beta)
   return examineBoard.Score;

if (examineBoard.Score > alpha)
   alpha = examineBoard.Score;
User avatar
hgm
Posts: 28440
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: pv in qsearch

Post by hgm »

stevemulligan wrote:I don't understand what you mean. It still avoids the horizon effect if I search all captures until there are none left.

It seems a lot slower without standing pat, just wondering if its going to be like 100 times slower or 2x...

Is there another way to get the full PV? A score without a PV makes no sense to me, especially since I'm starting to work on my eval
It seems you have several misconceptions here. Stand-pat is NOT ust a device to speed up QS. If you search until no captures are left, you will get totally wrong and meaningless scores. Because you wil also search bad captures. E.g. when QxP is the only capture left, but P is protected, you would play it, and conclude that you are in a position where you are a Queen down.

Secondly, stand-pat does NOT cutoff your PV. It is part of the PV. It means that at that point,for so faryou can judge, your best move will be a non-capture. That your tree has other branches that are longer does not alter that. They are not PV branches, but side branches of the PV that have been refuted by recaptures.
stevemulligan wrote:On the 2nd ply I know my engine takes this line: c4c3 b2c3 (b3c3) (d2d3) (c3d3) (moves in brackets are qsearch moves)
To quote your example: (d2d3) (c3d3) are not part of the 2-ply PV. They just a horrible blunder giving away a Rook, and its refutation by capturing it. Your engine would come to the conclusion that you are unavoidably going to lose a Rook in this position, without stand-pat, which is total garbage.
kbhearn
Posts: 411
Joined: Thu Dec 30, 2010 4:48 am

Re: pv in qsearch

Post by kbhearn »

The point is that if no capture is an improvement, taking the best bad capture is not an accurate representation of the position, because the bad capture does not need to be made, a noncapture can be played.

In your example d2xd3 was bad, it lost a rook (because of c3xd3). so it's not part of the pv, the assumption is there'll be something better than making that bad capture, and so you take the 'stand pat' eval and the PV shouldn't include the last two moves searched because they weren't part of it, the stand pat was, it maintains the sanity of the q-search only including nonquiet moves by assuming that there exists at least one quiet move no worse than standing pat. You can find positions where this is not true, zugzwang, or a tactic that involves some more quiet moves, but you'll discover that in future iterations as you increase your depth.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: pv in qsearch

Post by Evert »

stevemulligan wrote: When I stand pat I get c4c3 b2c3 (b3c3) because there are never any alpha cuts on the last two moves and that's how I generate my PV.
Why do you think that's a problem?
The stand pat code is called near top of qsearch after board eval (my engine is based on the tutorial on chessbin.com)
Calling the static evaluation is one of the first things I do in qsearch (if not the first). It's hard to think what you might do first (hash probes, I suppose, if you have them in QS, I don't). That sounds completely fine.
User avatar
stevemulligan
Posts: 117
Joined: Wed Jul 20, 2011 2:54 pm
Location: Ottawa, Canada

Re: pv in qsearch

Post by stevemulligan »

kbhearn wrote:The point is that if no capture is an improvement, taking the best bad capture is not an accurate representation of the position, because the bad capture does not need to be made, a noncapture can be played.
Ahh, I get it now. And all it took for me to understand was 5 different explanations from 5 different people /sigh Many thanks to everyone for having patience.

I see now that qsearch needs to stand pat, and it does so by relying on a (very safe) 'guess' there is a better non-capture. I should have realized the score of any captures after b3c3 were useless.