Comments/Ratings for a Single Item

The rest I'm leaving them as they are no enpassant. Thanks for your help!

Hello Greg, More questions from me I'm afraid. How do I tell the AI that a piece is minor or major? I noticed the ai knows that KBvK is a draw, probably also KNvK too. I do not know about KNNvsK. I am interested in KMvK,vwhere M stands for mamluk(CW).

Oh,

also in the KJvK endgame the AI does not know how to mate. It manages the heard the king to the corner, but then it does not give the final blow.

There is an evaluation function called LowMaterialEvaluation that does a few things. It will immediately terminate the game if we are down to KNK, KBK, KNNK, and even KBBK if both Bishops are on the same color.

It will return a flat evaluation of zero for KBKB, KBKN, and KNKN but won't terminate the game. It also has a setting called KRKIsDraw that, when set, will return zero if down to KRK (for Cylindrical Chess and Omega Chess), but doesn't terminate the game (although perhaps it should.)

It will also perform specialized evaluation for KRKP, KRKB, and KRKN so that it can win those. And there is a KxK function (where x is Rook or other piece with an endgame value of 500 or more) which returns an evaluation based on how close the losing king is to the corner plus how close the two kings are together.

Basically, it assumes a piece can mate the enemy king if it has an endgame value over 500 and switches to specialized evaluation. If it's not over 500, it will not terminate the game except in those special circumstances dictated by the rules of chess. Perhaps it should for situations like King + Camel vs King. It could decide this if the last piece is colorbound I suppose.

In all other circumstances, the standard game evaluation function applies. So for King+Joker against King, I am not surprised it does not know how to win. Perhaps I should activate KxK evaluation for any x that doesn't promote... And perhaps I should activate it for multiple non-promoting pieces against a lone King. Certainly there is more work to be done here. I have wanted to make a specialized KPK function for a long time. Knowing how to win when down to only a couple of pieces is tricky business in Chess and obviously harder in a universal chess program where your pieces can be anything...

EDIT: There are also a couple of games where I turn off the LowMaterialEvaluation completely because it would not do "the right thing" (for example, Knightmate).

Can't major or minor be a user defined property of a piece?

I do not think I have expressed myself well about the joker. The K and J do manage to force the enemy king to the corner, but then it is not doing the obvious checkmating move.

Can't major or minor be a user defined property of a piece?

Sure, it could.  But is that the right thing to do?

