We need to scrap Perft()

[R. Tomasi]

Indeed, that's why I suggest doing it the way I did.

OK, that would solve the problem how to obtain reference results - but at the expense of still not being what is done in real QS, even discounting pruning and just looking at the move generators. See the "no underpromotions in QS" example. So that would still not test how moves are generated in QS, which was the objective of the proposal.

What's your alternative proposal then? I mean, nobody would be forced to do this, it's just that having these kind of reference numbers would be nice (and helpful to some people, me included).

[Ras]

And another thing: we would then have QS explosion right in that kind of perft, too, because e.g. queens would go on plunder raids. In real QS, you counter that problem by a recapture-only mode from a certain QS depth onwards, but that wouldn't work in QS perft.

[dangi12012]

Indeed, that's why I suggest doing it the way I did.

OK, that would solve the problem how to obtain reference results - but at the expense of still not being what is done in real QS, even discounting pruning and just looking at the move generators. See the "no underpromotions in QS" example. So that would still not test how moves are generated in QS, which was the objective of the proposal.

What's your alternative proposal then? I mean, nobody would be forced to do this, it's just that having these kind of reference numbers would be nice (and helpful to some people, me included).

Wouldnt it only help in debugging?
Also what if your count differs by 2 from 8 billion. Since QS is by definition only for leaf nodes and with no bounded depth.
It would still be insanely hard to find a bug.

PerfT can collect statistics about chess like castling, ep, checkmate that are interesting in themselves. But if you add QS at the leaf you get a debugging tool for chess engine developers imo. Which also has its merits.

[R. Tomasi]

And another thing: we would then have QS explosion right in that kind of perft, too, because e.g. queens would go on plunder raids. In real QS, you counter that problem by a recapture-only mode from a certain QS depth onwards, but that wouldn't work in QS perft.

Yes, one would have these explosions. They are still finite, though. Perft is intrinsically explosive in that sense, and because it's not finite you need to stop at a certain depth. With captures only it still explodes, but finitely.

[R. Tomasi]

Also what if your count differs by 2 from 8 billion. Since QS is by definition only for leaf nodes and with no bounded depth.
It would still be insanely hard to find a bug.

You have a point there. So maybe still limit the depth somehow?

[dangi12012]

And another thing: we would then have QS explosion right in that kind of perft, too, because e.g. queens would go on plunder raids. In real QS, you counter that problem by a recapture-only mode from a certain QS depth onwards, but that wouldn't work in QS perft.

Yes, one would have these explosions. They are still finite, though. Perft is intrinsically explosive in that sense, and because it's not finite you need to stop at a certain depth. With captures only it still explodes, but finitely.

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?

Also for pure movegens the leafs are bulk counted with popcount which is a trick that has no use in engines. So that would bring pure movegen and engines closer together.

[Ras]

What's your alternative proposal then?

If you want that kind of cperft, I'd only include captures as one additional level at the leaves of the traditional perft, but with no further capture recursion. Odd/even perft would automatically imply the capture tests for each side. That leaves the caveat of underpromotion-only, which would ideally be specified in cperft so that is comes closer to real world QS. The normal underpromotion that is usually in main search is already caught in standard perft anyway.

[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.

[Ras]

Yes you run out of captures pretty quickly.

Actually not - due to mutual plunder raids.

[R. Tomasi]

What's your alternative proposal then?

If you want that kind of cperft, I'd only include captures as one additional level at the leaves of the traditional perft, but with no further capture recursion. Odd/even perft would automatically imply the capture tests for each side. That leaves the caveat of underpromotion-only, which would ideally be specified in cperft so that is comes closer to real world QS. The normal underpromotion that is usually in main search is already caught in standard perft anyway.

That sounds reasonable to me.