Hello,
I'm investigating a bullet game played (and lost) by my engine this morning, in which it played a rather stupid move.
In this position:
As white, it played Nd4, ignoring the threat of the pawn in b5.
Traces show that at some point during search, QS stopped due to "standing pat" at this position:
Which is, as far as I can tell, not quiet at all and leads white to lose a piece.
To fix this I naively tried to implement some kind of null-move check in quiescence, which kinda works in this particular case, but is a major elo loss in general.
I'm wondering if I'm asking too much to the QS and maybe that's a problem that should only be fixed by searching faster (and deeper) ?
Non-quiet position after quiescence...
Moderators: hgm, Dann Corbit, Harvey Williamson
Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Re: Non-quiet position after quiescence...
As it is white-to-move and white have no good capture it makes sense to stop here.
I guess its just you overall search depth is low being the problem here.
Weak engines are often try to prolong inevitable losses by giving checks and/or trading pieces (as here) during the search.
This would be somewhat mitigated when your depth would raise (although not completely gone)
Quick solution without losing much elo (and maybe gaining some) as of right now would be adding in recapture extension i guess, but this extension is very hard to get right for stronger engines so it can become hindrance in the future.
More refined solution would be adding specific "hanging" evaluation term, that is present in the most of the (if not all) top engines. It means during evaluation you give a penalty when your piece is attacked by a pawn (or rook by minor, or Q by R/N/B). But from my experience it is hard to come up with good numbers for this eval from the top of your head.
PS. I`m not very experienced in this stuff, so i would take my words with a grain of salt
I guess its just you overall search depth is low being the problem here.
Weak engines are often try to prolong inevitable losses by giving checks and/or trading pieces (as here) during the search.
This would be somewhat mitigated when your depth would raise (although not completely gone)
Quick solution without losing much elo (and maybe gaining some) as of right now would be adding in recapture extension i guess, but this extension is very hard to get right for stronger engines so it can become hindrance in the future.
More refined solution would be adding specific "hanging" evaluation term, that is present in the most of the (if not all) top engines. It means during evaluation you give a penalty when your piece is attacked by a pawn (or rook by minor, or Q by R/N/B). But from my experience it is hard to come up with good numbers for this eval from the top of your head.
PS. I`m not very experienced in this stuff, so i would take my words with a grain of salt

Re: Non-quiet position after quiescence...
I think a good solution to this problem is evaluating the position statically as pawn minus the least valuable piece, so something like -2.3. I would also give a bonus for the first position of something like -(-2.3)/2 since it is very hard to get out of the threat and the only option is to threaten a piece of greater value.Nomis wrote: ↑Sun Jan 10, 2021 3:04 pmHello,
I'm investigating a bullet game played (and lost) by my engine this morning, in which it played a rather stupid move.
In this position:
As white, it played Nd4, ignoring the threat of the pawn in b5.
Traces show that at some point during search, QS stopped due to "standing pat" at this position:
Which is, as far as I can tell, not quiet at all and leads white to lose a piece.
To fix this I naively tried to implement some kind of null-move check in quiescence, which kinda works in this particular case, but is a major elo loss in general.
I'm wondering if I'm asking too much to the QS and maybe that's a problem that should only be fixed by searching faster (and deeper) ?
- maksimKorzh
- Posts: 525
- Joined: Sat Sep 08, 2018 3:37 pm
- Location: Ukraine
- Full name: Maksim Korzh
- Contact:
Re: Non-quiet position after quiescence...
Can't see position, could you please provide bare FEN string?Nomis wrote: ↑Sun Jan 10, 2021 3:04 pmHello,
I'm investigating a bullet game played (and lost) by my engine this morning, in which it played a rather stupid move.
In this position:
As white, it played Nd4, ignoring the threat of the pawn in b5.
Traces show that at some point during search, QS stopped due to "standing pat" at this position:
Which is, as far as I can tell, not quiet at all and leads white to lose a piece.
To fix this I naively tried to implement some kind of null-move check in quiescence, which kinda works in this particular case, but is a major elo loss in general.
I'm wondering if I'm asking too much to the QS and maybe that's a problem that should only be fixed by searching faster (and deeper) ?
Position should be considered quiet when either no captures are available or if eval() == quiescence()
Can't say more without seeing actual position.
JavaScript chess engine with UCI support, own GUI and public API:
https://github.com/maksimKorzh/wukongJS
Chess programming YouTube channel:
https://www.youtube.com/channel/UCB9-pr ... KKqDgXhsMQ
https://github.com/maksimKorzh/wukongJS
Chess programming YouTube channel:
https://www.youtube.com/channel/UCB9-pr ... KKqDgXhsMQ
Re: Non-quiet position after quiescence...
Thanks for your replies.
I'll look into the extension.
maksimKorzh, the FEN are:
r2qkbnr/1b2p2p/n1p2pp1/pp1p4/8/BPNBPN2/P1PP1PPP/R2QK2R w KQkq - 0 10
5knr/1b2p2p/r1pq1pp1/p2p4/1p6/BPN1P3/P1PP1PPP/R2QK2R w KQ - 0 14
I'll look into the extension.
maksimKorzh, the FEN are:
r2qkbnr/1b2p2p/n1p2pp1/pp1p4/8/BPNBPN2/P1PP1PPP/R2QK2R w KQkq - 0 10
5knr/1b2p2p/r1pq1pp1/p2p4/1p6/BPN1P3/P1PP1PPP/R2QK2R w KQ - 0 14
- maksimKorzh
- Posts: 525
- Joined: Sat Sep 08, 2018 3:37 pm
- Location: Ukraine
- Full name: Maksim Korzh
- Contact:
Re: Non-quiet position after quiescence...
Seems like something is wrong with quiescence.
Neither of positions you've provided are quite.
May be you have depth limit in quiescence along with stand pat?
Otherwise it's hard even to assume what's wrong there.
If you post your alphabeta() and quiescence() code here it would bring some light...
P.S. Are you sure that your quiescence is only dealing with captures and not calculating quiet moves?
JavaScript chess engine with UCI support, own GUI and public API:
https://github.com/maksimKorzh/wukongJS
Chess programming YouTube channel:
https://www.youtube.com/channel/UCB9-pr ... KKqDgXhsMQ
https://github.com/maksimKorzh/wukongJS
Chess programming YouTube channel:
https://www.youtube.com/channel/UCB9-pr ... KKqDgXhsMQ
Re: Non-quiet position after quiescence...
Indeed, neither position is quiet, but in the second position white cannot improve the position with a capture, and thus QS stops. Which as far as I know is expected, and leads to my question.