Sjaak II - beta release!

Discussion of anything and everything relating to chess playing software and machines.

Moderator: Ras

User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: Sjaak II - beta release!

Post by Evert »

hgm wrote: UNLESS the other piece happens to be able to attack both b1 and c2 at the same time.
I'd missed this condition, took me a bit of head-scratching why it would no longer recognise BB as a pair with mate potential after fixing some other issues.

It now correctly identifies BB, BN, B(FA) and N(FA) as mating pairs and FF as defective. It also finds FN as a winning pair, which is not really optimal but better than stumbling into one of the KFNK losing positions. Now that it considers KFNK as a winning pair, Sjaak will no longer return a draw score from the evaluation.
The latter clause makes that KNWK is a general win: both N and W are color alternators, and could thus never do case 1 (the corner mate). N is forking, but does need to be at b3 for that. But you can afford to relocate the attacking King to a3, because W at c1 would attack c2, so that the King doesn't have to cover it. In addition the Knight can switch in one move from covering c2 to delivering the fork (if it is on d4).
Sjaak currently doesn't list NW as a winning pair. I'm not sure why, but it could be that the retrograde analysis it does is simply too crude. What it tries to do is proof that there is at least one mate position that cannot be avoided by choice, which it does by unmaking the last two moves and seeing whether it can put the defending king in a position where it has no choice but to walk into the mate. If it can, it marks the pair as "winning". Of course, two moves are not necessarily enough to proof that no win is possible. Perhaps I should change this so it just builds up a proper bitbase, but in order to assess whether the result indicates that mate can be forced or not is a bit more tricky. Or I can keep the bitbase around and use it in the search…

I could also change the scoring for pairs. What Sjaak knows is whether a pair can force mate. What it assumes is that it can invert this to say that pairs where it doesn't know they can mate, can't. It currently forces the score to 0 in that case, but I could just divide by a large factor instead...
Note that this still doesn't cover everything; e.g. the case Zebra + Ferz. The zebra does +/-2 on one coordinate, and +/-3 to the other, and there is no way to make 0 of those with 3 terms, so it cannot make the (0,1) step from c1 to b1. So it doesn't seem a useful support to the Ferz' fork. Because the Zebra is color-alternating it it also cannot do the c1-a1 3-step tour. Yet they have mating potential, because you can afford to put the attacking King on c3, using Fb2 to trap the bare King on a2-b1, which both can be covered by a Zebra on d4. This pattern requires a 'double-forking' piece like Ferz, which can cover c1, a1 and a3 at the same time, (but also the WN can do that), plus a piece that can attack b1 and a2 at once. Knight could do the latter from c3, but is again disqualified because its King needs to be there.
It doesn't identify FZ as a mating pair either (but it does get BZ).
I know that you want Sjaak also to work for non-orthodox Kings, but it is really important to not only consider corner mates, as you will miss many won end-games that way. I think in Team-Mate Chess some of the teams even need to mate the King on c1 (using a forking piece to cover b1 and d1).
I do, but I'm not sure it's doing a particularly good job of it at the moment anyway. But I probably will change over to using an actual bitbase eventually, and that should make everything nice and consistent. For now, I try placing the king on A8 and B8, which works better than just placing it on A8, but it may be even better to just scan the entire board. It's mostly pointless in the sense that if you can't mate the king in the upper left quadrant, you're unlikely to do it in one of the other ones, but if you have asymmetric pieces it could happen...
Anyway, general draws should be treated like KQKQ or KNNKN, which are still a tad worse than KRKR and KNNK. In the latter you can assume a hard draw limiting the search to a few ply, (3 or 1). But in KQKQ or KNNKN there are some longer wins, so you really should not limit the search depth, but just evaluate them as marginally better than a dead draw.
Right now, Sjaak's evaluation identifies KNNK and KNNKN as dead draws, which isn't ideal. The other ones are simply evaluated as equal, since either side has mate potential.
The search isn't affected directly.
User avatar
hgm
Posts: 28503
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Sjaak II - beta release!

Post by hgm »

Strange that you don't get KNWK. It seems it should satisfy your criteria:

[d]8/8/8/8/3N4/K7/8/1k2R3 w
Rook represents Wazir
1. Wc1 Ka1 2. Nb3+ Kb1 3. Wc1#

