Ratings & Comments

The page for Tigrey has now been published

I think you are making too much of this. For one, QS is never omniscient. The stand-pat assumption that the best non-capture will leave the evaluation approximately as it is, is just an assumption that is often false. There could be forks, or skewers. There could even be mate in one. Minimax turns out to be very resistant to random perturbation of a reasonably small fraction of the scores in the leaves; you must be very unlucky for such a perturbed score to affect the root score and move.

You actually defined different classes of legality, and why stop at three? Generalizing this you could have an arbitrary number of such classes. I would prefer to call these 'priority classes'. You must play a move from the highest non-empty class.

What to do is just a matter of statistics. How are the moves typically distributed over the classes, and how are the moves that typically change the evaluation distributed. In Suicide captures are class 1, small in number, non-captures class 2, large in number. The situation that there would be a class-1 move we do not want to consider in QS, which would outlaw all moves we do want to consider, because these are all class 2, never can occur. Same with Jumping Chess; the unconsidered moves are by definition class 2. Of course QS is still affected, because if there are moves to be considered, there will be no stand pat.

In Golem Chess typically all moves are class 1, and the occasional move that can be class 2 is even rare amongst captures. The logical thing to do, considering these statistics, is assume there will be class-1 moves amongst the non-captures. Unless you have reason to suspect there might be none. You would only be interested in knowing that if you did not find any class-1 captures, and when a lot of captures turned out to be illegal you could suspect that might be true for non-captures as well. (You know from the rules there cannot be any class-2 non-captures in Golem Chess.) Or you could simply know that you are in check, and that this is the reason for the large fraction of illegal moves. Especially if it is a contact check, for which the only legal non-captures can be King moves. But then you would probably extend even in QS, and the problem disappears. Otherwise you assume there will be legal non-captures, and guess their score as the current evaluation, to stand pat. It is what you always do when not in check, and the fact that there was only a capture that was discarded because it wasn't class 1 doesn't do more damage than that there occasionally is a class-1 non-capture that would score far higher than the current evaluation.

Note that the engine is very well capable of determining the distribution of moves over the various priority classes from nodes in the full-width part of the search. In particular you could make it keep track of how often there are no class-1 non-captures in the case there are no class-1 captures, and use that to decide whether to do a class-1 stand pat in QS. If there are more priority classes you would want to know what typically the highest-class non-capture is, given the highest-class capture that is available. If that is lower or equal to that of the highest-class capture, the capture can be searched, and a stand pat of the assumed highest-class non-capture can be tried only if that belongs in the same class.

It seems that the new move handler isn't updating the part of the diagram that shows which piece is selected.

I added H. G. Muller as an editor and made a note about our inactive editors.

I think you are making too much of this.

That is a disctinct possibility!  And that's why I wrote out all of that... so you could tell me if I'm on the wrong track, or overlooking the obvious.  I appreciate your time.  And, while I agree with what you've written, I'm not sure it justifies me doing anything differently.

You actually defined different classes of legality, and why stop at three? Generalizing this you could have an arbitrary number of such classes. I would prefer to call these 'priority classes'. You must play a move from the highest non-empty class.

Absolutely.  It did occur to me that one could invent a chess variant where there are even more tiers of legality...  But I'm not aware of any such game.  I've only come up with 3 instances of needing a middle ground between "legal" and "illegal".  I guess one could argue that as long as I'm making the change, I should go all the way and make an expandable hierarchy of legality.  But that seems more complicated and unnecessary.  And if it's not much more complicated, then it should be easy enough to adapt this should the need arise.  (And, while I would like to support as much as I reasonably can, it is not my goal to support anything that may come along.)

In Suicide captures are class 1, small in number, non-captures class 2, large in number. The situation that there would be a class-1 move we do not want to consider in QS, which would outlaw all moves we do want to consider, because these are all class 2, never can occur. Same with Jumping Chess; the unconsidered moves are by definition class 2. Of course QS is still affected, because if there are moves to be considered, there will be no stand pat.

