perft

[Steve Maughan]

Hi Daniel,

There are a few articles with test positions on my Chess Programming blog.

http://www.chessprogramming.net

You may find it helpful,

Steve

[Daniel Anulliero]

thx steve , good blog

[flok]

Am I right that those perft-values not always follow the correct rules, e.g. that occasionally when using the validation of the moves is too strict, that different values are returned?

For example:

Code: Select all

8/3K4/2p5/p2b2r1/5k2/8/8/1q6 b - -

With my program it finds 6 nodes, while the webpage I got this perft from says it should be 50.

I'm afraid even your FEN parsing code is full of bugs.[/quote]

From what did you determine that?

[syzygy]

Am I right that those perft-values not always follow the correct rules, e.g. that occasionally when using the validation of the moves is too strict, that different values are returned?

For example:

Code: Select all

8/3K4/2p5/p2b2r1/5k2/8/8/1q6 b - -

With my program it finds 6 nodes, while the webpage I got this perft from says it should be 50.

I'm afraid even your FEN parsing code is full of bugs.

From what did you determine that?

Well, when I see my program produce a result that is incorrect I don't wonder whether it is maybe not a bug because "6 is close enough to 50". I accept that it is a bug and that it is a bug in my code. And I realise that I am very lucky, because the bug is perfectly reproducible which means that it is 100% certain that I will find the bug and squish it.

Getting a working program with as few bugs as possible is a matter of attitude. Don't stare in amazement how your "fully correct" move generator can produce incorrect results. Do not think that you're done just because your perft 6 on the opening position is correct.

So how did I determine that your FEN parsing code is buggy? I did the first thing that you should have done. I set up the position and looked at it. It is pretty clear that black has WAY MORE than 6 moves. On the other hand, white with only a king on the board is pretty restricted... the white king has exactly 6 moves. What a coincidence!

So you're simply not parsing the "b" as "black to move".

That you are not completely parsing FEN strings is not a serious problem. It is easy to fix this. The real problem is that you have not given a serious look at what could be wrong here. Instead, you seem to somehow blame the "perft" test as not being reliable, which is basically the same as arguing that addition of numbers gives imprecise results. After all, it can't be your code, right?

Sorry for being so critical, but really, it is essential to be critical if you want to get anywhere with a chess engine.

[flok]

I'm afraid even your FEN parsing code is full of bugs.

From what did you determine that?

Well, when I see my program produce a result that is incorrect I don't wonder whether it is maybe not a bug because "6 is close enough to 50". I accept that it is a bug and that it is a bug in my code. And I realise that I am very lucky, because the bug is perfectly reproducible which means that it is 100% certain that I will find the bug and squish it.[/quote]

For the record: I asked that question because I was trying to find out what was going wrong. I totally agree that all bugs should be fixed. At work I'm that guy that compiles all his software with the "-pedantic" (GNU-C) compiler switch enabled and spends most of his time writing testcases.

What I tried to ask is, if it would be possible that these (original) values were obtained with an "almost-correct" move generator. I've read those are used in certain situations.

So you're simply not parsing the "b" as "black to move".

And indeed that was the case...in the single threaded mode of my program in which I ran the testcases initially.

It is easy to fix this. The real problem is that you have not given a serious look at what could be wrong here. Instead, you seem to somehow blame the "perft" test as not being reliable, which is basically the same as arguing that addition of numbers gives imprecise results. After all, it can't be your code, right?

No, no definately not that. Well, I hope I explained that above.

[syzygy]

What I tried to ask is, if it would be possible that these (original) values were obtained with an "almost-correct" move generator. I've read those are used in certain situations.

As I said, you were assuming the error was on the other side without even having had a look at the position yourself.

[flok]

What I tried to ask is, if it would be possible that these (original) values were obtained with an "almost-correct" move generator. I've read those are used in certain situations.

As I said, you were assuming the error was on the other side without even having had a look at the position yourself.

No no, I was asking if my code needed to be adapted so that it could handle perfts-for-slightly-valid-move-lists (if they existed).

I was not saying that there were incorrect perfts, I was asking if there were perfts to followed the strict validation of move-lists, and ones that had other rules that I did not know of.

If I didn't believe those perft-results out there were correct, I would not have bothered started implementing testcases using them.

[rreagan]

Perft values are not calculated using pseudo-legal move generators. The final perft value tallies up only the legal nodes.

For those using a pseudo-legal move generator, they have to check for legality to make sure the king is not left in check.