Perft(14) Weekly Status Report

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Perft(14) Weekly Status Report

Post by sje »

syzygy wrote:
sje wrote:It does have a very good record of accurate move operations, though.
Doesn't any chess engine / perft implementation that is not outright buggy?
How many chess engines have successfully calculated perft(13)? I know of only one.
syzygy wrote:I haven't really followed this, but what is the point of reporting on the progress made by an only average perft implementation? Wouldn't it be enough to report the final result?
As I wrote earlier, the motivations for making the effort public include: to encourage participation, to shorten the time to result, and to allow for independent confirmation of partial results. Just reporting the final result does none of this.
ibid
Posts: 89
Joined: Mon Jun 13, 2011 12:09 pm

Re: Perft(14) Weekly Status Report

Post by ibid »

sje wrote:
syzygy wrote:
sje wrote:It does have a very good record of accurate move operations, though.
Doesn't any chess engine / perft implementation that is not outright buggy?
How many chess engines have successfully calculated perft(13)? I know of only one.
I can think of three.

Perhaps your definition of perft includes a breakdown by move for some
arbitrary number of moves from the initial position. Or perhaps one is to
fixate on the word "engine" and exclude results if the same executable
doesn't play games of chess too.

But if that is the case, there being only one and no verification, I am not
entirely sure we know it "successfully calculated" anything... :)

Don't get me wrong, I am glad someone is verifying Peter's computation
and you are welcome to do it however you like, I was simply suggesting a
way to speed things up.

Best of luck,
-paul
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Perft(14) Weekly Status Report

Post by syzygy »

sje wrote:
syzygy wrote:
sje wrote:It does have a very good record of accurate move operations, though.
Doesn't any chess engine / perft implementation that is not outright buggy?
How many chess engines have successfully calculated perft(13)? I know of only one.
If only one, how do you know it was successful.

Seriously, having a correct working move generator is not something unique.
syzygy wrote:I haven't really followed this, but what is the point of reporting on the progress made by an only average perft implementation? Wouldn't it be enough to report the final result?
As I wrote earlier, the motivations for making the effort public include: to encourage participation, to shorten the time to result, and to allow for independent confirmation of partial results. Just reporting the final result does none of this.
Just announce once and keep your intermediate results on a website? Nagging people into participating by mere repetition usually does not work.
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Perft(14) Weekly Status Report

Post by sje »

ibid wrote:Don't get me wrong, I am glad someone is verifying Peter's computation
and you are welcome to do it however you like, I was simply suggesting a
way to speed things up.
Work on Oscar is progressing slowly but surely, and I'll soon be hitting the dual implementation frontiers of transposition tables and OpenCL hosting. But first I want to make sure that everything else is running and the program continues to pass many, many different perft() tests. Further, the code must be portable to any ANSI C environment, and it must also be reasonably clean and clear as it will be made publicly available.

Until Oscar is ready, Symbolic will continue to crank out work unit results; each step is another step closer to the goal. Additionally, results from the two programs for the same work unit can be used to help validate the effort.
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Perft(14) Weekly Status Report

Post by sje »

syzygy wrote:
sje wrote:
syzygy wrote:
sje wrote:It does have a very good record of accurate move operations, though.
Doesn't any chess engine / perft implementation that is not outright buggy?
How many chess engines have successfully calculated perft(13)? I know of only one.
If only one, how do you know it was successful.

Seriously, having a correct working move generator is not something unique.
syzygy wrote:I haven't really followed this, but what is the point of reporting on the progress made by an only average perft implementation? Wouldn't it be enough to report the final result?
As I wrote earlier, the motivations for making the effort public include: to encourage participation, to shorten the time to result, and to allow for independent confirmation of partial results. Just reporting the final result does none of this.
Just announce once and keep your intermediate results on a website? Nagging people into participating by mere repetition usually does not work.
Symbolic's perft(13) result:

1. Matched Byrne's result (1,981,066,775,000,396,239), but used different hardware and a very different algorithm,
2. Is backed up by all 20 perft(12) subtotals, all public and some separately verified,
3. Is backed up by all 400 perft(11) subtotals, all public and some separately verified,
4. Is based on hashing done with 128 bit signatures, effectively eliminating false positives,
5. Came from the same program which correctly calculated perft(n) with n from 0 to 12.

So, I think that the calculation was successful.

Oh, and I don't consider a once-a-week status report to be nagging of any kind. If anyone doesn't want to read them, then they can just skip this thread as I won't post the reports anywhere else.
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Perft(14) Weekly Status 2014-09-07

Post by sje »

Perft(14) Weekly Status 2014-09-07

There are more than 700,000 perft(7) results so far, about 0.73% of the 96,400,068 needed.

Completed work units (8): 000-004, 008, 011, 964
In progress (8): 005-007, 009-010, 012-014
Not yet started (949): 015-963

Work units in progress:

Code: Select all

WU#  Comp% Machine
---  ----- -------
005: 58.1% joni
006: 59.1% megan
007: 14.8% melissa
009: 46.9% cynthia
010: 93.7% rocky
012: 78.5% amanda
013: 34.9% serra
014: 35.1% kristen
mvk
Posts: 589
Joined: Tue Jun 04, 2013 10:15 pm

Re: Perft(14) Weekly Status Report

