Sjaak II - beta release!

[Ferdy]

Game between Nebiyu-Sjaak.
Sjaak could have claimed sente(white) has repeated the position 3x and gote(black) won, the position has appeared 4x with black to move. The perpetual check rule is really not the issue since white could have make a different move. Sjaak is gote(black) and it can afford to repeat positions.

This is not how it works. The game really ends at the 4th repeat of Nebiyu, and Sjaak could have claimed there. But it should still have claimed a loss for itself, because all its moves since the first occurrence of this position have been checks. So it is engaged in perpetual checking, which is explicitly forbidden as primary rule. The 4th-repetition issue is only a clarification on when exactly a sequence of moves is considered 'perpertual', but never alters who is checking.

Only when some of his moves since the original occurrence of the position would not have been checks the 'sente-loses' rule would kick in.

The reason I let XBoard adjudicate only one move later is that the official rule is formulated a bit vague, not as "the checking side loses" but as "the checking side should alter his move". I am not sure if my interpretation is correct, but it seemed safer to let the GUI never claim too early.

The game really ends at the 4th repeat of Nebiyu, and Sjaak could have claimed there.

That is my point, there was an infraction on repetition by Nebiyu in the first place.

It seems to me that the perpetual check rule is lighter than the repetition rule, because this is a game where one way to win games is to deliver a checkmate and you can not do a checkmate if you will not check your opponent. In a situation where the side under check has no other legal moves except moving its king to evade, and yet after evasion there is another check, king evades, check again and so on without delivering a checkmate (buggy program), then that could be charged as perpetual checking. The side that is under checked should adjust, and not the checking side, because this is a game of checkmating. Delivering a checking move without losing much but would attempt to deliver a final checkmate after series of checking moves that may appear perpetual initially should not be discouraged. But that repetition should be more discouraged of course, unfortunately only sente is punished.

[Evert]

That is my point, there was an infraction on repetition by Nebiyu in the first place.

It seems to me that the perpetual check rule is lighter than the repetition rule,

It seems to me that the rules directly contradict this.

I had a look at what Pritchard says about the matter this morning, and he says that perpetual check is forbidden, and the checking party must break the repetition. The chase rules in Xiangqi are similar in that you're not allowed to perpetually check, even if doing so gets you mated.

because this is a game where one way to win games is to deliver a checkmate and you can not do a checkmate if you will not check your opponent.

My understanding was that there is no such thing as "checkmate" in this game, and you win by capturing the enemy king (which would be a problem if Sjaak had to do that on the board, because it will never do that).

In a situation where the side under check has no other legal moves except moving its king to evade, and yet after evasion there is another check, king evades, check again and so on without delivering a checkmate (buggy program), then that could be charged as perpetual checking.

Perhaps.
My understanding is that this is the case if the position is repeated. I think you're allowed to check indefinitely as long as you never repeat the position. Since the board is finite, however, you can't keep that up forever...

The side that is under checked should adjust, and not the checking side,

No.

Delivering a checking move without losing much but would attempt to deliver a final checkmate after series of checking moves that may appear perpetual initially should not be discouraged. But that repetition should be more discouraged of course, unfortunately only sente is punished.

If you can deliver mate, you can do so without ever having to repeat the position. Of course, you may miss it the first time and then never find it because you think the repeat is illegal, but you get similar issues with repetitions in orthochess (although there you can only lose half a point over it). In practice I don't think this will break things very often.

[hgm]

Well, even making a good argument why the rules should be different will not alter the rules that are applied in the UEC Cup, so we better play by those, even when we consider them illogical.

There are only few sources for the rules of mini-Shogi, and even fewer non-Japanese. The UEC website has an English page, which says this:

Code: Select all

[b]Sennichite: fourfold repitation[/b]

In Mini-shogi, a fourfold repetition (千日手 sennichite) is required to end in "Sente (先手 Black） loses".Each player must have the same pieces in hand as well as the same position on the board.The result is "Sente （先手 Black） loses" unless one player is giving perpetual check;in that case, that player loses.

This seems pretty unambiguous to me. After Nebiyu's move there was a four-fold repetition, and one player was giving a perpetual check. So the 'unless' clause applies.

This rule is imported from regular Shogi, though, and I am sure there must be lots more info available on that. The only differense there is that the "Sente loses" must be replaces by "Game is a draw". But what is considered perpetual checking and what not is supposed to be exactly the same.

Perpetual checking is known as "Oute Sennichite", and is always lost by the side that is checking. The point of the rule is that you should not be able to avert a loss by perpetual checking. Who starts it (and thus repeats first) is not relevant.

When you don't believe me, ask Takeshi Ito. He will adjudicate the games...

[Ferdy]