I do not entirely understand this, but I think you are in agreement that "fallback legality" moves should be considered in qsearch in Giveaway and Jumping.

In Golem Chess typically all moves are class 1, and the occasional move that can be class 2 is even rare amongst captures. The logical thing to do, considering these statistics, is assume there will be class-1 moves amongst the non-captures.

I interpret this to mean that you agree that "fallback legality" moves should not be considered in qsearch in Golem Chess.

Note that the engine is very well capable of determining the distribution of moves over the various priority classes from nodes in the full-width part of the search. In particular you could make it keep track of how often there are no class-1 non-captures in the case there are no class-1 captures, and use that to decide whether to do a class-1 stand pat in QS.

Ok ... so if I understand correctly, your are not disputing that qsearch needs to be treated differently in Golem vs. Giveaway, but that, rather than a configurable variable that the programmer must set, the engine can determine this for itself.  Hopefully I got that correctly.  If so, my question is how much extra complication does this involve?  Certainly, I'd rather not add another user-configurable element if it's not necessary.  Heck, even the name of this hypothetical variable, "ConsiderFallbackLegalityMovesInQSearch", makes me a little embarassed.

Let's make sure I've isolated the questions to be decided correctly:

1. Do we need to expand beyond the standard determination of pseudo-legal moves as strictly legal or strictly illegal to account for games that have these types of "illegal unless there's nothing else" type moves?

2. If the answer to #1 is yes, do we just do as I've proposed and add a middle "fallback legality" category or do we go all the way and make a structure for any number of tiers of legality?

3. If the answer to #1 is "yes", regardless of the answer to #2, we have the issue of qsearch.  Do we have programmatic variables to determine what should be considered in qsearch, or do we determine that from statistical analysis?

Do I have this right?  And, if so, what are your answers to these questions?

I am having problems with my new preset for Suzumu Shogi. For some reason, it just keeps echoing "Please report any bugs or errors to Adam DeWitt" over and over again instead of showing the preset like it should. Any help would be greatly appreciated.

I was thinking banning burning Fire Demons and Heavenly Tetrarches (possibly allowing it if something else is burned first), but allowing these pieces to be captured directly or via igui (the latter which is a locust capture). I tried doing it with the BadZone function used in the last version, and most of the time it worked perfectly, but for some reason the part testing for the evic parameter value would cause the area move (and sometimes non-capture moves) to disappear if two burning pieces were within burning distance of their orthogonal ranging moves. Right now, I am happy with the current version. Fire Demons can still be traded, but at least now it is easier for the moving Fire Demon to grab an additional piece without risking recapture thanks to the strengthened burning ability.

International Draughts is such a game: not only is capture mandatory, but you must capture the most chips that you can.

In Suicide only non-captures are FallBackLegality, and you never want to consider these in QS. So it is a moot point. (Note, however, that the champion Draughts program Scan does consider moves that invite capture in QS, and considers a position only quiet when there are no such moves, and no captures.) In Jumping there can be captures amongst the FallBackLegality. You must consider those in QS, but only when you actually have to fall back, of course. Always consider the highest non-empty class, and none other.

You have to assign a class to standing pat, to decide whether you can do that, and whether that would be higher class than de highest non-empty class amongst the captures. Usually this can be based on statistics. For Suicide and Jumping stand pat is always FallBackLegality. So no standing pat when there are legal captures. For Golem stand-pat will be legal. So no FallBackLegal captures.

What you want to consider in QS can very well depend on variant. Beside captures one usually considers promotions. In Shogi considering promotions for pieces already in the zone is counterproductive. Promotion is almost a certainty there, and the static eval can assume, say, 90% of the value. Most Chess programs consider non-capture check evasions.

Add "&submit=Edit" to the end of the URL, and this will open up the editor without running the code.

