lucasart wrote:
- mate killer: again, it may help in particular positions, but overall it was proven to be perfectly useless
In terms of playing strength, I presume. That's not really surprising because it only helps in positions where you have mate-threats, which probably occur most often if you are in a better (winning) position anyway: it doesn't change the outcome of the game, it just gets you there faster. Testing for playing strength is not going to reveal that.
As a feature, it'll probably more useful as an analysis feature, and that could be an argument to keep it (in fact, might be an argument to add it).
Yes, that's exactly it.
But I'm still amazed about the recapture extension. So many programs do it, and it seems so intuitively right. Testing in my program has shown it to be useless (if not harmful) no matter how it's implemented: based on SEE, or on a (dangerously path-dependant) recapture condition, using half ply extensions, extending only at PV nodes etc.
Robery Hyatt mentionned in a previous thread that he did some extensive testing, and came to the conclusion that the *only* search extension that is usefull is the check extension. Even the 7-th rank pawn extension was proven useless. And the same applies to half ply extensions.
lucasart wrote:
- mate killer: again, it may help in particular positions, but overall it was proven to be perfectly useless
In terms of playing strength, I presume. That's not really surprising because it only helps in positions where you have mate-threats, which probably occur most often if you are in a better (winning) position anyway: it doesn't change the outcome of the game, it just gets you there faster. Testing for playing strength is not going to reveal that.
As a feature, it'll probably more useful as an analysis feature, and that could be an argument to keep it (in fact, might be an argument to add it).
Yes, that's exactly it.
But I'm still amazed about the recapture extension. So many programs do it, and it seems so intuitively right. Testing in my program has shown it to be useless (if not harmful) no matter how it's implemented: based on SEE, or on a (dangerously path-dependant) recapture condition, using half ply extensions, extending only at PV nodes etc.
Robery Hyatt mentionned in a previous thread that he did some extensive testing, and came to the conclusion that the *only* search extension that is usefull is the check extension. Even the 7-th rank pawn extension was proven useless. And the same applies to half ply extensions.
I agree in general, since I did extensive test upon the recapture extension myself while ago and found it useless. Also the only extension
that worked for me in it's pure form was check extension. But this is only 'in general'. What found to work also with my engines was the avoidance of reduction on certain conditions. I mean, you can still not extend, but avoid reductions also if pawn steps on 7th, Queen has been promoted, Pawny endgame appears, etc. This is still a form of indirect extension since you don't reduce and it's exactly what's working best for me.
lucasart wrote:
But I'm still amazed about the recapture extension. So many programs do it, and it seems so intuitively right. Testing in my program has shown it to be useless (if not harmful) no matter how it's implemented: based on SEE, or on a (dangerously path-dependant) recapture condition, using half ply extensions, extending only at PV nodes etc.
I think I still have it in Jazz, but disabled by default for similar reasons (it does nothing).
I didn't bother implementing it in Sjaak, although there is a possibility that it's more useful in some variants than in others...
Robery Hyatt mentionned in a previous thread that he did some extensive testing, and came to the conclusion that the *only* search extension that is usefull is the check extension. Even the 7-th rank pawn extension was proven useless. And the same applies to half ply extensions.
True.
Jazz still has this (enabled), Sjaak doesn't. I didn't get round to testing this yet.
My suspicion is that this will only matter if you're close to the horizon and need to better evaluate the passed pawn. Close to the root it probably doesn't matter so much. If you're doing promotions in q-search, then it may not be very important either.
lucasart wrote:
- mate killer: again, it may help in particular positions, but overall it was proven to be perfectly useless
In terms of playing strength, I presume. That's not really surprising because it only helps in positions where you have mate-threats, which probably occur most often if you are in a better (winning) position anyway: it doesn't change the outcome of the game, it just gets you there faster. Testing for playing strength is not going to reveal that.
As a feature, it'll probably more useful as an analysis feature, and that could be an argument to keep it (in fact, might be an argument to add it).
Yes, that's exactly it.
But I'm still amazed about the recapture extension. So many programs do it, and it seems so intuitively right. Testing in my program has shown it to be useless (if not harmful) no matter how it's implemented: based on SEE, or on a (dangerously path-dependant) recapture condition, using half ply extensions, extending only at PV nodes etc.
Robery Hyatt mentionned in a previous thread that he did some extensive testing, and came to the conclusion that the *only* search extension that is usefull is the check extension. Even the 7-th rank pawn extension was proven useless. And the same applies to half ply extensions.
I agree in general, since I did extensive test upon the recapture extension myself while ago and found it useless. Also the only extension
that worked for me in it's pure form was check extension. But this is only 'in general'. What found to work also with my engines was the avoidance of reduction on certain conditions. I mean, you can still not extend, but avoid reductions also if pawn steps on 7th, Queen has been promoted, Pawny endgame appears, etc. This is still a form of indirect extension since you don't reduce and it's exactly what's working best for me.
Ah, now that's an interesting idea. I'll try to move the "pawn to the 7-th trank condition" from extension to "non-reduction", to begin with. The point is that I don't reduce a move that has been flagged as "to extended", so the impact of an extension is often 2 plies instead of 1...
Evert wrote:
My suspicion is that this will only matter if you're close to the horizon and need to better evaluate the passed pawn. Close to the root it probably doesn't matter so much. If you're doing promotions in q-search, then it may not be very important either.
You're probably right, but unfortunately an extension condition that would depends on how close we are to the horizon, would be dangerously path dependant.
And yes, my qsearch generates always promotions, so it may not be useful in the search for that reason.
lucasart wrote:
- mate killer: again, it may help in particular positions, but overall it was proven to be perfectly useless
In terms of playing strength, I presume. That's not really surprising because it only helps in positions where you have mate-threats, which probably occur most often if you are in a better (winning) position anyway: it doesn't change the outcome of the game, it just gets you there faster. Testing for playing strength is not going to reveal that.
As a feature, it'll probably more useful as an analysis feature, and that could be an argument to keep it (in fact, might be an argument to add it).
Yes, that's exactly it.
But I'm still amazed about the recapture extension. So many programs do it, and it seems so intuitively right. Testing in my program has shown it to be useless (if not harmful) no matter how it's implemented: based on SEE, or on a (dangerously path-dependant) recapture condition, using half ply extensions, extending only at PV nodes etc.
Robery Hyatt mentionned in a previous thread that he did some extensive testing, and came to the conclusion that the *only* search extension that is usefull is the check extension. Even the 7-th rank pawn extension was proven useless. And the same applies to half ply extensions.
I agree in general, since I did extensive test upon the recapture extension myself while ago and found it useless. Also the only extension
that worked for me in it's pure form was check extension. But this is only 'in general'. What found to work also with my engines was the avoidance of reduction on certain conditions. I mean, you can still not extend, but avoid reductions also if pawn steps on 7th, Queen has been promoted, Pawny endgame appears, etc. This is still a form of indirect extension since you don't reduce and it's exactly what's working best for me.
Ah, now that's an interesting idea. I'll try to move the "pawn to the 7-th trank condition" from extension to "non-reduction", to begin with. The point is that I don't reduce a move that has been flagged as "to extended", so the impact of an extension is often 2 plies instead of 1...
Unfortunately, the avoid-reduction ideas are very floating. It depends of how aggressive are your reductions. For example, if you're reducing with 2 ply every move after let's say the 4th one, the avoidance could work better (0 ply reduction), but might work with 1 ply reductions and not avoidance and so on. It needs a lot of testing to find out what's exactly working best for you.
I prune losing captures in QS. Due to a bug in my implementation I included on a "random" basis some losing captures.
When I fixed he bug, the engine played weaker. Searching all losing captures it also played weaker. During research in what positions the bug helped I also found positions that had nothing to do with checks at all.
Consider a position where you and your opponent have a winning capture of the same value but with the piece that is the victim of the opponents capture you can perform a losing capture.
Playing the winning capture first gains nothing because the opponent performs his winning capture and material balance is restored. If you play the losing capture, the opponent recaptures and then you play the winning capture, you win material, because the winning capture of the opp. is no longer possible (the victim is already gone).
At the end I just accepted that QS is full of errors anyway (even SEE is not always accurate) so I tried to make it light weighted and spot the errors by an additional ply of search.
Mincho Georgiev wrote:[ What found to work also with my engines was the avoidance of reduction on certain conditions. I mean, you can still not extend, but avoid reductions also if pawn steps on 7th, Queen has been promoted, Pawny endgame appears, etc. This is still a form of indirect extension since you don't reduce and it's exactly what's working best for me.
You say you avoid reduction when "Pawny endgame appears". I assume you mean pawn endgame. But this only happens by a capture, so if you don't reduce captures, you already don't reduce "pawn endgame appears". Are you reducing captures, or was this a mistake?
This was just an example, pawn endgame could appear of course in case of a capture only. I mean if you _are_ reducing the captures, might be a good idea not to /or extend/ in case of /QxQ especially/ pawn endgame transition.
Just an idea. I don't do it since I don't reduce 'good' or 'equal' captures.
Path dependency shouldn't be dangerous as long as you extend by no more than 1 ply per move. If you only extend when remaining depth <= 4 say, and you store that hash, you'd recalculate it when another path reaches it at say depth 6 remaining anyways due to insufficient depth in the TT. The next two ply could hypothetically include one ply extensions themselves, but this would just push the depth 6 search to equivalent to the depth 4, not worse.
