Seirawan Chess: Sigla, Sjaak, Leonidas

[hgm]

In Fairy-Max I just give a hefty bonus for gating in a piece, to make it very unlikely it keeps them in hand until after it ran out of gating opportunities. This makes it gate on the first two moves if there isn't a very unfavorable randomization.

I guess a better approach would have been to penalize non-gating moves of back-rank pieces as long as there are still pieces in hand, as now it almost always starts with its Knights.

The problem is that this makes Fairy-Max a poor test opponent for other S-Chess programs, as it would never expose evaluation errors of the in-hand pieces.

In S-Fruit I explicitly keep track of the number of gating opportunities, and use a lookup table for a penalty depending on the that number, the number of in-hand pieces and the presence of castling rights. This typically makes it gate late. Unfortunately my implementation of gating at Rook squares was such that it now has become crash-prone.

[Evert]

The way I do it now is as follows:

Code: Select all

1. Determine how many pieces are waiting to be gated.
2. Count number of gating opportunities: this is the number of unmoved ("virgin") backrank pieces, not counting royalty (a fudge to account for castling only allowing one gated piece, despite involving two virgin pieces).
3. Tweak the score as follows:
    a. If I have at least two more options than pieces waiting:
        no scaling, count piece value fully for material
        pieces in holdings get a positive PST value
    b. If I have fewer than that but still enough options for gating all pieces:
        The piece value is scaled back using N*(N-1)/(N*(N-1)+1) where N is the number of gating squares remaining.
        The PST value for pieces in holdings is set to 0
    c. If I have fewer gating options than pieces waiting to be gated:
        The piece value is scaled according to N*(N-1) / files*(files-1)
        The PST value for pieces in holdings is set to 0        

This could all be done better with smooth scaling and 3c is a hack: it would be more accurate to disqualify the least valuable pieces from being counted rather than penalising all of them (then again, the Hawk and Elephant are close in strength and it may depend on the position which is better). In practice I don't think this matters much, since you've screwed up pretty badly either way and the main point of the evaluation term is to encourage the engine to never ever get into that position.

Counting the king or not for the purpose of gating possibilities is another interesting puzzle. More correct is to reduce the number of options by 1 if the player hasn't castled yet (but still could), and then perhaps only if there aren't enough other options. Even then, it's preferable to give up castling rights than to be down a Hawk or Elephant, but once again you've screwed up badly enough if you need to resort to that.

[hgm]

In S-Fruit I use this table:

Code: Select all

static const int HandLoss[4][16] = { // penalty for having ungated pieces as function of gating opportunities
   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, },             // no pieces in hand
   { 915, 0, 80, 50, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, },        // one piece in hand
   { 1830, 0, 995, 250, 180, 80, 50, 10, 0, 0, 0, 0, 0, 0, 0, 0, }, // two pieces in hand
};

The second subscript is actually twice the number of virgin pieces, decremented by one if castling rights exist. 915 is the average value of H and E (Fruit uses Q=1000).

The penalty of 250 for having only a castling left and two pieces represents the loss of castling, plus a penalty for tactical weakness that will require at least two moves to solve.

[Ferdy]

Here is a beta version which you might want to try with latest S-fruit and perhaps latest Sjaak.

Sigla s-chess engine download:
http://www.mediafire.com/download/6mccm ... 6.beta.rar

Some changes in eval related to gate pieces. There are also bug fixes in search and some improvement on reductions.

Limitation, cannot gate in rook file when castling .

Is S-Fruit available for download?

[mar]

I could build a new version from my development tree for testing, but it will have the usual problem of requiring the large C++ runtime DLL.

I can build the binaries for you if you post a link where to get the actual sources.

[Evert]

I could build a new version from my development tree for testing, but it will have the usual problem of requiring the large C++ runtime DLL.

I can build the binaries for you if you post a link where to get the actual sources.

Awesome, thanks!

I've uploaded the new version here (1.0 RC1): http://www.eglebbk.dds.nl/program/chess-download.html

[Evert]

Here is a beta version which you might want to try with latest S-fruit and perhaps latest Sjaak.

Sigla s-chess engine download:
http://www.mediafire.com/download/6mccm ... 6.beta.rar

Some changes in eval related to gate pieces. There are also bug fixes in search and some improvement on reductions.

Limitation, cannot gate in rook file when castling .