Perhaps any non-pawn (or any piece that doesn't promote) should activate the KxK endgame evaluation.  When active, the evaluation is determined 100% by (a) material, (b) how close the weak king is to the corner, and (c) how close the two kings are together.  All other considerations are switched off.  Maybe this should apply for King+Minor vs. King also?  In which case the distinction doesn't matter.

@H. G., any thoughts on this?

Forcing the opponent's last remaining piece into a corner can never hurt. So it should probably be the dominant eval term. Fairy-Max doesn't have true PST; just a centralization bonus, and a weight for each piece type to multiply it. Originally that weight was 0 or 1, configurable by the user. When the King is bared, I now increase it to 10. I don't see any reason to discard other eval terms.

What holds to K-K distance in the bared case should probably hold for all short-range leapers. Removing their centralization drive does not help them seek out the bare King, even though it doesn't obstruct it. In Fairy-Max this was a problem in the KNFFK and KFFFK (Makruk!), where K + two pieces is enough to corner the King (and N + F even enough to trap it there), and then it had no incentive to approach the remaining piece(s), which are needed to execute the checkmate. You would probably see the same in KNNNK, certainly on large boards.

Of course forcing into a corner can backfire if it is the wrong corner (KBNK!). In Fairy-Max I solved this by switching to a centalization bonus that awards driving to another corner once the bare King visits one. The idea is that if there is a mate in the current corner, the search will always be deep enough to see it when the bare King is already trapped there.

With orthodox Kings (and a rectangular board) many pieces can be classified as minors with certainty: if they do not attack two orthogonally adjacent squares. That of course includes color-bounds. But also many more (all elementary obliques, Omega Wizard, Phoenix, Mamluk). Not all pieces that fail this test are majors, though. E.g. Silver or Wildebeest. But is seems a better criterion than piece value; the >500 criterion also gets the Wildebeest, Commoner, Gold and WD wrong. In I once made a Fairy-Max derivative 'Pair-o-Max' where I apply the color-binding and value criterion, but the user can force a piece to be considered a 'weak major'.

Other user-configured end-game properties in Pair-o-Max were 'defective pair' and 'strong defender', which could indicate KxxK or KQKx are draws, respectively.

There is also the reverse case where a heavy minor manticore can't mate!

I do not think I have expressed myself well about the joker. The K and J do manage to force the enemy king to the corner, but then it is not doing the obvious checkmating move.

Ok, I have done some testing and we were looking in the wrong place.  The reason it does not do the obvious checkmating move is because that move is not checkmate, it is stalemate.  Until that point, the computer thinks it is ahead by one Joker.  It doesn't want to trap the King in the corner with the Joker because that ends the game in a draw.

Per an earlier discussion, the Joker only has movement capabilities when its side is on the move.  When the other side is on the move, the Joker has no movements at all.  So the King in the corner cannot move, because then the Joker would be checking it.  But the King is not actually in check before it moves.  It has no legal move, so it is a stalemate.  I had not considered this situation before.  But, under the current rules, King+Joker vs. King is a draw.

From what I understand a stalemated king passes nothing to the joker. Am I correct?

I don't think this is the most natural interpretation of the Joker. I would opt for rules where the Joker keeps mimicking the previously moved piece after null move (just as it would after opponent Joker move). But that for implementation of the 'castling through check' rule the partial-move interpretation would be used: would the King be capturable if it only performed the move up to that point? The castling issue is not only relevant to the Joker. E.g. with a lame Dababba (nD) on d1, could you play O-O? I would say 'no', because after the King steps to f1, the nD could capture it. But with the King still on e1 the nD cannot capture to f1.

[Edit] Another interpretation could be that the Joker during the opponent turn it always moves as King (or whatever royal you have). A null move cannot be unambiguously assigned to any piece, but for the definition of check we could use the fiction that the royal must make it, in contexts where it matters what piece was moved.

Of course it is still a matter of taste what the Joker imitates after castling. If we consider castling a 3-step move (K+K+R), it would be most natural if it imitated the Rook.

I don't think this is the most natural interpretation of the Joker. I would opt for rules where the Joker keeps mimicking the previously moved piece after null move (just as it would after opponent Joker move).

I agree with HG. It makes sense that a joker imitating a king to be a man so KJK is exactly like KMK. 

After some more consideration I would prefer the "null move doesn't change imitation" over "null move = King move" rule. Because then it would not matter whether you define check by a second move in the same turn, or as a move after a hypothetical null move. I am afraid the concept of a null move is only natural to engine programmers.

From what I understand a stalemated king passes nothing to the joker. Am I correct?

I'm sorry, I do not understand what you are asking.  When a King is stalemated, the game is over.

I don't think this is the most natural interpretation of the Joker. I would opt for rules where the Joker keeps mimicking the previously moved piece after null move (just as it would after opponent Joker move).

There was a very long discussion about this on talkchess and another discussion here.  The way I've programmed it was the concensus at the time, and for good reasons.  I could change it, but I think you would like the results of that even less.  It would forbid a lot of King moves.  (The problem goes way beyond castling through check.)  A King cannot move to any square that is attacked -- if the Joker still has its previous powers, it is potentially attacking a lot of squares and stopping the King from moving to them, despite the fact that if he did, the Joker would no longer be able to capture him because its powers have changed.  Whether or not the Joker could actually capture the King on the next move is irrelevant.  At the time of the King's move, the Joker either still has its powers or it doesn't.  You can't have it both ways.

After some more consideration I would prefer the "null move doesn't change imitation" over "null move = King move" rule. Because then it would not matter whether you define check by a second move in the same turn, or as a move after a hypothetical null move. I am afraid the concept of a null move is only natural to engine programmers.

The Joker having the powers of the King when the other side is on the move is at least logically consistent.  I don't like it, but then again, I don't like the Joker.  Also, I don't understand why you are mentioning null move.  I'm not sure what that has to do with anything.

I don't understand the null move usage here either. The way I have made the rules, the joker has a null move only at the beginning of the game!

"null move" is not no moves. A null move is a player passing a turn without moving. This is not legal in Chess, but chess programs do it anyway as a way to cut out part of the search tree.

https://www.chessprogramming.org/Null_Move_Pruning

Oh, ok!

The FIDE "laws of Chess" define check in terms of being attacked, and 'attack' in terms of pseudo-legal moves of the pieces. This does not allow for the pseudo-legal moves to change over time, and tacitly assigns the same pseudo-legal moves to a piece whether it is its turn to move or not. So it involves the fiction that the checking side can move, even if it is not his turn. To move out of turn you would either have to do two moves in the same turn, or let the opponent pass his turn between the two moves. This is how the null move enters the discussion.

Legality of moves in FIDE in general is completely covered by the rule "it is not legal to expose your King to capture, except for capturing the opponent King". Only castling is special, in that it is additionally declared illegal when the King starts or moves over an attacked square.

'Exposing to capture"is completely unambiguous. And it definitely does not indicate the interpretation you sketch above, where the Joker would "forbid a lot of King moves". The ambiguity is what moving out of check or through check means. Note that Fergus avoided any ambiguity by stating that the Royal Queen in Caïssa Britannia can not pass through a square that it could not legally move to". This also seems the logical way to treat passing through check in the context of castling. (Except perhaps for 3-step castling, where the second step in itself would be illegal because it is not even pseudo-legal, and the phrase would have to replaced by "where it cannot legally teleport to if teleporting was a pseudo-legal King move.) The spirit of the rule is all about the King being shot down during the attempt, like e.p. capture. Like I said, this is not a Joker-specific problem; many other pieces whose pseudo-legal moves depend on context (lame leapers, hoppers) require more precise definition of when castling is allowed.

Being in check at the beginning of your turn (and moving out of it) is yet another matter. Which affects both castling legality, and the stalemate definition.

To apply these definitions to a Joker, it becomes essential to define when exactly the pseudo-legal moves of the Joker change. It cannot be at the start of a turn, as at that point it is not yet decided which piece is going to move, so you cannot know what the new moves are. Declaring it has no moves at that point comes "out of nowhere"; no other piece loses all its moves (for determing whether the opponent would castle out of check) after it finishes is move. It seems much less arbitrary to let it keep its moves until another piece actually starts moving. That would affect whether you consider the side to move to be in check or not. And thereby whether castling is legal, or whether a terminal position is checkmate or stalemate. But nothing else.

This is not legal in Chess, but chess programs do it anyway as a way to cut out part of the search tree.

Or to test for check: when passing the turn would get your King captured.

Most of this makes sense.  I'm not entirely sure -- the thread on talkchess was so long ago I don't really remember, but people much smarter than I argued the point -- but I don't really care either.  I consider the Joker itself a bad idea, so I don't care exactly how it acts so long as I can implement it without making any significant changes to the architecture of the program itself.  And I think that is doable...  It makes the implemention of the ImmitatorRule a bit more complicated because it needs to track how each side's Jokers move individually, but that shouldn't be a big deal.  I think attack detection should also be ok.

Aurelian, are you in agreement that this is how it should work?  To be clear, let's make sure I understand...  White moves a Queen.  Then black moves a Knight.  It is now white's turn again.  At this instant, for purposes of determining if the white King is in check, black's Joker still moves as a Queen.  White decides to move a Bishop.  At this moment, for purposes of deciding if white's King is in check, black's Joker moves as a Bishop.  If white's King is not in check, it is black's move again.  At this instant, for purposes of determining if black's King is in check, white's Joker moves as a Knight.

with a lame Dababba (nD) on d1, could you play O-O? I would say 'no', because after the King steps to f1, the nD could capture it. But with the King still on e1 the nD cannot capture to f1.

Now this is an interesting question.  I'm inclined to agree ... castling should not be allowed because the lame Dababba could theoretically capture the King as it moves through.  That said, that is probably not how ChessV works at present.  I guess the truly correct way to do it is to move the King to each square in sequence and ask "am I in check" at each step.  But that's expensive.  It would probably be adequate just to lift the King off the board before doing the attack detection on the squares.

White moves a Queen.  Then black moves a Knight.  It is now white's turn again.  At this instant, for purposes of determining if the white King is in check, black's Joker still moves as a Queen.

That seems consistent. If black would have moved his Joker (as a Queen) instead of the Knight, and this Joker would then have delivered a Queen-like check at the end of this move, it seems logical that you could also use it to deliver a discovered check, by unblocking it with the Knight.

It can still be freely chosen whether the Joker would mimic the last-moved piece of the opponent, or the last-moved piece period. The rules could have been such that the black Knight move switches both Jokers to Knights, instead of just the black one. This is just a different kind of imitator.

All this would only be relevant if you aim a Joker at an uncastled King, which would want to castle on that move. It seems unusua that someone would expose his King this way, so the practical difference might be awfully small.

It can still be freely chosen whether the Joker would mimic the last-moved piece of the opponent, or the last-moved piece period. The rules could have been such that the black Knight move switches both Jokers to Knights, instead of just the black one. This is just a different kind of imitator.

Hmmm... The second option would be slightly easier to implement because it's closer to how it is currently written.  It also might be easier to understand -- maybe.  But I have no strong opinion either way.

Ooo... Something else I didn't consider. Games with Jokers need to amend the FEN format. The FEN will need to store what type(s) are currently being imitated.

Use the e.p. square to indicate the last-moved piece. For true e.p. rights it would be empty, implying a Pawn must be imitated.

This is also simpler when differently colored Jokers always have the same move. Which I think is conceptually simpler anyway. So it would probably the best choice.

The Joker has to imitate the last piece moved by the opponent so if white has moved a queen then it's black's turn and the black joker has queen powers for the purpose of checking. So in KJK the joker should unambiguously move as a king. I'm not sure why the rest isn't just an implementation problem.

Thanks a lot guys for taking the time to do this for me, as I am the main beneficiary of this code!

That might technically work, but I do not see any positive in hijacking the e.p. square in this way. The ep square is used by the code handling en passant - it won't and shouldn't know anything about imitators. Sure, I could program the en passant rule to just ignore values that don't seem appropriate, but that is just a hack and hacks don't lead to long term code understandably or maintainability. And, as you note, this wouldn't even work with the scenario where different colored Jokers move differently.

Some games just need additional state information to be stored - there's no way around it. For example, Carlos Cetina's Symmetric Chess needs to store the Bishop Conversion Rule properties. I don't think you will come up with a clever way to sneak that information into existing FEN structure. (This reminds me, I need to post on that page exactly how I've extended FEN to accommodate this. Been meaning to do that for a long time now.)