Post by mvk »

sje wrote:
syzygy wrote:
sje wrote:It does have a very good record of accurate move operations, though.
Doesn't any chess engine / perft implementation that is not outright buggy?
How many chess engines have successfully calculated perft(13)? I know of only one.
That is because the amount of required resources needed for calculating high-depth perft numbers is huge compared to the perceived value. Not because writing a bug-free move generator is any new ground. There are more effective ways to confirm the correctness of a generator than to blow tonnes of CO2 into the atmosphere.
[Account deleted]
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Carbon dioxide

Post by sje »

mvk wrote:There are more effective ways to confirm the correctness of a generator than to blow tonnes of CO2 into the atmosphere.
I'm sure that the the grass and trees on my land consume more CO2 than I produce. And my share of the plant life on the parks and forests which I help support with tax money eats a lot of CO2 as well.

Further, much of the power used is nuclear generated (which has its own problems), so no CO2 from fossil fuels. And the heat from my computers helps keep my house warm at night and in the winter.
Uri Blass
Posts: 10281
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: Perft(14) Weekly Status Report

Post by Uri Blass »

mvk wrote:
sje wrote:
syzygy wrote:
sje wrote:It does have a very good record of accurate move operations, though.
Doesn't any chess engine / perft implementation that is not outright buggy?
How many chess engines have successfully calculated perft(13)? I know of only one.
That is because the amount of required resources needed for calculating high-depth perft numbers is huge compared to the perceived value. Not because writing a bug-free move generator is any new ground. There are more effective ways to confirm the correctness of a generator than to blow tonnes of CO2 into the atmosphere.
I agree that calculating perft(14) is not a good way to verify the correctness of a move generator.

It is better to use the sum of perft(3) on many thousands of chess positions to confirm the correctness of a move generator.

There are many bugs that you cannot find based on perft(14) from the opening position and you may need clearly more than 14 plies from the opening position to get them.

For example if you have a bug in generating king moves when the black king is in rank 1 you are not going to discover it by perft 14 from the opening position because the black king will not get there(you need 16 plies to get to rank 1 with the black king because black needs 8 moves when 7 of them are king moves).
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Perft(14) Weekly Status Report

Post by sje »

Uri Blass wrote:I agree that calculating perft(14) is not a good way to verify the correctness of a move generator.
You are correct.

I did not claim that perft(14) would properly exercise all of the generate/execute/retract code in any program. But it does quite well for those positions which can be reached. Further, as Symbolic is primarily a chess program and not a perft() program. Many, many routines which have nothing to do with perft() are exercised. That's in part why Symbolic is a slow perft() calculator relative to at least some specialized perft() programs.

One way I use to verify move generation is to feed various well-known FEN files (e.g., BWTC, WAC, WCSAC, etc.) into the program being tested and run perft() for various depths and checking the results with a known good program.

A more thorough way is to use the random game generator code and compare the generation count for each position between the program being tested and a known good generator. It's tough for a bug to hide in hundreds of billions random positions. This technique is also good for testing specialized generators: gainer moves only, checking moves only, etc.

Symbolic's source is 21,135 lines long. The source specific to it's perft() transposition code is less than 0.5% of that, only 100 lines:

Code: Select all

NodeCount Position::PathCountTran(const ui depth, PCTBasePtr baseptr)
{
  typedef enum
  {
    EsInit,
    EsInitPly,
    EsExecute,
    EsTermPly,
    EsTerm,
    EsExit
  } Es;

  NodeCount total;

  Es state = EsInit;
  ui ply;
  PcPIRList pcpirlist;
  PcPIRNodePtr pnptr;

  while (state != EsExit)
    switch (state)
    {
      case EsInit:
        ply = 0;
        pcpirlist.Append(new PcPIRNode());
        pnptr = pcpirlist.GetHead();
        state = EsInitPly;
        break;

      case EsInitPly:
        pnptr->Reset();
        if (ply == depth)
        {
          pnptr->sum = 1;
          state = EsTermPly;
        }
        else
        {
          if (ply == (depth - 1))
          {
            pnptr->sum = CountMoves();
            state = EsTermPly;
          }
          else
          {
            if (baseptr->Probe(*this, (depth - ply), pnptr->sum))
              state = EsTermPly;
            else
            {
              Generate(pnptr->gmvec);
              state = EsExecute;
            };
          };
        };
        break;

      case EsExecute:
        if (pnptr->AllMovesUsed())
        {
          baseptr->Stash(*this, (depth - ply), pnptr->sum);
          state = EsTermPly;
        }
        else
        {
          Execute(pnptr->NextMove());
          ply++;
          if (pcpirlist.GetCount() == ply)
            pcpirlist.Append(new PcPIRNode());
          pnptr = pnptr->GetNext();
          state = EsInitPly;
        };
        break;

      case EsTermPly:
        if (ply == 0)
        {
          total = pnptr->sum;
          state = EsTerm;
        }
        else
        {
          pnptr->GetPrev()->sum += pnptr->sum;
          ply--;
          pnptr = pnptr->GetPrev();
          Retract();
          state = EsExecute;
        };
        break;

      case EsTerm:
        pcpirlist.Reset();
        state = EsExit;
        break;

      default:
        break;
    };

  return total;
}