Moderator: Ras
You can claim a draw, throughEvert wrote:Resigning seems little better than crashing...
Sjaak II version 1.0 (x86_64) compiled from source.Evert wrote: You may want to check the version number, I don't think there was a binary linked to in this thread that doesn't trip up on '=' to defer promotion that is more recent than the version that had the problem (the problem is something that I introduced when I re-wrote the move scanning to be less complicated).
I'm not sure there is.Evert wrote:I guess this is the situation that the Wikipedia page on Shogi refers to as "Impasse". It's very hard to do anything about that without resorting to special knowledge in the search and evaluation.myfish wrote: Agreed. I was speaking to someone about 'King Entering' recently and how it gets VERY hard to find mates in these situations.
If there's a simple solution, I'd be happy to hear it.
The issue with goro goro is the pieces don't really allow for any leeway in strategy when sente's and gote's pieces are laid out in opposite camps as you simply have golds, promoted knights (golds), tokins (golds), silvers (golds) etc etc.
So you are faced with a wall of pieces, all facing the wrong direction for attacks and no rearward diagonals. This was something I was surprised to see sjaaakII do in almost continuity. It didn't seem to consider, NOT promoting silver to make the mate.
I have read a number of books where it mentions the very thought of applying absolute numerical value to shogi pieces is a mistake because they all hold various values at different intersections of a game. Of course, to apply this would likely be a nightmare outside something other than an Ai and extensive knowledge of how a pawn in hand could actually be worth more than a dragon in a tesuji that follows up with threatmate or even checkmate. I suppose this is like the jigsaw conundrum of a 1000 pieces where all have equal value until you realise you only have 999.Evert wrote:Well, in simple material balance a gold is worth more than a silver, so it's not surprising that it would promote the silver at every opportunity. Having an army of golds is less useful than having a few silvers mixed in, but it's not so easy to give a general rule for that.
The other issue is that Sjaak will consider the gold to have mate potential - which is correct, as long as the defending king is in front of the gold. It doesn't take that into account. If it did, it might be enough to convince it to keep a silver around to avoid the loss of mate potential. That requires quite a bit of changes to the code though (as well as the rule of thumb that says that > 2 pieces are considered mate potential if they're not all color-bound on the same colour).
The tricky part here is that really all Sjaak knows about a variant are the rules and the piece values you give it. Everything else (whether pieces can deliver mate or not, whether pieces should be centralised or not) is derived from the rules and a set of heuristics.
However, there is an easy way to encourage it to keep a silver around: simply set the value of a promoted silver to be lower than that of a silver itself. Sjaak will then prefer to not promote the silver unless it sees an immediate benefit to doing that. It's wrong in general, but it would avoid this particular problem.
Ah, but which source? Even if it says 1.0, there are at least two source archives linked here that will show that version number: the one that I had intended to be 1.0 (until HGM rained on my parade by pointing out a couple of show-stopping bugs) and the later one that is really an SVN snapshot that still holds the 1.0 version number. At this point, they're both wrong, so I should probably take them both down.myfish wrote:Sjaak II version 1.0 (x86_64) compiled from source.Evert wrote: You may want to check the version number, I don't think there was a binary linked to in this thread that doesn't trip up on '=' to defer promotion that is more recent than the version that had the problem (the problem is something that I introduced when I re-wrote the move scanning to be less complicated).
True.hgm wrote:You can claim a draw, throughEvert wrote:Resigning seems little better than crashing...
1/2-1/2 {impasse}
At worst the GUI would forfeit you for a flase claim, which makes you off no worse than resigning. The fact that the game is still going on after a huge number of moves should actually be a strong indication that the diagnosis "impasse" is correct.
Well, I just put the code (and OS X/Linux binaries) up here: http://www.eglebbk.dds.nl/program/chess-download.htmlBtw, I am eagerly awaiting a Windows compile of the version with all those fixes you put in.
I suppose a generalisation of the 50-move rule would come in handy here: count the number of moves since you've last made "progress" to winning the game. If it's over a certain limit, declare the game a draw (quench the score if you think that's important, offer a draw, claim a draw, whatever).hgm wrote:You can claim a draw, throughEvert wrote:Resigning seems little better than crashing...
1/2-1/2 {impasse}
At worst the GUI would forfeit you for a flase claim, which makes you off no worse than resigning. The fact that the game is still going on after a huge number of moves should actually be a strong indication that the diagnosis "impasse" is correct.
Downloading now. ThanksEvert wrote:Ah, but which source? Even if it says 1.0, there are at least two source archives linked here that will show that version number: the one that I had intended to be 1.0 (until HGM rained on my parade by pointing out a couple of show-stopping bugs) and the later one that is really an SVN snapshot that still holds the 1.0 version number. At this point, they're both wrong, so I should probably take them both down.myfish wrote:Sjaak II version 1.0 (x86_64) compiled from source.Evert wrote: You may want to check the version number, I don't think there was a binary linked to in this thread that doesn't trip up on '=' to defer promotion that is more recent than the version that had the problem (the problem is something that I introduced when I re-wrote the move scanning to be less complicated).
Anyway, I also have the latest (1.0 RC4) here: http://www.eglebbk.dds.nl/program/chess-download.html
This should have all the latest fixes in it.
Yeah, I've read things like that too. Not sure I buy it though, since the same argument (piece values change and depend on what else is on the board and where everything is) applies to chess. The difference is that losing a pawn in chess is usually fatal, but in shogi it's apparently easier to get positional compensation. Larry Kaufman makes a similar argument here.myfish wrote: I have read a number of books where it mentions the very thought of applying absolute numerical value to shogi pieces is a mistake because they all hold various values at different intersections of a game.
Well, tactical threats always upset piece values, that is also true in chess. Any type of knowledge of material imbalances in Sjaak needs to derive from general principles; the only ones it has are a pair bonus for colour-bound pieces and dealing with defensive pieces (in Xiangqi)...Of course, to apply this would likely be a nightmare outside something other than an Ai and extensive knowledge of how a pawn in hand could actually be worth more than a dragon in a tesuji that follows up with threatmate or even checkmate.