SjaakII 1.0 RC1

[hgm]

Nothing so clever. To declare perpetual checking a loss I currently just declare repetitions in general to be illegal. Check evasions are an exception and are always allowed.

But in orthodox Chess that would be very wrong. You don't score repetitions as draw there? And in self-play of Sjaak in Goro-Goro some games do end in repetitions, which should not be possible when one of them would think it is a loss.

For regular Shogi it would also be quite wrong, as non-checking repetitions there also are draw. Only mini-Shogi has this exception that Sente loses in case of repetition.

But even if everything doesn't work perfectly now, the question remains: how will it be decided which variant uses what rule. Should it be set from the game-definition file, and what are the associated commands. Or is it derived from the parent variant. (I guess that would give a problem for mini-Shogi, but you have that as a built-in.)

[Evert]

Nothing so clever. To declare perpetual checking a loss I currently just declare repetitions in general to be illegal. Check evasions are an exception and are always allowed.

But in orthodox Chess that would be very wrong. You don't score repetitions as draw there?

Of course I do. It's set per variant.

And in self-play of Sjaak in Goro-Goro some games do end in repetitions, which should not be possible when one of them would think it is a loss.

For regular Shogi it would also be quite wrong, as non-checking repetitions there also are draw. Only mini-Shogi has this exception that Sente loses in case of repetition.

Actually, I spoke too quickly: I disallow repetitions in mini-Shogi, but not in regular Shogi (which actually means that Sjaak will see nothing wrong with going for a perpetual there). I guess the situation is rare.

But even if everything doesn't work perfectly now, the question remains: how will it be decided which variant uses what rule. Should it be set from the game-definition file, and what are the associated commands. Or is it derived from the parent variant. (I guess that would give a problem for mini-Shogi, but you have that as a built-in.)

Sjaak doesn't have a concept of "parent variants", the rules have to be specified in the configuration file (if they're different from the defaults).

I've made a few minor tweaks to it now so you can specify the number of repeats needed to claim the game ended, but basically the way it works is this:

Code: Select all

Rule: checkmate = win
Rule: stalemate = draw
Rule: repeat3 = draw

for orthochess, and

Code: Select all

Rule: repeat4 = draw

for Shogi-like. The variants.txt now includes those explicitly for the duplication of FIDE chess (where they're optional, since those are the default settings) and the repeat4 is for Judkins Shogi (where it isn't optional).

Looking into scoring perpetuals now.

[hgm]

Well, a poor-man's way to discourage perpetuals is to score repeated positions as a loss for the stm when they are reached by a check evasion and as a win when they are a check (when the normal result is a draw). Perhaps you should already reserve a keyword

Rule: perpetual = loss

for this, even when the implementation leaves to be desired, so that the games can already be defined with this, and then automatically become correct once you fix the implementation.

By default perpetual would be equal to repeat3/4.

Note that it is actually a bit controversial what the true rule is. Obviously you would have to test all moves of the repeat loop for being checks. (In Xiangqi there even is the possibility for mutual perpetual check, because of the Cannons, and in Chess the presence of Nightriders would also cause this, so you would have to do the test for both sides, and declare draw anyway when they are both checking on all moves.) But the issue is from where to where? It is in theory possible that a check position part of a perpetual loop is visited before as an isolated check, and after a lot of shuffling revisited, after which you started a perpetual there to force a 3rd and 4th occurrence. Should this now count as a perpetual or not? I think it should, but Takeshi Ito thinks not.

[myfish]

Just to butt in here and hi there by the way...

I was introduced to sjaak II by HGM who has been very gracious in support with a variety of my shogi and shogi variant needs and wants.

Right now, I have 2 versions of goro goro working in xboard / sjaak II with and without a lance/knight handicap.

Both play, sort of.

However, we do get issues with illegal moves that are in fact, perfectly legal and I see this is already being addressed. Thanks.

However, the issues surrounding draws and losses in repeated move sequences is a tougher one.

In shogi and it's many variants, the general rule is one of 4 times repeat = draw whilst 4 times repeated sequence in constant checking environment is a loss for the 'checker'. The former however CAN contain checks, just not perpetual checks to the limit.

The idea of adding draw/check configurations per variant is a good one and I await a release where this is working.

[Evert]

Well, a poor-man's way to discourage perpetuals is to score repeated positions as a loss for the stm when they are reached by a check evasion and as a win when they are a check (when the normal result is a draw). Perhaps you should already reserve a keyword

Rule: perpetual = loss

for this, even when the implementation leaves to be desired, so that the games can already be defined with this, and then automatically become correct once you fix the implementation.

By default perpetual would be equal to repeat3/4.

This is pretty much exactly what I have now, except you should specify

Code: Select all

Rule: perpetual = illegal