is fully forced.
User avatar
hgm
Posts: 28503
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Sjaak II - beta release!

Post by hgm »

The actual way in which the mate is forced from a distant position is this:

[d]8/8/2N5/8/8/1K6/3R4/k7 w
This also shows how to solve the 'tempo' problem with two pieces that cannot triangulate, so that the King has to do it, while preventing the opponent from doing it too.

1. Wc2 Kb1 2. Nb4 Ka1 3. Ka4 Kb1 4. Ka3 Ka1 5. Nc6 Kb1 6. Nd4 Ka1 7. Nb3+ Kb1 8. Wc1#

I had another idea: When you find things like KNNK are dead draws, you could also do a retrograde analysis under rules where null-moving is allowed for the bare King (so that he can never be stalemated). Under those rules KNNK would be won. From this you can then conclude that end-games like KNNKx with some weak x that is too far away to help in defense, but can absorb the turn, would actually be lost (e.g. KNNKN, KNNKF, KNNKW, KNNKP). Probably not generally lost, but not a certain draw like KNK that would allow you to not search deeper but immediately return a 0 score. So the knowledge should affect the eval, but not the search.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: Sjaak II - beta release!

Post by Evert »

The current version is now beta 4 (again from http://www.eglebbk.dds.nl/program/chess-download.html). Changes and fixes in this version are mostly minor:
  • Variants now always get assigned a "parent" variant (usually "fairy"). This wasn't always the case before.
  • Better detection of mating pairs. In particular FN is now considered a mating pair (it's a very defective one, but scoring it as an outright draw is a mistake). It is still not 100% correct in all cases though.
  • Fix a potential crash for variants that start without a king on the board
  • Fix a bug that caused moves to be truncated to 3 characters on 32 bit systems
  • Better evaluation in variants with capture-the-flag victory conditions (for instance King of the Hill)
  • More selective/restricted search in variants dominated by forced captures. Earlier these could cause a search explosion and take forever to finish a 2-ply search.
Many thanks for all the people who tried beta3 and submitted bug reports!

If you're interested i capture-the-flag or capture-dominated variants, give this version a try.

The next update will probably be a release candidate for version 1.0, and should include support for Seirawan Chess. In terms of testing, UCI mode would be particularly useful to me.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: Sjaak II - beta release!

Post by Evert »

I have done a quiet update of beta4 to fix an issue with parsing the UCI movelist.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: Sjaak II - beta release!

Post by Evert »

Evert wrote: The next update will probably be a release candidate for version 1.0, and should include support for Seirawan Chess. In terms of testing, UCI mode would be particularly useful to me.
After thinking about it a little bit, I've decided to go with "beta 5" rather than "release candidate" afterall. This update includes the following fixes/features:
  • Seirawan Chess!
    In fact, Sjaak should be able to play "Seirawan2880", which is like FRC (Chess960) except that the super-pieces (Q, H, E) are shuffled with the holding space as well. However, Sjaak currently doesn't have an algorithm to shuffle the position and since Seirawan2880 is not a standard variant it doesn't announce it.
  • Fix missing options in UCI mode
  • Send "e1g1" castling rather than "KxR" in UCI mode, unless told otherwise
  • Pressing "tab" will now complete commands or variant names (if readline support is enabled)
  • Fix Mini-chess ("micro", 5x5) under X/WinBoard, for which Sjaak did not send the start position
  • Fix a bug where Sjaak, playing White, would claim an immediate win in variants where a bare king loses (Sho Shogi, Shatranj)
  • Fix duplicate result claims and suppress all claims in UCI mode.
  • Add "lift" or "pickup" moves as an allowed move option, in addition to regular and drop moves.
I have also added a variant "twilight" (based on this: http://www.talkchess.com/forum/viewtopic.php?t=54521) which uses lift moves, but with a caveat: since there is no standard way to send lift moves to a GUI (say, XBoard) I made something up for now. It's not ideal and I'd be happy to change it if there is some sort of agreement on the best way to handle this. That is perhaps more suitable for discussion on the technical forum, but I'll open the discussion here for context.

The description of "Twilight Chess" suggests "square@piece" for a lift, in a reversal of "piece@square" for a drop move. I don't really like this for a number of reasons:
  • It doesn't read natural. "piece@square" reads very naturally as "[drop] piece at square". However, "square@piece" doesn't suggest "lift piece from square".
  • The piece information is redundant, all that is needed is the square (there can only ever be one piece on a square)
  • It re-uses '@', which so far I've always treated as indicating that a move is a "drop". Not a very convincing argument, perhaps, but I would personally prefer something else.
The way I have currently implemented this is "piece^square"; the ^ is meant to suggest an upward arrow so this reads more closely as "lift piece from square". It still suffers the redundancy of having the piece in there, but on the other hand, with the piece in there the move is again 4 characters long, which is sortof nice. Using "^square" may be better though.

To play "twilight", the following commands work:

Code: Select all

variant twilight
level 40 1:00 0
to set a time control of 40 moves in 1 minute, with 0 seconds increment. Sjaak will keep track of its own time, but it will not call the flag and it will get confused if you switch sides or take back a move.

As per usual, please let me know about any issues you run into (many thanks to those of you who have submitted bug reports: most of the problems that are listed above as fixed would not have been found as quickly if it was just me by myself). Also, do let me know about any feature requests you may have.
User avatar
hgm
Posts: 28503
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Sjaak II - beta release!

Post by hgm »

Evert wrote:
hgm wrote: Is it really necessary to ship 7MB of C++ std library with Sjaak II ? This makes the package exceed the allowed size for an e-mail attachment... :cry:
Unfortunately.
I tried static-linking, but the compiler complains that it can't find a suitable static replacement:

Code: Select all

Linking CXX executable sjaakii.exe
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libstdc++.dll.a when searching for -lstdc++
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libstdc++.a when searching for -lstdc++
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libstdc++.a when searching for -lstdc++
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libstdc++.dll.a when searching for -lstdc++
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libstdc++.a when searching for -lstdc++
/usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lstdc++
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc_eh.a when searching for -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc_eh.a when searching for -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc_eh.a when searching for -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc.a when searching for -lgcc
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc.a when searching for -lgcc
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc.a when searching for -lgcc
/usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lgcc
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc_eh.a when searching for -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc_eh.a when searching for -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc_eh.a when searching for -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lgcc_eh
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc.a when searching for -lgcc
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc.a when searching for -lgcc
/usr/libexec/gcc/x86_64-w64-mingw32/ld: skipping incompatible /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/libgcc.a when searching for -lgcc
/usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
make[2]: *** [sjaakii.exe] Error 1
make[1]: *** [CMakeFiles/sjaakii.dir/all] Error 2
make: *** [all] Error 2
Looks like a problem with the compiler set-up, but I haven't been able to figure out how to fix it yet...
Has this problem already been solved? I would like to release an update for the WinBoard mini-Shogi package containing Sjaak II.

I don't understand why static linking should be the solution. The whole idea of having a MinGW compile is that it would use the standard MicroSoft C(++) dynamic libraries that are always present on Windows systems, so that you get binaries that are not dependent on the ported libraries cygwin1.dll etc.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: Sjaak II - beta release!

Post by Evert »

hgm wrote: Has this problem already been solved? I would like to release an update for the WinBoard mini-Shogi package containing Sjaak II.
Not yet, I haven't really had time to look into it. I've also been sitting on updating the version to 1.0 (I think I have all the features I wanted for that).
I don't understand why static linking should be the solution. The whole idea of having a MinGW compile is that it would use the standard MicroSoft C(++) dynamic libraries that are always present on Windows systems, so that you get binaries that are not dependent on the ported libraries cygwin1.dll etc.
Well, first of all, you can give it a try and see whether it works without the DLL. It doesn't work for me (under Linux) but I never tried a real Windows system.
Bear in mind though that despite the name (MinGW) the situation here is a bit different: I'm actually using a cross-compiler under Linux rather than a native Windows compiler. If the missing library is just a standard runtime library, I would expect it to be part of Wine rather than MinGW, which it doesn't seem to be. Again though, I never tested this on an actual Windows system.

Note also that I don't have a similar problem with Jazz, which is plain C. It just seems to be an issue with the C++ standard library. The GNU version may just be incompatible with the Microsoft version, I don't know.