Order

[MDiaz]

Someone can explain whi in some engines (everyone?) is beter search bad captures (sse(mov)<0) before moves or even killer moves?
Do yow use same ordering in search an in qsearch?

[hgm]

I guess bad captures (SEE < 0) are more often good moves, to the point of causng a cutoff, than the killer move. This might partly be due to the fact that most people do not allow bad captures to become killer moves.

[bob]

I guess bad captures (SEE < 0) are more often good moves, to the point of causng a cutoff, than the killer move. This might partly be due to the fact that most people do not allow bad captures to become killer moves.

A couple of notes.

1. Captures are not allowed to become killers because captures are searched _before_ killers so it would be pointless to do so.

2. In my case, I generate captures first, then pick out the ones with SEE >= 0 and try those first. Then killer moves. Then I generate the rest of the moves, but since the losing captures are already on the list first, they get searched first. Most likely, by the time you get thru the hash move, good captures, then killers, if you have not hit a beta cutoff, you are going to search everything anyway so it doesn't matter at all.

Move ordering is about one thing, getting a "good enough" move up front to get a quick cutoff. Otherwise ordering is irrelevant.

[hgm]

1. Captures are not allowed to become killers because captures are searched _before_ killers so it would be pointless to do so.

But if you would defer searching bad captures to after the killers, or even after non-captures, as Manuel seems to suggest we should do, it would no longer be pointless to allow these bd captures as killers. That was my point.

[bob]

1. Captures are not allowed to become killers because captures are searched _before_ killers so it would be pointless to do so.

But if you would defer searching bad captures to after the killers, or even after non-captures, as Manuel seems to suggest we should do, it would no longer be pointless to allow these bd captures as killers. That was my point.

I certainly search 'em after the killers, because I search killers before generating the non-capture moves. And I suppose that in _rare_ cases, a capture that looks bad could be good. But it would displace a non-capture that will be good in far more cases. That's why most have always used at least 2 killers, so that just one won't get overwritten by a locally-good-move that is not useful in the general case...

I'm pretty sure I have tested this extensively in the past, although I do not remember the results, other than that I have always excluded captures, from the days of Cray Blitz to today.

[hgm]

Now you got me confused. First you say that captures are searched _before_ killers. Now you say the bad captures are searched _after_ the killers.

The main qustion still stands: if bad captures are searched after the killers, why would you exclude these bad captures from being killers?

[bob]

Now you got me confused. First you say that captures are searched _before_ killers. Now you say the bad captures are searched _after_ the killers.

The main qustion still stands: if bad captures are searched after the killers, why would you exclude these bad captures from being killers?

OK, back to the beginning.

I first try the hash move before generating any moves at all. If that causes a cutoff, good, I avoided doing any move generation at all.

I then generate just captures, and search the ones with SEE >= 0, leaving the rest on the list for later. If those cause a cutoff, good. I avoided generating non-captures.

Next I try the killers. If they cause a cutoff, good. Again, I have not yet generated non-captures.

If I get this far, I generate non-captures next, but the captures with SEE < 0 are on the front of the list, so they get searched first. Good for tactical tests usually, bad in general. But I don't want to take the time to move them down or skip over them and have to come back, although I might try this latter idea to see if it is better for normal positions.

Hopefully that was clearer. I can try killers (which are not allowed to be captures) before generating non-captures, as once I generate non-captures I just exclude the killers from being searched a second time. Ditto for the hash move.

The reason "bad captures" are excluded is that "all captures" are excluded. I suppose it would be possible to do this, although I think the effect is so tiny that it would be hard to measure. Most of the time a good capture does the trick. By the time you get down to killers, it is very unlikely they are going to help...

[sje]

If I get this far, I generate non-captures next, but the captures with SEE < 0 are on the front of the list, so they get searched first. Good for tactical tests usually, bad in general. But I don't want to take the time to move them down or skip over them and have to come back, although I might try this latter idea to see if it is better for normal positions.

Maybe I'm missing something here, but why generate non-captures without first ensuring that there's no cutoff caused by a "bad" capture?

[bob]

If I get this far, I generate non-captures next, but the captures with SEE < 0 are on the front of the list, so they get searched first. Good for tactical tests usually, bad in general. But I don't want to take the time to move them down or skip over them and have to come back, although I might try this latter idea to see if it is better for normal positions.

Maybe I'm missing something here, but why generate non-captures without first ensuring that there's no cutoff caused by a "bad" capture?

It did not help when I tried it, and the benefit _used_ to be that I used the history heuristic so that I could actually try some non-captures before those bad captures were tried. I removed the history stuff a couple of years ago when I discovered it was not helping at all any longer.

[CThinker]

If I get this far, I generate non-captures next, but the captures with SEE < 0 are on the front of the list, so they get searched first. Good for tactical tests usually, bad in general. But I don't want to take the time to move them down or skip over them and have to come back, although I might try this latter idea to see if it is better for normal positions.

Maybe I'm missing something here, but why generate non-captures without first ensuring that there's no cutoff caused by a "bad" capture?

It did not help when I tried it, and the benefit _used_ to be that I used the history heuristic so that I could actually try some non-captures before those bad captures were tried. I removed the history stuff a couple of years ago when I discovered it was not helping at all any longer.

I still think that answer did not address Steven's questions, which is, why generate non-captures before exhausting all captures?

If I understand it correctly, Crafty does it this way:
1. generate captures
2. try good captures
3. try killers
4. generate non-captures (append to the list of bad captures).
5. try bad captures and non-captures

Why not this:
1. generate captures
2. try good captures
3. try killers
4. try bad captures
5. generate non-captures
6. try non-captures

If you get a cut-off in (4), you don't need to do (5) which is time-consuming.