But I do agree that both Jokers having the same move is conceptually simpler and therefore preferable.

Well, I don't see any trouble with both joker having the same movement powers both players don't have their turns at the same time, but honestly I don't understand the details of what you two guys are talking about. It is just that I'm very grateful that you are basically helping me design my own games!

in KJK the joker should unambiguously move as a king

Sure - there is nothing else so this is a pretty easy case.

so if white has moved a queen then it's black's turn and the black joker has queen powers for the purpose of checking

This is not the question.  The question is, after white moves a Queen, how does white's Joker move for the purposes of determing if black's King is in check (or moves through check while castling).  Does it also move as a Queen, or does it move as whatever piece black last moved?

I'm not sure why the rest isn't just an implementation problem.

There is obviously an implementation issue, but there may also be conceptual issues.  We have run into lots of questions, have we not?  And, years later, we are still not sure.  H.G. seems to think we can eliminate all ambiguity with careful definition.  And he might be right; I'm not so sure.

Thanks a lot guys for taking the time to do this for me

You're welcome.  But this is the kind of thing that we like thinking about, which is probably why we have both been working on universal chess programs for decades now :)

Oh, now I understand. After white has moved the white joker has no move as it is it's default. Check should be checked only immediately after the enemy moved. I think I had this discussion with Fergus a while ago.At least this is how I see it. But I'm quite sure that then you cannot have the same move for both jokers!

Oh, now I understand. After white has moved the white joker has no move as it is it's default. Check should be checked only immediately after the enemy moved.

Ah!  But now we're right back to exactly how ChessV is implemented now!  Where KJK is a draw, not a win...  If the Joker doesn't check the enemy, how can King+Joker possibly checkmate?

Well, I think he meant that during your own turn enemy Jokers have no move (so that you can never move into their check), but that whether they deliver check should be judged in the opponent's turn (after he released the piece, but before he pressed the clock, as it were).

Well, I think he meant that during your own turn enemy Jokers have no move (so that you can never move into their check), but that whether they deliver check should be judged in the opponent's turn (after he released the piece, but before he pressed the clock, as it were).

This does not make sense to me.  It sounds good but does not really clarify anything for me.  It might be helpful to discuss an actual situation.  In this position, black has just moved his King into the corner:

So now white's Joker moves as a King and moves to b2:

Is black's King in check or not?  If not, then that's a stalemate.  I do not think saying "whether they deliver check should be judged in the opponent's turn (after he released the piece, but before he pressed the clock, as it were)" changes anything.  Any move the black King makes, it will then be judged that he is in check, so that move is illegal.  Any move the black King makes is illegal, so the game is over.  Whether it is checkmate or stalemate is determined by whether the King is in check.  Am I missing something?

