We need to scrap Perft()

[dangi12012]

Yes you run out of captures pretty quickly. But for every leaf node that can be very expensive. So usual depths for perft of 7-8 might have to be reduced to 5.
But as a debugging and performance tool for a pure QS search approach it has some merits.
So who wants to put in the work first?

Probably about 10mins and I have working implementation (although not the fastest one ). But before starting any work on it, we should maybe agree on what work is to be done.

Propoposal:
cperft(6) = perft(6) + recursive QS for every leaf node
So that would have a lower bound of 119,060,324 for the default position + a few million for the unbounded captures.

I would keep it to unbounded recursive captures since that is the same as QS. Its the same exploding tree as normal perft so no problem at all.
Also I can think of tricks to know the captures at the end of a node which is not something that translates to true QS (where you do that recursively).

[R. Tomasi]

Yes you run out of captures pretty quickly. But for every leaf node that can be very expensive. So usual depths for perft of 7-8 might have to be reduced to 5.
But as a debugging and performance tool for a pure QS search approach it has some merits.
So who wants to put in the work first?

Probably about 10mins and I have working implementation (although not the fastest one ). But before starting any work on it, we should maybe agree on what work is to be done.

Propoposal:
cperft(6) = perft(6) + recursive QS for every leaf node
So that would have a lower bound of 119,060,324 for the default position + a few million for the unbounded captures.

I would keep it to unbounded recursive captures since that is the same as QS. Its the same exploding tree as normal perft so no problem at all.
Also I can think of tricks to know the captures at the end of a node which is not something that translates to true QS (where you do that recursively).

Remains the issue about how that helps with debugging. I find the proposal to just do captures at the final depth (as suggested by Ras) quite good. One could discuss if one might want to do 2 capture layers instead of one, but as Ras pointed out, for debugging it doesn't matter.

[Ras]

That sounds reasonable to me.

Ah, and queen promotions should be regarded as captures even if they don't capture because they are usually part of QS move gens.

So basically, one additional, non-recursive level with:
1) captures (including e.p.)
2) promotions to queen even if they promote on an empty square (i.e. without capture)

[Ras]

I find the proposal to just do captures at the final depth (as suggested by Ras) quite good.

Yes, it's easy because at least with cperft 0, you look at all captures and queen promotions in the given position. That is something you can observe manually, plus that you can see which exact moves are missing (if any).

[R. Tomasi]

That sounds reasonable to me.

Ah, and queen promotions should be regarded as captures even if they don't capture because they are usually part of QS move gens.

So basically, one additional, non-recursive level with:
1) captures (including e.p.)
2) promotions to queen even if they promote on an empty square (i.e. without capture)

For 1): underpromotions, too? I think your idea to have a parameter for the underpromotions has some merit, but I kind of dread the situation were we have to tabulate twice: with and without underpromotions. Confusion is bound to happen there.

[dangi12012]

I find the proposal to just do captures at the final depth (as suggested by Ras) quite good.

Yes, it's easy because at least with cperft 0, you look at all captures and queen promotions in the given position. That is something you can observe manually, plus that you can see which exact moves are missing (if any).

Ah I see why this discussion is irrelevant now and non recursive is better.
The normal Perft includes any and all moves of qs. So just increasing perft to perft+1 solves that.
and with cperft(0) you can debug.

[Ras]

For 1): underpromotions, too?

No underpromotions because the objective is to test the move gen in QS, and that typically doesn't include underpromotions.

I kind of dread the situation were we have to tabulate twice: with and without underpromotions.

That would need to be agreed beforehand, and I think not evaluating underpromotions in QS is the typical way engines work.

[Ras]

The normal Perft includes any and all moves of qs.

Yes, but using a different kind of move generator so that different bugs might be lurking there.

The idea with the additional cperft level is that you get a lot of positions to test, and if the number is correct, you're good to go. Only if it isn't, then you need cperft 0 in an appropriate position for debugging.

[R. Tomasi]

Ok. So let's summarize what seems to be the agreement we're converging toward:

cperft(n) is like normal perft(n), except for the final depth, were we only look at captures (excluding underpromotions) and queen-promotions.

[R. Tomasi]

Btw. I could see a similar thing to cperft for testing checking-moves movegen (in very similar spirit).