Comments/Ratings for a Single Item

That's right. I consider the X and Y thing bad design which I argued against. You can make longer jumps with [x,y] notation.

This is more a matter of taste than an objective advantage, though. The [x,y] notation needs at least 5 characters. With that many characters the XY notation can go up to [15,3] (GXXXX) or [11,11] (GYYYY). At which point the [x,y] notation already uses double digits. So the first cases where [x,y] would be more compact are [19,0] and [16,16]. It is extremely unlikey that such large leaps would be encountered in practice. (Perhaps for mapping a dual board or a two-level board on a rectangle, such as for Alice Chess.)

Even if it could be argued that [2,1] is better notation than N, it is just not Betza notation. Using multi-letter atoms for indicating atoms for which no single-letter notation exists has already been done by Betza himself (e.g. NN).

Sure, there's a subjective element to it, and I'm not actually arguing that [2,1] is better than N (I don't, that was just an example to explain how the notation works.)

The fact that it is less compact is almost meaningless to me. Easy to understand and easy to parse and implement is what I consider important. These long moves are very rare. No need to be cryptic to save a character or two. I also consider NN to be unnecessarily bad and I don't support it either. I use N0, which Betza also suggests.

Easy to understand and easy to parse and implement is what I consider important.

Well, parsing the X/Y in the Interactive Diagram was as trivial as it can get. After reading an atom and looking up the (x,y) step and default range, you have to examine the following characters anyway for being a digit that would overrule the range, or duplication to toggle the range 1<->inf. When you encounter an X in that process you just add (3,0) to (x,y) (and (2,2) for an Y), and keep looping until you encounter the digit or something else. Having to test for en entirely new (x,y) syntax would have been far more complex.

Betza notation is intrinsically more difficult to understand than (x,y) notation; you have to remember what all letters mean. If that was an argument you should not use Betza notation at all. And only having to remember that X boosts the leap by 3 steps gives you a lot of extra leaps for just remembering one more letter.

Suffice it to say I disagree with most of that but debating it is not a good use of my time. The time to debate the merits was when this came up, but instead you just did what you wanted.

Really, this is the least of it. Your XBetza has become so insanely complicated that most of it is of no use to me. There is absolutely no chance that I could implement it in a bug-free way, and some of it I don't even understand.

Fortunately, all I need to do is parse those strings that represent moves that ChessV's internal move generator is capable of anyway, and it does that with a clean subset of the grammar.

Guys, I think that both sides of the argument have merit. But it is important to have one standard. Anyway I know how to implement the NmAY in chessV so that is the most important thing. I also don't think that very long leaps will often be used, but the antelope and the giraffe should appear often enough on 12x12-16x16 boards.

Hi Greg,

In the five games I have published the joker imitating a pawn gains only it's regular move power, no double step, no en passant, no promotions. In the games that I am testing now with ChessV the double step is allowed to the joker if on the proper rank. The double step move is implemented as a move of a pawn on the second rank and, not as a first mover property. I'm prepared to change the rule here so that double step is allowed. It is not very important, and anyway it works this way and I have sample games like that. What are your thoughts on the matter so far?

Next, do you foresee any related problems? What scares me is to publish the game with a set of rules and then someone finds an exception or to implement my own program a slightly different game because of that.

I thought it would help if you can provide the code of the joker. But it is not only that it is also how the joker connects with other classes in your design. This is why I ask the broader question.

The Joker piece will normally emulate all the movements of other pieces that are handled by the internal move generator, but not movements that are enabled by Rules (en passant, castling). The pawn's double move is handled by the internal move generator so it does get emulated. I knew you didn't what that, so in the two built-in Apothecary variants I added a hack to prevent it. Unfortunately, that hack will not work with the scripting language. If the boards are the same for your new variants, you could probably derive them from 'Apothecary Chess Classic' or 'Apothecary Chess Modern' and they will inherit the hack. Otherwise I will need to give this more consideration...

Don't worry about that. I just wanted to know how it works, because of the reasons I have stated earlier. I'll allow the double move from the proper rank.

Ok, that makes the implementation cleaner. Do you want me to change the two original games? Right now they are not allowing the Joker a pawn double-move. And if a Joker makes a double move when emulating a pawn, should it be possible to capture it en passant? (This is easy - just add Joker to the EnPassantRule.VictimTypes). But a Joker cannot capture a pawn that has just double-moved en passant.

No, for historical purpose I think they should remain the same.

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.