release: WB version of my EGT generator

[hgm]

I was so annoyed with the user unfriendliness of my tablebase generator, that I now made a version of it that can run as a WB engine. So that you can actually have it play out an end-game against you, letting the tablebase prove the win against your best efforts.

I also made it possible to specify the end-game on the command-line, and to define the piece types in a piecedef.ini file in a user-friendly format (e.g. R: 1,0,s* would define a Rook). Before, this required altering the source code, and recompiling.

Now you only have to install it under WinBoard for example as

"Q vs R" -fcp "4men -xboard KQ.KR" /fd="../fairygen" /initialMode=EditPosition

and you will see the building stats scroll through the Engine-Output window while you can in the mean time set up a KQKR position, and then click 'Machine White' to get crushed.

It can be downloaded from http://hgm.nubati.net/fairygen.zip .

[hgm]

I already released a next version, fixing a probing bug. (I had added code to reduce any given position to the canonical symmetry sector, but it would sometimes get the diagonal symmetry wrong when the white King was on the diagonal.)

This version has flag arguments to alter the treatement of stalemate or allow null move in general. It turns out that KNNK is a win in those cases. Even KBBK and KBNK seem winnable without zugzwang (i.e. when the bare King can null-move).

[Evert]

This version has flag arguments to alter the treatement of stalemate or allow null move in general. It turns out that KNNK is a win in those cases. Even KBBK and KBNK seem winnable without zugzwang (i.e. when the bare King can null-move).

Awesome!

[Evert]

This version has flag arguments to alter the treatement of stalemate or allow null move in general. It turns out that KNNK is a win in those cases. Even KBBK and KBNK seem winnable without zugzwang (i.e. when the bare King can null-move).

Awesome!

Remind me: this is not true of KRK, right (I know, I could take out my board and pieces and try it out)?

[hgm]

Indeed, KRK is a draw against null-move, and the generator confirms it. (There area few mates when you are already on a1, and he can immediately 'stalemate' you there.)

[hgm]

Something interesting: when null-move is legal, stalemate normally would be nonexistent, as you would never be without legal moves when not in check, because you could always null-move. In practice, however, letting yourself be trapped in a stalemate position by King plus one piece will doom you, as the opponent now has all the time in the world to manouevre his other piece in the position to check (and thus mate) you. Only when color-binding of that piece guarantees this cannot happen, you can surive the stalemate, and the opponent willbe forced to release you to make progress.

But this means that the attacking side can use a threat with stalemate as a weapon to force the bare King to move. E.g.

[d]7N/8/8/8/8/4BK2/8/5k2 b

Black is not in check here, but he is forced to step towards the deadly corner to avoid Bf2!, after which the Knight will sooner or later finish the job (Ng6-f4-d5-e3). This does make it easier to drive up the bare King.

The most difficult combination of rules for the attacker (not implemented in the released generator yet) would be the rather unnatural one where black can null-move whenever he wants, but can claim a draw when stalemated. In that case black could simply sit and wait in the diagram, until the white Knight forces it to move by checking f1, rather than moving to f1 immediately. (And returning to f1 after that when white approaches the Knight would also be fatal.) This makes white progress much slower, and it would still take 31 more moves to checkmate.

Nevertheless, KNBK turns out to be generally won even under those rules. But it does take 65 moves, rather than 34.

[hgm]

Yet another release (v 1.2)!

On request I added the possibility to 'seed' the tablebase, i.e. define the DTC of some positions by hand, by specifying a file with (position, DTx) pairs with a -f argument.

This version now interprets stalemate always as stalemate, even when black is allowed to null-move (so that strictly speaking stalemate could never exist). The other case was not very interesting, because when stalemate is a forced pass, you will sooner or later be mated in that position. So I dropped that.

This version also supports a -m flag to force generation of DTM tablebases.

[hgm]

Nothing new, just a screenshot: