Comments/Ratings for a Single Item

Ah yes, there was a bug there. I tested whether the Joker was an fI or a bI after I had already corrected the f and b meaning for the color. So that a black fI was seen as a bI. This should be fixed now.

Hello HG, I have played a game of apothecary chess-classic where the joker is defined in XBetza notation as fI. What has happened is that the black j imitating a white P went backwards instead of forwards as a normal black p would move. Can I fix that? Can you fix that, or give an option for it?

HG, I am curious about how the joker's power is calculated by the interactive's diagram AI. This seems to me a difficult task.

Now that you mention it, it puzzles me that it gets a value at all. The Diagram determines the piece values by setting up a couple of random positions, and then count the number of moves and captures a piece would have when put on every empty square of these positions. But this is done before any piece was moved, so the Joker should not have any moves at all. Yet it does seem to get a non-zero value.

But I guess the concept of piece value does not apply to the Joker at all, so no matter what value it would get, it would always be wrong. A more sensible approach would be to give the Joker the average value of all pieces of the opponent, or perhaps a weighted average that weights mobile pieces more heavily, as these woould on average be moved more often than others. So something like the sum of the squares of the piece values divided by the sum of the piece values.

But that would just be the instantaneous value of the Joker. And the value of pieces is much dominated by the instantaneous value they would get in the end-game. E.g. in the early middle game Knights and Bishops have usually many more moves than Rooks, yet trading them for a Rook at that stage provides an almost winning advantage. A Joker against just King plus Pawns would be a pretty useless piece.

It seems to me that 3-fold repetition is not detected by the current interactive diagram. Is that true?

That is true. For the purpose of getting a feel for what the game is like this didn't seem needed. The AI is pretty weak, and the human should try to beat it. If the Diagram starts repeating, it is up to the human to deviate, as a draw should be considered a success for the Diagram. The human can decide at any time whether he wants to continue the game, or abandon it.

It seems to me that 3-fold repetition is not detected by the current interactive diagram. Is that true?

HG, I am curious about how the joker's power is calculated by the interactive's diagram AI. This seems to me a difficult task.

Without table it will in general be difficult to make a sensible promotion choice automatically. Not every variant has such an obvious default choice as orthoChess. So the idea was that people who want to seriously play would always open the table. But the diagram serves more purposes than playing (which is only a recently added capability), and for showing move diagrams or an initial position the promotion function is totally unimportant. So there is no reason to show the piece table by default.

What it now does when the table is closed is indeed a bit primitive: if promoChoice starts with a letter it takes the piece with that ID; if not it takes the forelast piece in the table (assuming the user will have specified the pieces in order of increasing value, King last, an assumption that fails for the diagrams generated by the Play-Test Applet).

I was too lazy to add a lot of code here (e.g. to check which pieces are in stock) only for the purpose of ensuring that the choice was legal (but likely still unsatisfactory) with a closed table. It is not really a disaster if the user gets a wrong piece because he forgets to open the table before promoting; he can just take back the move (and the reply) with the < button, and try again. The diagram accepts illegal moves in general, so why should illegal promotion choice be an exception? And if the table is open, but no choices are available, the user can simply click another piece on the board to abort the attempted promotion.

That being said, there are prospects for improvement here. For the purpose of the AI I wrote a completely new move generator, which creates a list of pseudo-legal moves. (And that includes all pseuo-legal promotion choices.) One of the items on my to-do list is to abandon the old move generator used for highlighting, and rewrite the mouse-click handler to interpret board clicks in terms of this list, narrowing the sub-set of possible moves as more squares get clicked, until only a single one is left. That would also cure the current limitation of only a single locust victim. And promotions for which no valid choice is available would not have occurred in the list, and not have been highlighted. I don't really feel like putting much effort in a temporary solution. (This reminds me that the AI probably does not recognize such impossible promotions as delivering check, now. But that again seems a rule that would never have to be invoked in practice.)

What should be rather easy, though, is completely remove the code that handles the case of a closed table, and open the table instead when the user promotes.

[Edit] I now uploaded a new script, which does the latter. It now also recognizes the case where nothing in the table gets highlighted, and aborts the move immediately rather than inviting the player to pick a piece.

I found an issue with promotions trying to implement Grand Chess.  Here are the promotion options:

promoZone=3
promoChoice=*N*B*R*Q*M*C!P
holdingsType=1

This works correctly as long as the table is displayed so that the user must choose the type to which to promote.  If a pawn tries to move to the last rank with no promotion option, and the table is open, it will highlight the square green, but you cannot complete the move because you can't pick any option from the table.  But, with the table closed, if you move to the last rank with no promotion option available, you automatically promote to cardinal!

I am saying that the Diagram (including the AI) will work, but that the Play-Test Applet currently cannot be used to completely generate the necessary Diagram description through its 'Show HTML' button. Because there is no way to make it add the necessary setting maxPromote=2. But you can add that line by editing the HTML code it does produce afterwards. Or you could also generate the Diagram description through the Design Wizard; this does allow you to specify a value for maxPromote. And it also allows you to control the order in which the pieces are specified.

I'm not sure I understand. You seem to be saying that it will work and it will not. Do you mean the interactive diagram will work but the AI will not?

You should be able to do this by defining Pawn and Ferz as the first two pieces, setting maxPromote=2, promoZone=1, and promoChoice=W (assuming W is the ID of the War Elephant). It might still want you to indicate the 'choice' by clicking on the War Elephant in the table (which will then be highlighted in blue). But it only requires a choice when the table is opened anyway. If the table is closed it always promotes to the default piece, which is the first ID of the promoChoice string. If there is never any choice, there is no reason to open the table.

The Play-Test Applet doesn't offer an opportunity to specify a maxPromote parameter different from 1. In western Chess variants it is very rare that there is more than one promoting piece, and in the cases I knew the promotion rules for the non-Pawns are then often special. (E.g. more Shogi-like, where there is a fixed promoted form.) The Play-Test Applet has no provision for defining Shogi-type promotions (which would be controlled by the diagram parameters maxPromote and and promoOffset, rather than promoChoice.)

Such mixed promotion rules are not really supported by the Diagram proper; the Diagram can be augmented with a user-defined JavaScript function WeirdPromotion to handle such cases. This is what I used for Chess and a Half: as far as the Diagram is concerned only Pawns promote, and it enforces the promoChoice setting on those. Promotion of the other pieces is handled by having WeirdPromotion recognize when they should promote, and return the promoted version in that case. I also use that for implementing 'contageon' in Maka Dai Dai Shogi.

It is always a hard call what to include in an interface to keep it user-friendly; I don't want to deter prospective users with an enormous list of options they would almost never need.

I have been thinking for how the need for using a custom WeirdPromotion script could be reduced. I could for instance introduce a parameter contageon that would decare a list of pieces that should be treated as contageous, and by default make royal pieces immune to that. (Or also introduce a parameter immune.) And I could make mixed promotions standard by having the Diagram obey the promoChoice parameter for the first piece (presumably Pawn) even when promoOffset is non-zero, if the promoChoice is non-empty or different from a single +.

Can the ID support Shatranj Kamil X? Specifically the promotion rules - Pawn and Ferz both have mandatory promotion to War Elephant on the last rank. I read the promotion section but its not obvious to me how to do this.

The interactive diagrams are an awesome innovation by the way!

The problem is that writing a strong engine is an open-ended project, that you can easily spend all your time on for the rest of your life. No matter what you have, it can always be made stronger with more effort. But unfortunately I have only one life, and cloning has not yet be perfected.

Besides, if you want to have a really strong engine, JavaScript is a bad idea. The same algorithm implemented in C would always be significantly faster, and thus stronger.

So any effort spent in this area would be more fruitful when spent on a conventional C program like ChessV or Fairy-Max, than on a JavaScript web Applet. You can argue that the diagram is more versatile than existing multi-variant engines w.r.t. the range of CVs it can handle, but that is exactly because more effort went into expanding its possibilities, rather than increasing its playing strength. I still believe that it will be more useful to add features that would allow it to do CVs it cannot yet do (e.g. with piece drops) than to make it stronger for those it can already do.

That being said, there are many standard techniques in engine building that the diagram's AI doesn't implement yet. Such as a transposition table, move-sorting heuristics such as killer and history, check detection, null-move pruning.Perhaps at some point I will add the check detection, because it seems really a bit unbalanced that (at 2 ply) it doesn't see mate-in-1 threats against it. It would add a lot of code to do that in a way that doesn't enormously slow it down. (And if it did, it would probably be better to keep the speed and just set it for 3 ply.)

In an earlier comment you said you could build an AI that plays much stronger than the one you currently have implemented into the diagram. I know the AI in the diagram is intended to be weak, but maybe you could implement the stronger AI as a separate option and have an option to switch between weak and strong AI in the AI bar?

Well, Chu Shogi seems to be the only case where this exception exists, and it makes no sense to tailor a diagram that is intended for general use too much to one specific variant. The diagram already has a 'hook' for customizng promotion rules to a variant: the page can provide a function WeirdPromotion() for sanctioning a default promotion, or altering it. I guess it would have been better if the Chu Shogi exception for last-rank Pawn promotion would have been implemented through that. Now the Diagram does it by default, it also happens in Dai Shogi, where the rule makes no sense (and thus probably would not have applied) because it is always better to promote a Pawn to Gold when entering the zone.

Perhaps you could add a function (i.e. IsPawn(p)) to allow certain pieces to promote on the last rank? That way you can still keep the option off but allow certain pieces to promote on the last rank if need be.

Oops, I inadvertantly unbalanced parentheses when fixing the problem that in the checkmating applets it insisted the first piece should promote when the piece table was open (despite promoZone=0). Fixed now.

The newest diagram script has a script error. Here is the error message I got when putting a diagram using the new script into the repl.it IDE for HTML:

>
Script error.
>

That is correct. It does count all ranks, also the brouhaha squares. It doesn't make an exception when there are only dark squares on a rank, and brouhaha squares are still part of the board. I thought it was allowed to capture to brouhaha squares, and there is no reason why such a capture could not also be a promotion.

So you would have to define promoZone=4, and adapt the rank limits in the promoChoice string accordingly.

I played against the AI in the interactive diagram .

when a pawn of mine has reached the promotion zone the promote menu has not appeared.

My guess is that the rank with brouhaha squares is counted as the final rank so the 3rd from last is unpromotable, the 2nd from last behaves as the 3rd from last should, and so on.

Null moving can currently be done by closing the AI, moving a piece back and forth, opening the AI again and press Move. For something that perhaps is needed only once every few hundred games, that doesn't seem too much trouble. Trying to do it through the normal move-entry interface is likely to have unwanted side effects for everyone. It would already be a problem that a drag & drop null move is not distinguishable from a single click to select the piece.

It may be rare that you would skip a turn in a Shogi variant, but there are those instances where that is useful.

If you were to implement such a feature, I would suggest keeping the deselection of pieces the same, but having the squares where locust captures are possible trigger the 2nd leg code even when those squares are empty. However, it's important to differentiate between multi-moves that can br triggered by moving to an empty square and those that can only be triggered by capturing (i.e. the Lion's lion power vs. the Heavenly Tetrarch's igui move).

As far as I know, there is no easy way to skip a turn with a multi-move piece has this ability. Can this be implemented?

Do you have any suggestion for how that could be implemented? I guess that what makes it difficult is that the move-entry system makes non-destructive intermediate squares transparent, so that a back-and-forth move to an empty square only leaves a marker on the selected piece. And clicking that again deselects it. I guess I could change the priorities there, so that clicking a piece that has marked itself as target will result in a null move, rather than a deselect. It should always be possible to deselect it by clicking another piece. (And if you have no other piece, there is no reason to deselect it in the first place.) Currently it only does that if a locust victim has been specified.

But is this really important? I always though that null moves are merely a hypothetical possibility, and that in practice it would almost always be very bad to play them. The pieces that can do null moves in Shogi are so powerful that you are not very likely to get into zigzwang if you have them.

The new AI is pretty impressive. But I must ask you something. As far as I know, there is no easy way to skip a turn with a multi-move piece has this ability. Can this be implemented?