I know it's not my piece, but I would think that the Joker does check the king, since the king was the previously moved piece. It seems weird that the Joker could ever have no movement at all.

@Daniel,

This is not my piece either. I'm just using it. The joker has no movement at the beginning of the game.

@Greg,

The way I see the situation at hand (the actual situation that has started this discussion), the black king will be captured at the next move and this counts as a check to me, even if we are very technical about it, it is not. I'm afraid I have no further understanding on the matter

We can summarize this as:

• To judge whether in check at the start of your turn, the enemy Joker should be imagined to still have the move of the previous turn.
• To judge whether you are in check during or at the end of a turn, you should imagine the Joker to move as the piece that is moving in that turn.

Now Greg's example was special, because the Joker itself moved. If the white King had been on c2, the Joker on a5, and a white Knight on a4, and on the move before Queens were traded at c3, where the Knight recaptured (Na4xc3)... Is this checkmate or stalemate?

The Diagram considers it stalemate, because it lets the white Joker move as Knight after 1... Qxc3 2. Nxc3.

I think I had not understood this earlier. Now I see the conundrum.

This is a checkmate because the joker still has black queen's powers. Only after black moves the power is changed. In this case it cannot. So it is at least a stalemate. But for the reason stated above the black king is also in check.

Isn't this the same situation with having the king and joker unobstructed on the same orthogonal? This pins all rooks, queens, chancellors and so on.

@Greg,

I see why you hate the joker! And probably for similar reasons I love it!

Isn't this the same situation with having the king and joker unobstructed on the same orthogonal? This pins all rooks, queens, chancellors and so on.

No, this is different: moving a pinned piece is something the opponent punishes in his own turn, by capturing the King. The question here is whether the side that moved has delivered check with this move. Even when he does, he cannot capture the King. Because it is not his turn.

Anyway, the Diagram considers this stalemate, because the Imitator moves like a Knight. This is how I defined the I atom in XBetza:

A new atom in XBetza is I. Unlike the other atoms, it does not represent a fixed move: it stands for "all moves of the most recently moved (or imitated) piece type".

The most-recently moved piece is a Knight here. It doesn't say anywhere that the piece has to be an opponent. In your own turn it would of course be one. So this doesn't affect how the Joker moves. Just how it delivers check (which again is only important in the case of mate or castling).

• "Check threat": after making one's move, an opponent's fool becomes the same piece for one move; if the fool would thus give immediate check, the move would have been illegal, thereby preventing the piece moving ("neutralizing" it) unless it moves to block the check or take the fool.

That is from the wikipedia article about Omega chess.And the following is from my article on Apothecary Chess Modern:

The joker (jester,fool) imitates the power movement and capture of the last piece moved by the opponent.

In both cases the joker's move is update at the begining of one's move replacing the old move that has been inherited two plies ago.

So HG, I think we are talking about differnet pieces. 

Me too like Aurelian, I was not understanding the controversy. There is an old entry for the Joker in the Piececlopedia: https://www.chessvariants.com/piececlopedia.dir/joker.html where the Joker is defined relatively to the last move of the opponent. Which is Aurelian's definition I believe.

Beside this, is that discussion at the right page? It looks like if ChessV page is hijacked.

Yes, that was what I also said to Greg. There exist various kinds of Imitators. But the practical difference is very slight, as delivering check makes any difference for castling out of check (while normally you would castle before the opponent has any opportunity to check), and deciding whether a mate is checkmate or stalemate (while stalemate is usually only possible when the opponent's King is bare, in which case you will have many ways to checkmate that are not affected by the precice Imitator properties). So it is really a moot point.

Well,HG, Even the rarest of situations have to be taken into consideration.I'll wait to see what Greg has out of all of that!

Ok, I think we are all on the same page now.  Yay!  So we have three different options to choose from.  The difference is what powers of movement a Joker is considered to have when it is the other player's turn.  This only matters for purposes of deciding if that player is in check, or moves through check when castling.

Option 1: The Joker is "reinitialized" each time the owning player moves, returning to its initial state of having no moves at all.  This is how ChessV currently works, and I think the Game Courier preset as well.  Personally, I consider this a reasonable option, but it seems others do not, and it has the unfortunate consequence of meaning that King+Joker cannot checkmate a bare King.

Option 2: The Joker retains the move capabilities of the last piece moved by the opponent.  Therefore, both Jokers always have moves (except on the very first move of the game), and the two Jokers will not necessarily have the same moves.  This is consistent with the description on the Apothecary Chess Modern page.  But I don't think the description on Wikipedia is sufficient to distinguish between this and:

Option 3: The Joker imitates the last piece moved by either player.  This is how the Interactive Diagram currently works and is consistent with the description of the 'I' atom in XBetza.  (That said, I assume there is still ambiguity in the XBetza definition because of questions like whether it imitates the two-space pawn move, can capture en passant, castling, or any other game-specific rules.)

[Edit]: The diagram I posted is a checkmate in both options 2 and 3, but a stalemate in option 1.  The situation H. G. posted is a checkmate in option 2, but a stalemate in options 1 and 3.

Personally, I have no strong preference between these options.  Option 2 is slightly harder to implement but I can still do it if that's the concensus.

The ‘castling out of check’ case suggests to me another definition again: if we consider the restriction on castling out of check to be an extension of the restriction on moving through check — in effect that the K can be captured en‐passant on its starting square, upon having decided to move — then check for castling purposes would always be calculated with an effetive K move for the joker. Iow the move of the J, and whether it gives check, is defined at ‘touch move’ time.

For the case of determining checkmate or stalemate, that would mean that the J would give check with the intersection of the moves of all pieces able to move pseudo‐legally. As such KJK would still lead to checkmate, but with most other combinations of material the J would not give passive check at all. But in e.g. KJKQ the J would give passive check as a K. With more complex pieces (esp. those that can be blocked — particularly the Vulture of the large Apothecary games) this would potentially be position dependent. (And I think it's a little subtler yet in the hypothetical case of a game with both a joker and two royals with disjoint movesets)

Ofc this is probably horribly inefficient to program, provided it's even deemed to make sense (I like it for castling‐out‐of‐check restrictions, but I'm ambivalent between it and Option 2 (by Greg's numbering) for check‐/stalemate — it avoids the surprising(?) behaviour of HG's example where the J checks as a piece that's no longer on‐board, in exchange for arguably slightly greater opaciity of definition), so take it or leave it :‌)

Option 2: The Joker retains the move capabilities of the last piece moved by the opponent.  Therefore, both Jokers always have moves (except on the very first move of the game), and the two Jokers will not necessarily have the same moves.  This is consistent with the description on the Apothecary Chess Modern page.  But I don't think the description on Wikipedia is sufficient to distinguish between this and:

I think this is the implementation I want for my games! 

I don't think the XBetza definition is ambiguous. It says "all moves of the most-recently moved piece type". 'All' really means 'all', so including double-pushes and e.p. captures. (I do not consider promotion part of the move.) It also mentions that it imitates the piece type, rather than a particular piece. So it doesn't matter whether the piece that moved still was able to make its initial move; it is the Imitator that should satisfy the conditions for making the initial move.

This is also how I implemented it in the Diagram: the I atom in the move decription of the Imitator's move is simply replaced by the move description of the piece it imitates, as if the Imitator was of that piece type.

Problems could occur with piece types that do not have a fixed move, like the Elk in Elk Chess. Because the Diagram treats that as two piece types, that promote to each other depending on where they land. The implementation would then imitate the type the Elk promoted to, even if it was on a square shade where a 'unified Elk' would have moved differently. I see this more as a problem / ambiguity in the implementation / definition of the Elk than in that of the Imitator.

in effect that the K can be captured en‐passant on its starting square

This is exactly how I implemented castling in Fairy-Max and the Interactive Diagram. So these would not castle away from an adjacent enemy Imitator, even if it just had landed there through a Knight move. This is an ambiguity in the definition of castling, however. The condition for legality of castling could have been formulated as "when the King could be moved to any square between and including its origin and destination without exposing it to capture". As this describes a stay at the origin as a (null-)move of the King, a Joker should use a King move to capture it even there.

NOTE: When this conversation is concluded, I will move comments to more appropriate places (Apothecary, XBetza, etc.)

The ‘castling out of check’ case suggests to me another definition again ... 

Ofc this is probably horribly inefficient to program

Yes, I'm sorry, this is more complicated than I'm prepared to implement.  And I'm concerned people won't sufficiently understand it.  Look how hard it has been to even get everyone understanding the current issue, and we are all experienced players of chess variants.  H.G. did present another idea which we could call Option 4 - for purposes of check determination when the other side is on the move, the Joker is always considered to move as a King.  (Sorry if I'm not understanding that right.  But I don't think this will be a popular option.)

I don't think the XBetza definition is ambiguous. It says "all moves of the most-recently moved piece type". 'All' really means 'all', so including double-pushes and e.p. captures.

That means that the Interactive Diagram isn't compliant with other rules of Apothecary.  That said, I think that is fine.  It is unreasonable to expect a simple "prototype" testing engine like the ID to enforce very nuanced rules exactly for all games.  But I do think the question is not as clear as you make it out to be.  If you add a Joker to Xinagqi, how does it imitate the King?  Is it restricted to the palace?  If it is not currently in the palace, can it move?  Does it "check" the opponent king across an open file?  Only in the palace?

If you add a Joker to Xinagqi, how does it imitate the King?  Is it restricted to the palace?  If it is not currently in the palace, can it move?  Does it "check" the opponent king across an open file?  Only in the palace?

I was thinking just that, too! 

Yes, I'm sorry, this is more complicated than I'm prepared to implement

I expected as much :)

I'm concerned people won't sufficiently understand it

That is my main reservation with it as well

Look how hard it has been to even get everyone understanding the current issue, and we are all experienced players of chess variants

To be fair, most variants are in this respect noticeably simpler; temporal imitators raise some very subtle timing‐related issues that ‘normal’ pieces can easily ignore

H.G. did present another idea which we could call Option 4 - for purposes of check determination when the other side is on the move, the Joker is always considered to move as a King

Indeed, I saw. For moving out of check, this proposal is equivalent to mine as H.G. has since noted; for mate, it differs only in that the null move (per H.G.'s explanation) can be performed by any piece (with a pseudo‐legal move — though I suppose it'd be a valid simplification to allow it to simply be any piece), not just the King.

(But I don't think this will be a popular option.)

Indeed; it seems a tad artificial to me. My proposal eliminates a bit of the artifice at the expense of some definitional clarity. Which is a tradeoff that I can understand one might be reluctant to make (especially if, as in your case, one finds the J distasteful in any case ;‌) )

If you add a Joker to Xinagqi, how does it imitate the King? Is it restricted to the palace? If it is not currently in the palace, can it move? Does it "check" the opponent king across an open file? Only in the palace?

That depends on how much of the restriction is considered to be a property of the General and how much is considered a general game rule. There's no general consensus on where that line lies; I think all of the particulars you list have been interpreted in a variety of ways by different extrapolations

That means that the Interactive Diagram isn't compliant with other rules of Apothecary.  That said, I think that is fine.  It is unreasonable to expect a simple "prototype" testing engine like the ID to enforce very nuanced rules exactly for all games.  But I do think the question is not as clear as you make it out to be.  If you add a Joker to Xinagqi, how does it imitate the King?  Is it restricted to the palace?  If it is not currently in the palace, can it move?  Does it "check" the opponent king across an open file?  Only in the palace?

Indeed, I don't worry about that. The purpose of the ID is not to provide an exact implementation of any particular variant. Just to provide a set of tools that makes it possible to get a fair approximation. And, as I said, this whole issue is a moot point. You could probably play hundreds of games before you encounter a situation where a Joker check would or would not make castling illegal or would checkmate or stalemate depending on this.

In general I don't think much of rules or rule complications that have next to zero effect on actual game play. I would always go for simplicity when it does not matter.

As for a Xiangqi Joker; this doesn't seem decidable by logic. It depends on whether you consider confinement as part of the move rules, or as an independent property of the piece type. Like the Joker would not mimic the royalty either, and can use a King move to step to an attacked square any time it wants. But of course you could make rules that would mimic any properties of the last-moved piece type.

Option 2: The Joker retains the move capabilities of the last piece moved by the opponent.  Therefore, both Jokers always have moves (except on the very first move of the game), and the two Jokers will not necessarily have the same moves.  This is consistent with the description on the Apothecary Chess Modern page.  But I don't think the description on Wikipedia is sufficient to distinguish between this and:

I think this is the implementation I want for my games! 

Ok, if there are no objections, this will be the behavior of the ImitatorRule in ChessV.  (I do not really want to support different flavors of imitators if I can help it.)

As long as we are revisiting the Joker, I would also like to address the pawn issue.  I would like to avoid the Joker imitating the pawns differently in different Apothecary games if we can.  I think the easiest and cleanest way is for me to add an ability to specify a position-dependant move by a Rule so that it won't be imitated.  This way the game designer can have it either way -- as a regular MoveCapability of the piece (if you wanted it imitated) or as a Rule (if you don't).

Those sound great!

Ok, if there are no objections, this will be the behavior of the ImitatorRule in ChessV

No objections from me

as I said, this whole issue is a moot point. You could probably play hundreds of games before you encounter a situation where a Joker check would or would not make castling illegal or would checkmate or stalemate depending on this.

In general I don't think much of rules or rule complications that have next to zero effect on actual game play. I would always go for simplicity when it does not matter.

It's effectively moot in the Apothecary games, sure. Nevertheless it's not so difficult to contrive games where the issue would carry greater importance: consider a game featuring both a joker and an orphan. Such a game would have an equivalent problem with determining under which conditions the joker threatens — and thus relays moves to — the orphan, which one would imagine would have a substantially greater effect on gameplay (especially if it's a gimmick game with several of a few different imitators).

The latter case is (much like the orphan itself, and perhaps even the joker) ofc of even greater interest to problemists than variantists, and they don't really tend to have much of a presence here

consider a game featuring both a joker and an orphan

Yeow.  Just as a practical matter, a game with both a Joker and an Orphan is unlikely to ever be supported by ChessV, and that probably goes for most any universal chess engine that wasn't built specifically for that.

ChessV has fundamental movements that are handled natively by the internal move generator, but some capabilities that you would like to be intrinsic to the piece itself are implemented by special Rules that are plugged into the game.  For example, the internal move generator does not understand capture-by-advance.  So the Advancer in Butterfly Chess gets this capability via the CaptureByAdvanceRule.  The ImitatorRule doesn't "know" anything about the CaptureByAdvanceRule, so if you drop a Joker into Butterfly Chess, it will not be able to imitate the Advancer's power to capture by advance.  This is unfortunate, but it is just a practical reality.  In order for ChessV to do everything that it does as well as it does, and without bugs, some functions need to be encapsulated in a strict separation-of-concerns.

Besides, if we did contemplate a game with both of these pieces, I bet we could come up with a LOT of complex corner-cases where it isn't clear how they should interact anyway.  (But that's just a hunch.)

As for a Xiangqi Joker; this doesn't seem decidable by logic. It depends on whether you consider confinement as part of the move rules, or as an independent property of the piece type. Like the Joker would not mimic the royalty either, and can use a King move to step to an attacked square any time it wants. But of course you could make rules that would mimic any properties of the last-moved piece type.

I agree 100%.  I was just making the point that the XBetza "I" atom doesn't answer all questions.  I think the XBetza page should probably note that different implementations may vary.

What board dimensions does ChessV allow, and is that determined by the total number of squares or are there strict limits on the width and height?

What board dimensions does ChessV allow, and is that determined by the total number of squares or are there strict limits on the width and height?

Both.  You are limited to a maximum of 16 files and 16 ranks.  But there is also a limit of 192 squares, so you can't really get 16x16.  The largest size is essentially 16x12 or 12x16.  Someday this might be increased, but not any time soon.  Going to 16x16 would not be too large a code change, but it would have a performance cost for every game, even small ones.

A (late) question to Greg. In your Option 1: Option 1: The Joker is "reinitialized" each time the owning player moves, returning to its initial state of having no moves at all. This is how ChessV currently works, and I think the Game Courier preset as well. Personally, I consider this a reasonable option, but it seems others do not, and it has the unfortunate consequence of meaning that King+Joker cannot checkmate a bare King.

I have not understood how the joker is moving. I understand Option 2 and 3, but what about 1? Let's imagine the Owner moves a Rook, then the opponent moves a Pawn. How is the Joker moving now if it has no moves at all?

Both.  You are limited to a maximum of 16 files and 16 ranks.  But there is also a limit of 192 squares, so you can't really get 16x16.  The largest size is essentially 16x12 or 12x16.  Someday this might be increased, but not any time soon.  Going to 16x16 would not be too large a code change, but it would have a performance cost for every game, even small ones.

Isn't there a more sensitive choice to have a ChessVBig build separatly? This would not cut the performance for chessV small and allow users to have speed in the smaller boards case and also allow to implement 16x16 games.! 

Isn't there a more sensitive choice to have a ChessVBig build separatly? This would not cut the performance for chessV small and allow users to have speed in the smaller boards case and also allow to implement 16x16 games.! 

Sure, this could be done, but I am not enthusiastic about maintaining two versions.  And I am not sure this is a problem in practice.  There are other reasons it is not going to play Dai Shogi or Tenjiku Shogi.  I'm sure there are less crazy 16x16 games, but I still don't know how well it would work.  ChessV is well-written and modern computers are powerful but at some point exponential growth still overwhelms you.  I don't think 16x12 has even been tried.  You could try this and see how it goes.

The only game I'd like to invent of this size would be an 16x16 Chu Shogi variant, named apothecary of course. But for this it is way more important to see chu shogi in ChessV which is in itself stretchy!

I have not understood how the joker is moving. I understand Option 2 and 3, but what about 1? Let's imagine the Owner moves a Rook, then the opponent moves a Pawn. How is the Joker moving now if it has no moves at all?

Ok, one last try.  The question is how a Joker moves when it is not that player's turn.  When it is white's turn to move, how does black's joker move?  After white moves, of course black's joker moves like whatever piece white moves.  But when it is still white's turn, how does black's joker move?  Under option 1, it has no moves at all.

This usually makes no difference because black pieces don't move when it is white's turn anyway.  The only time it matters is for deciding if the current player is in check.

It is black's turn to move.  Is he in check?  That depends on how the white joker moves at this moment.  Under option 1, the white joker has no moves because it is not his turn.  So black is not in check.  The game is still over!  If black moves, then the white joker will again be able to move like a king and black will be in check.  It is not legal to move into check, so black has no legal moves and the game ends.  But it ends in stalemate, not checkmate, because he is not in check at this moment.  It would be the same outcome if the white joker could move, but was currently emulating a rook.

The way I have always looked at this is that to know whether a square is attacked by the opponent during your turn you should pass that turn, and see whether the opponent then can move there. So the question then is what the turn-pass would do for the movement capabilities of the Joker. There are several cases that could be argued for:

1. The Joker keeps its move from the previous turn, because no piece was moved during the turn pass, leaving the 'last-moved piece' just as it was. In Greg's diagram black would be stalemate if the Joker had moved to b2 through a Knight move (e.g. imitating a black Knight that just moved to b2 while capturing it). But checkmate if it had been capturing a Bishop that just moved there, as it would then still be imitating that Bishop, and thus check black.
2. The turn pass is considered a move of the King (like in Chu Shogi it would be a move of the Lion). The Joker would then always check like a King during the opponent turn. In Greg's diagram black would always be be checkmated, even if it had moved there through a Knight move (e.g. imitating the Knight that was on b2 while capturing it).
3. The Joker must imitate the null move. It would then not be able to deliver check at all, and the position would always be stalemate. (During its own turn it could still capture a King, though, through whatever move it has then.)

Thank you Greg, indeed I didn't have it. Now it's alright. Smiling, I say that I will never use a joker. Too much controversial. :=)

