Comments/Ratings for a Single Item

Hello Greg,

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

@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!

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.

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.

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.

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

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.

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

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

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.

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?

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. :=)

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

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

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.

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

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?

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.

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?

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.

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

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