What’s happened with promotions rule? I hadn’t seen this yesterday. And what’s happened with Shielder? (maybe I can agree (or deny) capturing from front of Shielder, but it mustn’t push Shielders). It’s intentional or bug? Probably it’s bug, but I didn’t see this on small iPhone yesterday. Maybe earlier iPhone versions don’t support, and newer do? I hope it’s bug of rules.

Sorry, but yellow X-es are captures!

I have an idea: you can turn Ox’s face to left in Stone Garden, as it was in my drawings, and make it different from Horizons. About Index it’s same. Please.

Hello Greg,

How can I add evaluations for the maasai pawn pushes?

I guess I didn't make the link clear enough (Edit: Suzumu Shogi on the Chess Variants Game Courier). What I have should work. I don't see any typos in the code. But of course I'm probably overlooking something.

Edit: I found it. Turns out the remind messages in the Post-Game sections had typos in them.

Sorry, but yellow X-es are captures!

OK, I fixed that now.

I flipped the Ox image in Horizons, because it looked too much like the Knight image in the way you had drawn it. I think piece images should be quite different even when looked at in low resolution. If I would flip the Ox here, it would become too similar to Index. Of course I could flip them both. But I don't think it is a problem that the Ox in Horizons and Stone Garden Chess look the same, although they move differently. They are also called the same, and this is actually more confusing than that the image is the same. People would not easily remember in which direction the Ox looked in another game, They might not even know the other game.

This kind of thing is usually caused by a parsing error that is due to a simple syntax error. To find out what it could be, I added "list;" to the end of your Pre-Game code and clicked Run. At the end of the first listing, I got this:

907   remind "Enter third leg of move or press Pass;
gosub legalmoves2 KING 2;
continuemove;
elseif sub stalemated king:
endif;
;end;

So, it looks like your remind statement is missing a closing quotation mark. However, looking at your actual code, I don't see it missing.

I would recommend the general debugging technique of cutting or commenting out sections of code to determine which code is causing the problem. If you cut code, paste it back in before cutting more, so that you can later paste back in all that you cut out.

Thx, but about moving of previous version of Ox, it’s just historic note.

How can I add evaluations for the maasai pawn pushes?

You can set the Forwardness Piece-Square-Table componenets.  For the regular Pawn type, it is 7 midgame and 10 endgame.  For user-defined pieces it's 0.  So you can set PSTMidgameForwardness=7 and PSTEndgameForwardness=10 to make it consistent with the Pawn.

You can look at the PSTs in the piece properties.  And you'll need to restart the program after making changes to an include file.  They are parsed at startup.

Thx, but about moving of previous version of Ox, it’s just historic note.

If you want to make historic notes about Horizons, the Horizon article would be the place to do it. Not the article about another Chess variant. People intersted in Horizons might never look here, people interested in Stone Garden Chess might not be interested in Horizons, let alone in its history.

I see that your HT subroutine has a line where it refers to origin and dest instead of to #from and #to. That may be where your bug lies.

So the problem is that the Tetrarch should not be able to capture another Tetrarch when it lands on a square next to it, but should be able to capture it when it was already standing next to it, without moving? In addition to capturing one other piece?

That was what I was thinking as well, and given that the rest of the code is fine, we are probably right. Unfortunately, simply getting rid of that clause won't really solve the issue. The Heavenly Tetrarch has a unique mechanic that causes it to jump over the first square it travels over, so the preset needs to take that into account. It might be possible to get rid of it with clever use of the cond statemenet though.

Edit: Turns out I was using the wrong variables to account for the distance of the first part of the move. The values of origin and dest were updated before the move was evaluated, so the distance would always be 1 and the move would thus get rejected. I fixed this by using ori and dst instead, which stay the same for all parts of the move.

It seems that the new move handler isn't updating the part of the diagram that shows which piece is selected.

Ah yes, it wasn't. I now fixed that too.

I made an Alfaerie set for Chu Shogi that makes use of Jeremy Good's pieces. I reversed the colors, so that dark pieces are used for Black and white pieces are used for White.