Both. You are limited to a maximum of 16 files and 16 ranks. But there is also a limit of 192 squares, so you can't really get 16x16. The largest size is essentially 16x12 or 12x16. Someday this might be increased, but not any time soon. Going to 16x16 would not be too large a code change, but it would have a performance cost for every game, even small ones.

I was thinking of trying some very wide boards, like 8x20 or 8x24, which would fit the 192 squares limit. Is the reason for the 16 file and rank limit that larger dimensions might be more difficult to display clearly?

The way I have always looked at this is that to know whether a square is attacked by the opponent during your turn you should pass that turn, and see whether the opponent then can move there. So the question then is what the turn-pass would do for the movement capabilities of the Joker.

1 seems most natural to me. I would think that passing a turn shouldn't count as moving a piece, so it shouldn't change the Joker's move if it is defined by the last piece moved. In a game that doesn't allow passing, passing should be considered the same as a double move by the other side.

I was thinking of trying some very wide boards, like 8x20 or 8x24, which would fit the 192 squares limit. Is the reason for the 16 file and rank limit that larger dimensions might be more difficult to display clearly?

No, this was not the primary reason.  It has to do with the size of various pre-allocated arrays.  I don't actually remember the implications of more files very clearly ... it might not be that bad.  I will take a look.  Exceeding 192 squares would be far more costly.

