A perft(7) challenge position

[xmas79]

My program NGN says:

Code: Select all

fen rnb1kbnr/pp1pp1pp/1qp2p2/8/Q1P5/N7/PP1PPPPP/1RB1KBNR b Kkq - 2 4
OK

perftfastmt 7
Time elapsed: 51.66800 seconds
Total leaf nodes: 14794751816
286.3M LNPS

[sje]

Three in agreement, so far

A third program also says: 14,794,751,816

BUT

A fourth program says: 14,794,762,630

It appears that the correct answer is indeed 14,794,751,816. Symbolic calculates the sum in three different ways, and that's the answer it gets, too. The alternative answer of 14,794,762,630 is from Ankan's GPU program -- which may be based on gperft -- and the difference is surely due to a false positive transposition table probe.

After many hundreds of thousands of perft(7) calculations, this is the first instance of a disagreement between Ankan's program and mine.

And this is why I use 128 bit hash signatures instead of 64 bit hash signatures.

[StuartRiffle]

Pigeon said 14,794,751,816

(But it made me sweat for a couple of minutes first!)

[ankan]

yes, most likely due to false positive from transposition table probe.

Just tried with non hash versions of the program and got correct answer:

CPU Perft 7: 14794751816, Time taken: 73.9707 seconds, nps: 200008156
GPU Perft 7: 14794751816, Time taken: 0.526672 seconds, nps: 28091023117

[sje]

yes, most likely due to false positive from transposition table probe.

Just tried with non hash versions of the program and got correct answer:

CPU Perft 7: 14794751816, Time taken: 73.9707 seconds, nps: 200008156
GPU Perft 7: 14794751816, Time taken: 0.526672 seconds, nps: 28091023117

I'll guess that the other mis-matched counts in the 409 work unit result are all derived from just one or two false positives which were retained in the transposition table for the duration of the run.

So far, five complete work units in the 400-799 range match correctly for a total of perft(7) 500,000 results. Also, there were an additional perft(7) 500,000 matching results from work units outside the 400-799 range.

Verified units (5): 400-401 403 406-407
Failed units (1): 409
In progress (8): 402 405 408 410-414

[Ajedrecista]

Hello Steven:

Here is the divided perft that confirms others' results:

Code: Select all

Intel Pentium D930 (3 GHz).
JetChess 1.0.0.0 (single core, 32-bit, hash = 512 MB).

rnb1kbnr/pp1pp1pp/1qp2p2/8/Q1P5/N7/PP1PPPPP/1RB1KBNR b Kkq - 2 4

  1  qb6-a5   458387356
  2  qb6-c5   651144888
  3  qb6-d4   730695681
  4  qb6-e3   739871066
  5  qb6*f2    25924489
  6  qb6-c7   481112000
  7  qb6-d8   265137487
  8  qb6-b5   569536792
  9  qb6-b4   460349749
 10  qb6-b3   548033029
 11  qb6*b2   685709017
 12  qb6-a6   271118692
 13  nb8-a6   513657072
 14  ng8-h6   589352355
 15   c6-c5   360968765
 16   f6-f5   531397121
 17   a7-a6   423681823
 18   a7-a5   447089524
 19   d7-d6   703673629
 20   d7-d5   827346268
 21   e7-e6   759858285
 22   e7-e5   739884888
 23   g7-g6   538145267
 24   g7-g5   525444540
 25   h7-h6   437638427
 26   h7-h5   541275720
 27  ke8-d8   439181982
 28  ke8-f7   529135904

Total:      14794751816

14,794,751,816 (move pathes after 7 half moves).

Time: 37.281 s (0:00:37.281).

Regards from Spain.

Ajedrecista.

[Joost Buijs]

Nightmare says:

Nodes: 14794751816
Time: 99.99 sec.
Nodes/sec.: 148,098,872

[tpetzke]

Code: Select all

iCE 3.0 v658 x64/popcnt [2016.1.3]
position fen rnb1kbnr/pp1pp1pp/1qp2p2/8/Q1P5/N7/PP1PPPPP/1RB1KBNR b Kkq - 2 4
perft 7
perft        Nodes    Time
  1             28    0 sec
  2            741    0 sec
  3         21.395    0 sec
  4        583.456    0.016 sec
  5     17.251.342    0.171 sec
  6    490.103.130    4.493 sec
  7 14.794.751.816    134.067 sec

 Perft 1 - 7 executed in 138.747 sec  (110.29 Mnps)

[Stan Arts]

Nemeton confirms. Dusted off my ancient perft code to give it a spin out of curiosity.

...But in doing so I thought to be clever and besides some other stuff removed side on move in check detection thinking it was not needed giving me a little extra speed.

..So my nodecount went slightly off for depth 7. I start to panic here.
Going over Kiwipete and other well known perft positions, all go slightly off. It seems once promotions and castling happens in large numbers.

So I add counters for promotions and castling. All off, though promotions seem accurate in positions where castling doesn't happen.

I'm thinking I have a castling bug after years.

I start to go over my castling code, do find a nice cleanup along the way, and then it occurs to me what's wrong. Ofcourse side to move in check was needed there.

TLDR / Moral of the story.
-Don't optimise.
-I lost an hour of my life.
-Perft is useful for bug hunting.

Code: Select all

ply: 1 nodes: 28 promotions: 0 castling: 0
ply: 2 nodes: 741 promotions: 0 castling: 0
ply: 3 nodes: 21395 promotions: 0 castling: 0
ply: 4 nodes: 583456 promotions: 0 castling: 0
ply: 5 nodes: 17251342 promotions: 0 castling: 0
ply: 6 nodes: 490103130 promotions: 0 castling: 36
ply: 7 ndoes: 14794751816 promotions: 0 castling: 1719609 

[pkumar]

My engine under development gives
D7 14794751816

Knps is bad.
I shall appreciate a few positions to take my engine through hoops (e.p., promotions, castling, etc.).