Will it accept moves that gate there? If not, you'll probably run into trouble at some point. I don't think Fairy-Max ever does it, but Sjaak will do it occasionally (I don't pretend to understand why though).

[hgm]

Annoying move indeed. Fairy-Max will never do it, and I had to add several lines of code to allow it from the opponent. (Basically pre-correcting the RxK notation to the corresponding K step before doing the normal MakeMove gating at King square, and afterwards moving what appeared on the K square to the R square.)

Even WinBoard is kludgy for this move, regarding notation: in SAN it really writes it as the Rook capturing the King, (e.g. Rxe1/E), which looks awful. We would really need a better notation for it. Gating at King square now is a normal O-O with H or E gating suffix (e.g. O-O/H). One way would be to include a disambiguator behind the suffix (e.g. O-O-O/aH vs. O-O-O/eH), but I really dislike that. Another idea is to use \ in stead of / for the suffix announcer: O-O\H vs O-O/H.

One problem is that the Komodo S-Chess version actually plays this, with black in the opening that it plays against S-Fruit at 2-4min/40 moves TC. (They both play reproducibly.)

Fruit encodes its moves internally as 2 bit special-move flag (normal, e.p., castling, promotion), two bit promotion piece (N, B, R, Q) and 2x 6 bit square number. In S-Fruit I use the promo-piece codes for {N, H, E, Q} instead, upgrading B and R promotion when the user does those. (In theory this can lead to false stalemate perception.) I slipped in some code in move_do() to detect non-null promotion piece in non-promotion moves, and interpret those as gatings (So you can gate H, E or Q, and the code that specifies N on promotion counts as non-gating). This allowed gating to be combined with castlings, and as the castlings are encoded as the King move, the gating code automatically gates at the King square. (The original code tests for castling after the move, and then moves the Rook if there was one, based on the encoded King to-square.)

So what I did is add moves flagged as castlings, but encoding the Rook move in stead of the King move (e.g. a1d1). Then the gating code automatically gates at the Rook square, and the castling code now has to also test for to-square d1/f1/d8/f8 next to c1/g1/c8/g8, and move the King in those cases as extra displacement, rather than the Rook. I did not put it in the move generator yet, so it would never play the move by itself. But when I enter it, it crashes some moves later, so I must have goofed somewhere.

I did not release S-Fruit yet. I wanted to finish and debug it before doing that. But I did not have any opportunity to work on it, last week.

[Evert]

Annoying move indeed. Fairy-Max will never do it, and I had to add several lines of code to allow it from the opponent. (Basically pre-correcting the RxK notation to the corresponding K step before doing the normal MakeMove gating at King square, and afterwards moving what appeared on the K square to the R square.)

Even WinBoard is kludgy for this move, regarding notation: in SAN it really writes it as the Rook capturing the King, (e.g. Rxe1/E), which looks awful. We would really need a better notation for it. Gating at King square now is a normal O-O with H or E gating suffix (e.g. O-O/H). One way would be to include a disambiguator behind the suffix (e.g. O-O-O/aH vs. O-O-O/eH), but I really dislike that. Another idea is to use \ in stead of / for the suffix announcer: O-O\H vs O-O/H.

Sjaak uses O-O/Hh1 or O-O/He1 as SAN output for gating moves. I'd prefer the last one to actually read just O-O/H, but I need to special-case that and haven't bothered. I don't think I actually implemented parsing these on input though. It's not exactly pretty.

Fruit encodes its moves internally as 2 bit special-move flag (normal, e.p., castling, promotion), two bit promotion piece (N, B, R, Q) and 2x 6 bit square number. In S-Fruit I use the promo-piece codes for {N, H, E, Q} instead, upgrading B and R promotion when the user does those. (In theory this can lead to false stalemate perception.) I slipped in some code in move_do() to detect non-null promotion piece in non-promotion moves, and interpret those as gatings (So you can gate H, E or Q, and the code that specifies N on promotion counts as non-gating). This allowed gating to be combined with castlings, and as the castlings are encoded as the King move, the gating code automatically gates at the King square. (The original code tests for castling after the move, and then moves the Rook if there was one, based on the encoded King to-square.)

Sjaak's move encoding is complicated. Moves are a combination of pickups, drops and swaps. A castle move is encoded as two swaps, a castle+gate is two swaps+one drop. The drop location is always explicit, which makes this relatively easy. I do need to special-case RxK on input and output, but I need to do the same for KxR anyway.

So what I did is add moves flagged as castlings, but encoding the Rook move in stead of the King move (e.g. a1d1). Then the gating code automatically gates at the Rook square, and the castling code now has to also test for to-square d1/f1/d8/f8 next to c1/g1/c8/g8, and move the King in those cases as extra displacement, rather than the Rook. I did not put it in the move generator yet, so it would never play the move by itself. But when I enter it, it crashes some moves later, so I must have goofed somewhere.

This is what I would do for a dedicated S-chess engine as well.

A related question: Sjaak should be able to play Seirawan2880 without any modification, but it doesn't have an algorithm to generate a starting position (it relies on the GUI for that) which is why it doesn't announce this as a possibility. I remember some discussion in the past for "shuffle-FEN" that would tell the GUI which back-rank pieces to shuffle. Did anything come of that? Or should I just bite the bullet and write an algorithm to generate these?

[Ferdy]

Here is a beta version which you might want to try with latest S-fruit and perhaps latest Sjaak.

Sigla s-chess engine download:
http://www.mediafire.com/download/6mccm ... 6.beta.rar

Some changes in eval related to gate pieces. There are also bug fixes in search and some improvement on reductions.

Limitation, cannot gate in rook file when castling .

Will it accept moves that gate there? If not, you'll probably run into trouble at some point. I don't think Fairy-Max ever does it, but Sjaak will do it occasionally (I don't pretend to understand why though).

Simply it does not know h1e1 and something similar as castling move. I probably need more time to solve this for the sake of completeness.
Does Leonidas know about this type of move?