2. The turn pass is considered a move of the King

Option 2b: the turn pass can be made by any piece (or any piece w/ a pseudo‐legal move) on the passing side. And is thus, for mate‐detection purposes, equivalent to the intersection of all such moves.

This has the advantage of needing less off‐board state to be maintained: you only need to record what the opponent's last move was, not your own (as with e.g. en‐passant or lion anti‐trading); also a Joker cannot then give check as a piece no longer on the board, which I find a mildly surprising behaviour, and the position in Greg's diagram is unconditionally checkmate. It also matches my proposed update‐on‐touch‐move semantics, which covers castling out of or moving through check, even in the presence of multiple differently‐moving castling‐capable royals, as well as a possible rule for interacting w/ e.g. Orphans

Conversely, opt. 1 has the advantage of being considerably easier (I imagine) to implement, and probably to explain, at the expense of in some ways exhibiting more surprising behaviour. And Daniel's equation of it with a double move makes some sense (though given the context of actual double‐move variants there are possible quibbles). I imagine it'd be the most popular option.

I agree that of the options H.G. listed, 1 seems most natural; I find my opt. 2b a touch moreso, but opt. 1 is not far behind, so people's mileage may (and probably will!) vary

I would only add that H.G.'s #1 can correspond to either my Option 2 or Option 3, depending on how the Joker is defined. (Whether it emulates the last piece moved by the opponent or the last piece moved period.)

Since Aurelian has opted for Option 2, and I'm not hearing any objections (I don't think H.G.'s post really deviated from this), it would be nice to consider the matter settled - at least for Apothecary and for the "default" definition of the Joker. Other game inventors may decided to do different things of course.

EDIT: For the record, these are the potential disadvantages to this option that I've heard: (1) It requires storing state information for the type of piece last moved by both players, and (2) There are circumstances where a Joker can emulate a piece that is no longer on the board (although only when the other side is on the move).

