Single Comment

OK, I started a new thread for this to put an end to the off-topic
posting.

OK, the Seirawan algorithm Fairy-Max uses obviously sucks. Let me tell you
the full story about this:

A colleague engine author of mine recently converted his very strong Chess
engine (2800 Elo, so about 800 Elo stronger than Fairy-Max) to an S-Chess
engine, as a commercial project. I learned this last spring, and we came to
the conclusion that it would be nice if we could use XBoard as a GUIfor it.
So we agreed that he would convert his engine to WinBoard protocol (it was
originally UCI), and that I would add it to the variants supported by
WinBoard. And we defined the necessary protocol extensions that would be
needed to encode the gating moves.

After that, nothing happened for some time. (I was busy writing a Shogi
engine.) But a few weeks ago we set a release point for WinBoard 4.5.0,
(early December), and I wanted Seirawan Chess to be in before that. So I
just plunged ahead without an engine, and implemented it in WB. But I had
nothing to test the engine functions, which is a bit risky. So I decided to
do amakeshift implementation of Seirawan Chess in Fairy-Max, which already
knew the pieces, so that I just had to add the gating. But I implemented it
through a kludge, as my only interest was really to have an engine that
would support the protocol, and I did not worry much about playing quality.
(As that would be exceeded by 800 Elo when the other engine became
available anyway.)

So what I did was implement gating at the levelof the game move, but not in
the search. Fairy-Max selects its moves without being aware that any gating
is possible, and if it happens to move a piece from the back-rank, it gates
in any yet un-gated piece (first Hawk, then Elephant). I later refined this
a bit by checking that the score of the opponent reply after gating was not
suddenly much higher than it was in the original search without gating,in
which case I would cancel the gating, as I was apparently gating in a
super-piece on a square that was under attack. The idea was that by gating
in at the earliest opportunity, before there were any tactical
complications, I could get away with doing it without thinking about it.

Now I see this reasoning was flawed: Fairy-Max does his own gating, all
right, but the opponent can of course still delay the gating for as long as
he wants. And then surprise Fairy-Max with it while engaged in tactics.
This is exatly what happens here. Fairy-Max plays 9.Bg5, because he thinks
he can refute 9... Qxg5 with 10.Hc7+ to grab a Rook. (That this locks in
its Hawk this way, so that it might be doomed in the long run, is beyond
its strategic abilities to recognize, and even in engines with mobility
evaluation the poor Hawk mobility would never outweigh a Rook. Otho-Chess
engines program this as a pattern (with N in stead of H) to discount such a
doomed Knight.) So the plan is good, but of course did not count on an
Elephant suddenly appearing on d8(9... Qxg5/E) to defend c7, and thwart
white's ill intensions...

I guess this proves that my makeshift approach is just too simple,and that
you can never play decent Seirawn Chess this way. The gating really has to
be fully in the search. I amnot sure it would be worth it todo this in a
general-purpose variant engine, though. Anyway, thank you for exposing this
weakness.

As for the possibility to drop the pieces: the strong engine I was talking
about actually supports two variants: official Seirawan (or S-Chess, as
they call it nowadays), and a variant where you can drop the pieces on the
back rank whenever you want. I wanted to make it possible to play both
variants as 'Seirawan' under WinBoard, and let the engine decide which
drops or gatings are legal according to its current settings. WinBoard also
does not check, for instance, if the piece that effects the gating has
already moved or not. 

So one could say that Seirawan is only a partially defined variant in
WinBoard. This is not uncommon: some of the other variants are even
supported to a lesser degree, and can only be played with legality testing
off to prevent WinBoard from interfering with the game because it thinks
some of the moves are forbidden. In that case the engine is in full
control, and when it decides an entered move is illegal, it tells so to
WinBoard, and WinBoard will then refuse the move from the user.

I probably should let WB forbid drops anywhere else than on the back-rank,
however. These would be illegal under any circumstances, and it is easy to
do. Note that I only started implementing Seirawan a week ago, or so, and
that it is still in development.