Simple KQK endgame tablebase verification

[xmas79]

I still don't understand one thing. During the generation I always need to probe the TB to see if the score I have in the TB is already better of what I'm analyzing. I understand that I needed to probe only when marking the positions "won", since if cah happen that they have been already encountered before. When I'm marking a position as lost instead, it cannot happen that it has been encountered before becuse when I mark the position as lost ALL of its ancestors must be won. The problem is that if I disable one of these checks I get different counters....


Thx,
Natale.

[xmas79]

Hi Steven,
did you ever wrote an user manual for symbolic??? Every now and then I see you typing new commands!! ))

Thanks.

[xmas79]

Did you use that method to test your TB?

[Patrice Duhamel]

For KPK, I found easy to test my table with Gaviota tables.
I use KPK only for the draw information, and let the engine search other positions.

Are KRK and KQK very usefull ?

[xmas79]

Are KRK and KQK very usefull ?

Not really by itself I think. NGN had no problem at all at winning these endings. However I'm refactoring my eval, and as part of such process reviewing the special end game management code,which includes KPK. I was not really satisfied of what I had in that ending, so I wanted to write a KPK EGTB. so I had to write the KQK first to check I fully understand what I was doing (!), now I'll go with KRK, then I will finally implement KPK,which is an endgame I saw too often, and that motivated me to write that.

[syzygy]

Did you use that method to test your TB?

Yes, that is the basic idea.

But to keep the verification efficient the verification program first decompresses the compressed file and then reconstructs information that was thrown away by the generator before the compression phase. For example, for positions with a winning capture the compressed table may store an arbitrary value (whatever compresses best) as the probing code will correct it. The verifier makes the same correction. When that's done, I do a loop over all positions as I described, but I reuse the move generation scheme of the generator (which works on indexes instead of regular board representations) as that is much more efficient. Since I reuse code, my verifier is not fully independent from my generator. That is a weakness in my approach.

[sje]

Hi Steven,
did you ever wrote an user manual for symbolic??? Every now and then I see you typing new commands!! :)))

A poll was taken with100% of Symbolic's users responding and the unanimous verdict was that no user manual is needed. All are perfectly happy with the program's help command:

Code: Select all

[] help
Commands:
      beep  Emit audible alert
     bench  Run benchmark
      dapv  Display auto predicted variation
        db  Display board
     dbbdb  Display bitboard database
   dbcolor  Display board (color)
    dbmono  Display board (mono)
      dbov  Display boolean option vector
       dcc  Display chess clock
      ddtc  Display distribution thread count
        df  Display FEN
       dhs  Display hash signatures
       did  Display program identification
       dif  Display initial FEN
        dm  Display moves
      dmcs  Display moves (certain scores)
      dmcv  Display moves (combo vector)
      dmob  Display moves (opening book)
      dmqs  Display moves (quiescence scores)
      dmtb  Display moves (tablebase)
    dmverb  Display moves (verbose)
      dpgn  Display PGN
       dps  Display pawn structure
        ds  Display status
      dsob  Display status (opening book)
      dstb  Display status (tablebases)
      dstt  Display status (transposition tables)
      echo  Echo command arguments
      exit  Exit program
      flip  Flip the position
    fsmate  File scan: mate finder with full move distance limit
    fstabs  File scan: TABS with seconds limit
         g  Go search for N seconds then play the result move
      help  Show help strings
      hint  Calculate and display a move hint
   loadfen  Load FEN from file
   loadpgn  Load PGN from file
  makebook  Make book: ifname ofname plylen mincount
      mate  Mate finder
       new  New game
      nice  Nice priority
      noop  No operation
   normpgn  Normalize PGN file (file1 -> file2)
    pcbulk  Path count (bulk mode)
    pcfull  Path count (full mode)
    pctran  Path count (tran mode)
    perft7  Work unit perft (draft=7)
    perft8  Work unit perft (draft=8)
  perftrep  Work unit perft report
  perftsum  Work unit perft summation
       rbo  Reset boolean option(s)
      rbov  Reset boolean option vector
      rdtc  Reset distribution thread count
        rg  Random game generation
    rgfile  Random game generation to a file
        rm  Retract move
       rmp  Retract move pair
      rmts  Retract moves to start
       rtt  Reset transposition tables
         s  Search for N seconds then display the result move
   savefen  Save FEN to file
   savepgn  Save PGN to file
       sbo  Set boolean option(s)
      sdtc  Set distribution thread count
        sf  Set FEN
    system  System command
      tabs  TABS with seconds limit
      test  Test
   uniqpgn  Uniquify PGN (file1 -> file2)

Boolean options:
      dto0  Developer test option 0
      dto1  Developer test option 1
      dto2  Developer test option 2
      mono  Monochrome output only
      talk  Speech synthesis output
      tras  Trace: analysis statistics
      trcv  Trace: current variation
      tre0  Trace: enumeration ply 0
      tre1  Trace: enumeration ply 1
      trfd  Trace: first down
      trfv  Trace: final variation
      trlf  Trace: load factor
      trpt  Trace: processor (usage) time
      trpv  Trace: predicted variation
      trpz  Trace: ply zero operations
      trsi  Trace: search iteration
      trtt  Trace: transposition table operations
      trwt  Trace: wall (elapsed) time
      tstp  Timestamp in command prompt
      verb  Increased verbosity

[syzygy]

I still don't understand one thing. During the generation I always need to probe the TB to see if the score I have in the TB is already better of what I'm analyzing. I understand that I needed to probe only when marking the positions "won", since if cah happen that they have been already encountered before. When I'm marking a position as lost instead, it cannot happen that it has been encountered before becuse when I mark the position as lost ALL of its ancestors must be won. The problem is that if I disable one of these checks I get different counters....

It depends on what method of generation you use exactly.

For a small TB you can afford to keep things simple and just keep doing forward searches on all positions until things stabilise. (If you do that, then my proposed method of verification is nothing else than doing another iteration to make sure that the table remains stable.)