I had a look at what Pritchard says about the matter this morning, and he says that perpetual check is forbidden, and the checking party must break the repetition. The chase rules in Xiangqi are similar in that you're not allowed to perpetually check, even if doing so gets you mated.

So he does not say that the checking side must break the checking? In mini shogi repetition is allowed for gote, but not for sente(white), unless one player is giving perpetual check, that player loses.

Can you also ask how many checks exactly is perpetual? It may happen that same position 4x may appear before one can say that one side is doing probably perpetual checks.

[hgm]

Can you also ask how many checks exactly is perpetual? It may happen that same position 4x may appear before one can say that one side is doing probably perpetual checks.

There is no limit. You are allowed to give 100,000 checks. As long as you do not repeat. As soon as you start repeating the same checks, it becomes a perpetual. The burden of proof that he can still give more checks without repeating is on the checker. There is no obligation on the checked side to help him with that.

[hgm]

@Evert:

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...

[Evert]

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...

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...

[hgm]

Well, I managed to get the new package to Takeshi Ito after all. It seems the attachment size limit on my local mailer is not as strict as from the web-mail. (The package was 3.34MB now in stead of 1.32MB for WB plus the other 4 engines.)

As Sjaak II is open source, I guess the best long-term solution is to have it compile by someone who runs Windows and knows how to make state-of-the-art compiles there. (Too bad Jim Ablett is no longer around. I only have a 32-bit gcc 3.4, so I cannot do it myself.)

[Edit] I just played Sjaak II 131 against the Lima update, and Sjaak lost due to repetition without anything being captured.


And perhaps this is just personal taste, but I think it is really annoying that Sjaak puts double spaces between the moves of its PV. It makes that I can see fewer moves in the small space I usually have available for it, and as an attempt to align the moves of subsequent PVs in columns it is a bust anyway, because the font used in the Engine Output window is proportionally spaced.

[hgm]

This is the game:

Code: Select all

[Event "Computer Chess Game"]
[Site "MAKRO-PC"]
[Date "2014.11.21"]
[Round "-"]
[White "Sjaak II 131"]
[Black "Lima v1-41 64bit POPCNT"]
[Result "0-1"]
[TimeControl "1200"]
[Variant "shogi"]
[FEN "rbsgk/4p/5/P4/KGSBR[-] w 0 1"]
[SetUp "1"]

{--------------
r b s g k
. . . . p
. . . . .
P . . . .
K G S B R
white to play
--------------}
1. Sd2 {+0.21/19} Sb4 {+0.04/17 1:00} 2. Bc2 {+0.26/19 41} Gd4
{+0.04/16 28} 3. Gb2 {+0.20/19 57} Bc4 {+0.19/15 20} 4. Rd1 {-0.02/18 42}
Rd5 {+0.04/14 18} 5. Rb1 {-0.07/17 34} Ra5 {+0.87/15 13} 6. Rd1
{+164.99/2 0.1} Rd5 {+99.99/17 26} 7. Rb1 {+164.99/2 0.1} Ra5
{+99.99/24 26} 8. Rd1 {+164.99/2 0.1} Rd5 {+199.99/17 25} 9. Rb1
{+164.99/2 0.1} Ra5 {+199.99/24 20} 10. Rd1 {+164.99/2 0.1}
{Xboard adjudication: repetition} 0-1

Seems the both see the repetitions, but that Sjaak has the sign wrong!

[Evert]

Well, I managed to get the new package to Takeshi Ito after all. It seems the attachment size limit on my local mailer is not as strict as from the web-mail. (The package was 3.34MB now in stead of 1.32MB for WB plus the other 4 engines.)

As Sjaak II is open source, I guess the best long-term solution is to have it compile by someone who runs Windows and knows how to make state-of-the-art compiles there. (Too bad Jim Ablett is no longer around. I only have a 32-bit gcc 3.4, so I cannot do it myself.)

That would help; my experience is that finding someone else to compile something on Windows is difficult if they can't just stick it into MSVC. I suppose I'll find a fix eventually (the compiler is a bit old, updating it may already resolve the issue).

[Edit] I just played Sjaak II 131 against the Lima update, and Sjaak lost due to repetition without anything being captured.

I'll look into it.

And perhaps this is just personal taste, but I think it is really annoying that Sjaak puts double spaces between the moves of its PV. It makes that I can see fewer moves in the small space I usually have available for it, and as an attempt to align the moves of subsequent PVs in columns it is a bust anyway, because the font used in the Engine Output window is proportionally spaced.

I understand what you mean, and I agree it's not pretty. The reason it does this is because I normally look at output in a terminal window, and it irks me even more if the moves don't line up there, so it pads the moves to something like 6 spaces each, which I think is always enough, or at least often enough that the occasional mis-match doesn't annoy me.

On the other hand - it actually uses a (slightly) different output format in its own terminal mode, so I could just remove the padding in XBoard mode without annoying myself.