(perpetual = loss would probably work the same in practice though, but it's treated a bit differently).

Note that it is actually a bit controversial what the true rule is. Obviously you would have to test all moves of the repeat loop for being checks. (In Xiangqi there even is the possibility for mutual perpetual check, because of the Cannons, and in Chess the presence of Nightriders would also cause this, so you would have to do the test for both sides, and declare draw anyway when they are both checking on all moves.) But the issue is from where to where? It is in theory possible that a check position part of a perpetual loop is visited before as an isolated check, and after a lot of shuffling revisited, after which you started a perpetual there to force a 3rd and 4th occurrence. Should this now count as a perpetual or not? I think it should, but Takeshi Ito thinks not.

I think I see "perpetual check" as a particular type of chase, and if I wanted to do it properly I would probably implement it as one where the chased piece has to be royal. That would mean in practice that I can alternately chase a king and a rook indefinitely. Seems against the spirit of the idea though.

[Evert]

Just to butt in here and hi there by the way…

Hello!

I was introduced to sjaak II by HGM who has been very gracious in support with a variety of my shogi and shogi variant needs and wants.

Right now, I have 2 versions of goro goro working in xboard / sjaak II with and without a lance/knight handicap.

Both play, sort of.

However, we do get issues with illegal moves that are in fact, perfectly legal and I see this is already being addressed. Thanks.

That somewhat depends on what illegal moves you're seeing. Could you be more specific?

There is one specific circumstance where I see illegal moves from SjaakII in Shogi, and that is if it does not have enough time to search all moves (which basically means it's probably screwed anyway). This isn't a Shogi-specific problem, but it's the only variant I've tested extensively where I've seen this problem (presumably Crazyhouse would have the same problem). It only happens at short time controls.

However, the issues surrounding draws and losses in repeated move sequences is a tougher one.

In shogi and it's many variants, the general rule is one of 4 times repeat = draw whilst 4 times repeated sequence in constant checking environment is a loss for the 'checker'. The former however CAN contain checks, just not perpetual checks to the limit.

Ok, so it is a chase with the condition that the chased piece is a king. I can implement that properly, but it'll have to wait a while. Avoiding perpetuals should work in the development build though, which should be good enough to play.

The idea of adding draw/check configurations per variant is a good one and I await a release where this is working.

Should be soonish, but I'll probably have to end up calling it "1.0 release candidate 4" rather than "1.0" as I had originally planned, since by now it contains quite a few changes compared to the last one.

[myfish]

I think I see "perpetual check" as a particular type of chase, and if I wanted to do it properly I would probably implement it as one where the chased piece has to be royal. That would mean in practice that I can alternately chase a king and a rook indefinitely. Seems against the spirit of the idea though.

Need to be careful here.

You could in theory and practice, with enough pieces, chase a check right around the board and it would be perfectly legal.

However, checking and rechecking in steps that repeat would be a loss to the checker.

[hgm]

I think Keith was still using the latest version on your download page, not the fixed one from the link published here, and that the illegal-move problem he refers to was caused by the = suffix for deferral.

I think I see "perpetual check" as a particular type of chase, and if I wanted to do it properly I would probably implement it as one where the chased piece has to be royal. That would mean in practice that I can alternately chase a king and a rook indefinitely. Seems against the spirit of the idea though.

Well, you can do that, both in Xiangqi and Shogi. "One check, one chase" is perfectly allowed in XQ, as would be alternately chasing two different non-royal pieces.

Or do you mean the case where two opposing pieces mutually chase each other? This is allowed in XQ for non-royal pieces, where it usually occurs for Rook vs Horse. When one side chases a King, and the other side a non-royal (e.g. perpetually checking a King with a Rook, while the King has two Rooks behind it, so that moving away the King discovers a counter attack on the unprotected checking Rook) would mean a loss for the checker.

[Evert]

I think Keith was still using the latest version on your download page, not the fixed one from the link published here, and that the illegal-move problem he refers to was caused by the = suffix for deferral.

Ok, that's good to know.

I think I see "perpetual check" as a particular type of chase, and if I wanted to do it properly I would probably implement it as one where the chased piece has to be royal. That would mean in practice that I can alternately chase a king and a rook indefinitely. Seems against the spirit of the idea though.

Well, you can do that, both in Xiangqi and Shogi. "One check, one chase" is perfectly allowed in XQ, as would be alternately chasing two different non-royal pieces.

Or do you mean the case where two opposing pieces mutually chase each other? This is allowed in XQ for non-royal pieces, where it usually occurs for Rook vs Horse. When one side chases a King, and the other side a non-royal (e.g. perpetually checking a King with a Rook, while the King has two Rooks behind it, so that moving away the King discovers a counter attack on the unprotected checking Rook) would mean a loss for the checker.

I was actually thinking of the following situation: the position is repeated, and the chase-detection returns a number of pieces that are being chased, which include a king and a non-royal. However, the scenario doesn't make sense: if the king is marked as a chased piece, then you're checking it on every leg of the chase. If you interrupt the checking of the king to attack another piece, you break the chase. So the situation I was thinking of can't actually occur.

However, I gather that the chase rules in Shogi are a bit different in that you are allowed to chase the king perpetually, as long as you don't simply go back-and-forth?

[myfish]

I think Keith was still using the latest version on your download page, not the fixed one from the link published here, and that the illegal-move problem he refers to was caused by the = suffix for deferral.

Which has now been rectified. New version now compiled.