We need to scrap Perft()

[R. Tomasi]

For example, what about check evasions?

Since that should also be part of main search, regular perft covers that aspect. That's also why I don't really see the need for a checkperft. Without checkperft, we could stay with cperft for the capture / QS test.

checkperft was about generating checks only, not check-evasions. But honestly, I'm fine staying with cperft for the capture/QS test. I don't see support for something like a checkperft gaining much traction...

[R. Tomasi]

It only way this would kind of make sense to me is if you didn't stop in ply + 1, but instead explored all the captures and promotions fully.

Well, the problem with that is: assume you get numbers differing from the reference. How do you go about debugging that then? The difference might happen like 10ply down from the leaf...

[dangi12012]

Could somebody post a table with the new cperft() ?

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [0] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [1] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [2] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [3] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [4] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [5] = ?

r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [0] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [1] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [2] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [3] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [4] = ?

Now we said non recrsive leaf nodes - or fully recursive leaf nodes?
I would be happier to see them fully recursive since that is more in engine style.
But only pending captures and pending promotions.

[Ras]

I would be happier to see them fully recursive since that is more in engine style.

That would be bad because it would lead to QS explosion - and unlike perft where you have strict control over the recursion depth, recursive QS would explode in many positions due to plunder raids. That's why in real engine QS, you need to combat this problem e.g. by a recapture-on-same-square mode from a certain QS depth on.

[R. Tomasi]

Could somebody post a table with the new cperft() ?

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [0] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [1] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [2] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [3] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [4] = ?
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 [5] = ?

r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [0] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [1] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [2] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [3] = ?
r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - [4] = ?

Now we said non recrsive leaf nodes - or fully recursive leaf nodes?
I would be happier to see them fully recursive since that is more in engine style.
But only pending captures and pending promotions.

See my posts. I posted results for the starting pos and for kiwi-pete. It was done with only one ply-depth capture and excluding any underpromotions.

[Ras]

See my posts. I posted results for the starting pos and for kiwi-pete. It was done with only one ply-depth capture and excluding any underpromotions.

I get different results for Kiwipete (r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 1):
cperft 0: 8
cperft 1: 351
cperft 2: 17102
cperft 3: 753124
cperft 4: 35043030

My suspicion is that leaf underpromotions that also happen to be captures are counted in Mergi's implementation, but they shouldn't be counted:

Code: Select all

    if (board.CapturedPiece() || GetMoveType(m) == PROMOTE_QUEEN) {
        ++total_nodes;
    }

If I modify my move gen to also include underpromotions that are captures, then I get 758998 for cperft 3, but as you said above, no underpromotions at all in the leaf nodes.

[R. Tomasi]

See my posts. I posted results for the starting pos and for kiwi-pete. It was done with only one ply-depth capture and excluding any underpromotions.

I get different results for Kiwipete (r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 1):
cperft 0: 8
cperft 1: 351
cperft 2: 17102
cperft 3: 753124
cperft 4: 35043030

My suspicion is that leaf underpromotions that also happen to be captures are counted in Mergi's implementation, but they shouldn't be counted:

Code: Select all

    if (board.CapturedPiece() || GetMoveType(m) == PROMOTE_QUEEN) {
        ++total_nodes;
    }

If I modify my move gen to also include underpromotions that are captures, then I get 758998 for cperft 3, but as you said above, no underpromotions at all in the leaf nodes.

Underpromotions shouldn't be counted in my implementation - I actually double checked to be sure about that, but of course it's possible that I still f*cked up. Unfortunately I am not home currently and can't access my code from here - I'll have to wait till after the x-mas holidays to check again.

[Mergi]

My suspicion is that leaf underpromotions that also happen to be captures are counted in Mergi's implementation, but they shouldn't be counted:

Code: Select all

    if (board.CapturedPiece() || GetMoveType(m) == PROMOTE_QUEEN) {
        ++total_nodes;
    }

You are absolutely right.