Ok, I think we can forget about 16x16 for now.  I tried ChessV with the 16x12 Double Chess...  OUCH.  It barely works at all.  The branching factor is just too high.  Even the opening position has 72 legal moves (compared to 20 for Chess).  I suspect midgame positions could easily have over 200 although I didn't get that far.

More than 16 files is also problematic.  It would increase the size of a data structure that stores pawn information.

More than 16 files is also problematic. It would increase the size of a data structure that stores pawn information.

Thanks for looking at it anyway

What is the problem with a high branching factor? You can search less deep in a given time, of course, but that also holds for any opponent.

With alpha-beta the EBF only grows as the square root of the typical number of moves. So even if the latter is 6 times higher, the EBF would only go up by a factor 2.5.

What is the problem with a high branching factor? You can search less deep in a given time, of course, but that also holds for any opponent.

I was surprised by just how shocking slow it became.

With alpha-beta the EBF only grows as the square root of the typical number of moves. So even if the latter is 6 times higher, the EBF would only go up by a factor 2.5.

The square root growth is a theoretical value, and while it may be commonly achieved, it is certainly not guaranteed.  What I suspect is happening is this.  The board is very large, the armies start far apart, and no additional evaluation parameters have been added.  So I suspect that there are just a lot of moves where the evaluation is the same so we get way less beta cut-offs.

But it should become easier to find cut moves when the evaluation is constant. If all leaves would be evaluated as 0, the first random sequence of moves will be the PV, and every move you randomly pick in a cut node would immediately be a cut move.

@Greg, If you allow customizable low material evaluation like KMK (M is the CW), may you make it with lists like in KWWK(W is the CF)? I'm sure you though about that, too, and it is a bit late to raise this problem, but it could turn helpfull!

Hello Greg,

Have you an idea about when you will release the next ChessV version?

May you specify if the new version is ready? I am on the tip of my toes for that!

May you specify if the new version is ready? I am on the tip of my toes for that!

I'm sorry, I know you're anxious.  I will post as soon as it is ready, but I can't say when exactly that will be.

Thanks!

What would be good settings for evaluating the balance of a different armies variant? I've tried some tests with 0:30+10 and Medium variation but got conflicting results.

What would be good settings for evaluating the balance of a different armies variant? I've tried some tests with 0:30+10 and Medium variation but got conflicting results.

Your results are understandable.  Although the armies are not balanced, they are close, so you need to play a *LOT* of games to get valid results that are not swallowed up by noise.  At a time control of 30+1, you can't play many games.  And such long controls aren't necessary since with games on an 8x8 board ChessV can reach a search depth of 10 in a fraction of a second on a modern computer.  But the other thing to watch out for is that you aren't playing the same game over and over.  The search variation setting helps, but I also use different pre-calculated opening lines.  I will post more about this soon ...

How many is a lot? I did one set of 200 games and had a final score of -2, but then I tried a second set and by the time it got to 106 games the score was 62.

This is an anomalous result; if the games were really independent, the statistical error should decrease as 1/sqrt(numberOfGames). So for 106 games it would be around 4%, so that the 62/106 (=58.5%) score is about two standard deviations above equality, while the other score pointed to equality with a 3% standard error. The standard error in the differens of the two results should be about 5%, so the 58% is off a bit more than you would expect, but not extremely so.

What I often did to make the games more independent is play them as shuffle games. If you shuffle white and black independently (as seems natural for CwDA) you can create a lot of starting positions even when you leave King and corner pieces in place.

So for 106 games it would be around 4%, so that the 62/106 (=58.5%) score is about two standard deviations above equality

What I meant was that white won 62 games more than black. The actual numbers were 80 white wins, 18 black wins, and 8 draws. This was very different from the first test, where black won more, but with a much smaller margin.

Ah, I see. That is 79%, which is way outside any statistical error bar.

I think I have encountered a new situation involving the joker. I want to post a png with the position but I don't know how. Can someone tell me how to add a picure in the comments?

You just write a FEN of the position between [ fen] and [ /fen] tags, somewhere in the text of your comment.

Oklh, that is using the diagram designer, isn't it?

Indeed, it automatically invokes the Diagram Designer, with default settings. For a static image that should be good enough. You can also use the Interactive Diagram as a game viewer, by including a parameter moveList= , followed by all the moves of the game. This preloads the game in the Diagram, and you can then use the buttons in the AI panel to navigate through it.

The fen of the position, as is found in chessV, is this:

3J3k1w/10/10/8p1/2P5Pp/1S7P/5s4/10/4c4j/7BK1 w - - 0 78

but I did not manage to do it. Here J stands for joker, w stands for wizard, s stands for maasai pawn. The rest are self explanatory.

This should be close enough for discussion:

And c is a chancellor, but this actually has no importance!

The short story is that black has just captured an chancellor on h10 and white is to move. The version that I have (I think is the last one published) gives now a stalemate. The long story is that any piece moved by white leads to a king capture by black in the next move. Here actually the black chancellor on e2 has a role to play. The difference from the studies we already have is that a role is played by the white joker who inherits and transmits a king (more actually a man I think) power. Is that in the second case a checkmate or a stalemate? It looks like ChessV as white has sacrificed it's chancellor for an easy draw, but is this a way for black to checkmate the opponent? And most important how should it be? I am confused by this myself. Depending on what you can do Greg, I am ready to adjust the rules in these rare cases. The most important thing is though, that the rules are clear for everybody.

Ok, diagram updated with Chancellor.

What was White's last move? The version you have doesn't have the updated rules yet, so the black joker can't move. In the updated version, the black joker will have the ability of white's last move, which could make it a checkmate if it attacks the white king. Otherwise, it is still a stalemate under the new rules. Any piece white moves would lead to white's king being in check by the black joker. Even white moving joker (imitating a king) would make black's joker imitate a king and therefore it is still check. Since white cannot move, it's a stalemate.

Agreed, but I'm not sure if it is a different stalemate.

I have no idea what you mean

No matter about my previous comment.