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?
pv in qsearch
Moderator: Ras
-
stevemulligan
- Posts: 117
- Joined: Wed Jul 20, 2011 2:54 pm
- Location: Ottawa, Canada
-
Aleks Peshkov
- Posts: 974
- Joined: Sun Nov 19, 2006 9:16 pm
- Location: Russia
- Full name: Aleks Peshkov
Re: pv in qsearch
Chess is not checkers, without stand pad Qsearch has no sense.
-
stevemulligan
- Posts: 117
- Joined: Wed Jul 20, 2011 2:54 pm
- Location: Ottawa, Canada
Re: pv in qsearch
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 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
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: pv in qsearch
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.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.
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.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: pv in qsearch
How is it causing a problem?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.
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?
-
stevemulligan
- Posts: 117
- Joined: Wed Jul 20, 2011 2:54 pm
- Location: Ottawa, Canada
Re: pv in qsearch
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.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?
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;
-
hgm
- Posts: 28440
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: pv in qsearch
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.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
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.
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.stevemulligan wrote:On the 2nd ply I know my engine takes this line: c4c3 b2c3 (b3c3) (d2d3) (c3d3) (moves in brackets are qsearch moves)
-
kbhearn
- Posts: 411
- Joined: Thu Dec 30, 2010 4:48 am
Re: pv in qsearch
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.
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.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: pv in qsearch
Why do you think that's a problem?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.
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.The stand pat code is called near top of qsearch after board eval (my engine is based on the tutorial on chessbin.com)
-
stevemulligan
- Posts: 117
- Joined: Wed Jul 20, 2011 2:54 pm
- Location: Ottawa, Canada
Re: pv in qsearch
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.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.
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.