Comments by HGMuller

Well, I don't read it that way. I don't even quote a precise value, I only say "more like a Rook [than like the Bishop]". That is a pretty wide margin. Of course, the larger the margin, the more undeniable the statement. I don't think that anyone would dare to deny that an FAD or WAD has a value between that of a Pawn and a Queen, even without any study.

So yes, if computer tests show that FA is very similar in value to a Bishop, and FAD similar to a Rook, the statement that FAD is far more valuable than a Bishop seems to have a large-enough safety margin to bet your life on it. Even without computer testing it should be pretty obvious; the FA and N are very similar in mobility and forwardness, and the value of N and B are well known to be very close. Having 50% more moves should count for something, methinks. So the reason I sound very confident in that posting is not only because of computer studies, but is also based on prevailing player opinion and logic reasoning, which leads to a similar conclusion.

My objection there mainly concerned that 'thinks' could also refer to just a suspicion, and is not the correct term for describing an observation. In a sense no thinking at all goes into a computer study. You just let the computers play, and take notice of the resulting score.

Well, the values that Kaufman found were B=N=3.25, R=5 and Q=9.75. So also there 2 minor > R+P (6.5 vs 6), minor > 3P (3.25 vs 3), 2R > Q (10 vs 9.75). Only 3 minor = Q. Except of course that this ignores the B-pair bonus; 3 minors is bound to involve at least one Bishop, and if that broke the pair... So in almost all cases 3 minors > Q.

You can also see the onset of the leveling effect in the Q-vs-3 case: it is not only bad in the presence of extra Bishops (making sure the Q is opposed by a pair), but also in the presence of extra Rooks. These Rooks would suffer much more from the presence of three opponent minors than they suffer from the presence of an opponent Queen. (But this of course transcends the simple theory of piece values.) So the conclusion would be that he only case where you have equality is Q vs NNB plus Pawns. This could very well be correct without being in contradiction with the claim that 2 minors are in general stronger.

BTW, in his article Kaufman already is skeptical about the Q value he found, and said that he personally would prefer a value 9.50.

If you don't recognize teh B-pair as a separate term, then it is of course no miracle that you find the Bishop on average to be stronger. Because i a large part of the cases it will be part of a pair.

I now improved the new Diagram script for recognizing checkmates faster, and it now deals with the opening threats 1.Pj6 and 1.Pj6 SE11n 2.BGi6 at 2.5 ply. It also punishes the wrong defense 1.Pj6 o11?

This version uses marker symbols for indicating the promotion/deferral choice. What do you think?

Make the images 50x50 instead of 48x48. This will stop the need to pad these images when the squares are 50x50.

I think this would be the proper solution. Most Alfaerie images are 50x50; I have no idea how some (mainly of the orthodox pieces) came to be 48x48 or 49x49. I wouldn't know how to make a palette PNG image; I usually geenrate the AlfaeriePNG images with fen2.php from SVG images, and fen2.php is based on C code I took from XBoard, which uses a function to safe a bitmap as PNG file, described as a 'toy interface' that offers little or no control of the image properties. (But it works.)

When I have time I will re-render these pieces at the proper size.

However, I did notice a bug that causes the promotion choices to replace pieces on the squares they are shown on if you select something other than a promotion choice.

OK, fixed that.

Finding the mate threats is also significantly sped up in this version, by the use of a mate-killer heuristic: once it finds a checkmate it searches the same sequence of its own moves first in order to refute alternative opponent moves. As in large variants almost all moves do the same (namely nothing to address the problem), that makes their refutation almost optimal, and partly compensates for the slowdown by lines with checks in them being searched deeper.

The search algorithm now extends the depth a full ply for the first check evasion it tries, (at any depth, not just at the horizon), and half a ply for alternative  check evasions. After 1.j6 it now finds 1... SEn11 after 1.6, 3 of 4.6 sec at 1.5/2/2.5 ply. After 2.BGi6 it then finds 2... m11 in 12 or 33 sec (2/2.5 ply). After 1... o11? it finds VGn9! in 8.6 or 14 sec (2/2.5 ply). Not yet with a mate score, but because it sees the opponent has to sac its GG to push the mate over the horizon. At 3 ply it does get the mate score in 18.6 sec.

[Edit] Oh, and the Diagram had a bug. FD and +WB did not burn when capturing other FD, because there was one @ to few in their row of the capture matrix (for the empty square). Fixed that too.

It appears almost all alfaerie GIF images are 50x50. Some (including the orthodox pieces) are 49x49. Elephants and their derivatives are even 53x50. I recall that I had once seen a 48x48 GIF too, but forgot which that was.

Almost all PNG images are 48x48, though. Only a few that I recently made (mostly compounds done by fen2.php) are 50x50. I produced many of the SVG from which these are derived, but I think Greg had a script that he used to 'bulk convert' the SVG to PNG. He must have used 48x48 in this script. Why he picked that size is unclear to me, as amongst the GIF images it is virtually non-existent.

I think it is undesirable that GIF and PNG images have different sizes. It should be our long-term goal to upgrade all images to the (anti-aliased) PNG, and having different sizes would obstruct that.

So what to do? Should I try to re-render all the alfaeriePNG at 50x50? I suppose I could make my own script for that, at least for everything that we have as SVG, and not compound or post-edited (to apply crosses and such)..

The idea of a fixed move that can be described by a notation implies a board with regular tiling. Such a tiling can have other connectivity than the usual 8-neighbor square-cell topology, e.g. hexagons or triangles. But these could have their own, completely independent system of atoms and directions, reusing the available letters for their own purposes.

I have thought about supporting hexagonal boards in the Interactive Diagram. This could be done by representing the board as a table with a column width half the piece-mage size, and give every table cell a colspan="2", in a masonic pattern. That would distort the board to a parallellogram. A numerical parameter hex=N could then specify how large a triangle to cut off at the acute corners. The board could then be displayed without border lines and transparent square shade, so that a user-supplied whole-board image with hexagons could be put up as background for the entire table. This would purely be a layout issue; the rest of the I.D. would know nothing about it. In particular, the moves of the pieces would have to be described in the normal Betza notation as if the pieces were moving on the unslanted board. E.g. a hexagonal Rook would be flbrvvssQ.

About castlings: one can of course think up any sort of crazy move, and present it as a castling option. But in orthodox Chess castling exists to fulfil a real need, rather than the desire to also have a move that relocates two pieces at once. The point is to provide a way to get your King to safety without trapping your Rook, and without having to break the Pawn shield. Sandwiching a piece between your Rook and King doesn't seem to serve a real purpose. If the piece could easily leave you could have done that before castling, and if not than it is still semi-trapped.

A more sensible novel form of castling would be where multiple piece end up at the other side of the King. E.g. when the piece next to the Rook would be a Moa ([F-W]), conventional castling is not up to the task. You would need a castling that moves the Rook to f1, and the Moa to e1, upon castling to g1 on 8x8. Of course you could argue that this is a defect of the start position, and could better be solved by choosing a setup that had a jumping piece on b1/g1.

I have rendered all images in the alferieSVG directory now as 50x50 PNG using fen2.php?s=50&p=..., in the directory /graphics.dir/alfaeriePNG50. They look like this

(The shell script I used for this is /graphics.dir/alfaeriePNG50/x, and then y to give them the desired filename.)

It would be really nice if you could deselect a piece that you have just selected in the holdings.

OK, I now implemented this both in betza.js and betzaNew.js. (Every click in the holdings was treated as a first click, to prevent you could move pieces into the holdings, or between holdings squares. But a click on the already selected piece there indeed deserves to be an exception.)

@Fergus: I can no longer upload these .js scripts through the File Manager page of the Interactive Diagrams article. I get this error message:

Upload of /home/chessvariants/public_html/membergraphics/MSinteractive-diagrams/betza.js was allowed but failed! The cause of failure is unknown.

Upload through WinSCP still works.

So, I'm thinking that having varying alpha values is available only in true color images, and that provides a reason for keeping these as true color images.

I am not really into these graphics formats, but I can imagine that the palette for historic reasons contains only up to 256 24-bit colors (i.e. RGB without alpha). I guess that with an alpha channel the number of different RGBA combinations in a typical image becomes so large that 256 would almost never be enough, so that no one bothered to define a standard for palette with alpha channel.

I have now done that too. But betzaNewer.js is experimental, and sooner or later will replace betzaNew.js and disappear itself (because it is fully compatible).

It's trying to get caib[qN] to work that would be the challenge.

Well, now that generalized burning is been written with the aid of legs behind a semicolon, another punctuation (say comma), could be used for generalized rifle capture. Burning and rifle capture are related: there is a set of captures, burning automatically does all of those that are possible, rifle capture has to select one of those. Pure rifle capture is a null move followed by the capture option. Suppose O without range would mean null move, then [O,cqN] would be a rifle-capturing Rose. There still is the issue of whether the rifle part can be optional. I would say no, as the entire moves in a Betza description are already optional. So by making it mandatory to do at least one of the rifle captures, you can still allow the move without capture by specifying it separately. Like for Odin's Forest Ox: N[N,cK].

I tried something similar, and it does work as expected using betzaNew.js. But not with betza.js. Which does surprise me, as I had not expected it to be different in this respect, so I will look into that.

And make sure to set maxPromote=0 to disable the normal promotion by zone rather than by morph.

[Edit] It appears that multiple promotion sets were never implemented in betza.js.

The promotion zone the article mentions makes no sense to me: Pawns can be moved such that they never could reach the zone. It would make more sense to have white Pawns promote where the black (non-Pawn) pieces start. So the far end of level D and E, not of A and B.

'In chess analysis, computer tools like Stockfish, Komodo, and AlphaZero help us know the importance of each chess piece during the game. They use calculations to assign a value to each piece based on factors like mobility, king safety, and board position...'(12 Sep 2023, Tato Shervashidze, Chess Coach...)

It is not only false, but it sounds like total nonsense to me. For one, AlphaZero is not comparable in any respect to Komodo or Stockfish; everything is different, and naming them in one breath already exposes the one who says this as completely ignorant on the subject of computer chess. (Which of course doesn't exclude he is a good Chess coach or has a high rating.)

In the past few years there has been a revolution in chess programming, after it had been converging to a method thought to be optimal for several decades. Initially programs were scoring positions at the leaves of a look-ahead search tree by a static (= not playing out any moves) heuristic that is now called a Hand-Crafted Evaluation. Piece values were a major part of that, often interpolated between 'opening' and 'end-game' values depending on the strength of the material still on board. The positional terms were Piece-Square Tables (accounting for mild general position dependence of piece values, without taking note of the location of other pieces, such as that Knights are poor at edges, and even poorer in corners), mobility (the actual number of moves a piece has in the current position), King safety (the number of squares around the King attacked by opponent pieces, and the value and number of these pieces), Pawn structure (passer advance, isolated / backward and doubled Pawns)

These parameters were never calculated (for orthodox Chess engines), but often were tuned. This was done by taking a large data set (like 500,000) of quiet positions from games with known result, and then tweeking all the bonuses and penalties (including piece values) that were used in the HCE until the calcuated evaluation score correlated best with the game result.

Than came AlphaZero out of nowhere, with everything completely different. It used a neural network for evaluation of positions as well as for guiding the search. This network simulates a brain with millions of cells, in some 40 layers, with tens of millions of connections between them. And they tuned the strength of those connections by having the thing play chess against itself. No one knows what each connection represents, but the result is that it eventually it could very accurately predict the winning probability for a position, apparently paying attention even to subtle strategic condiderations.

After that a hybrid form was invented: NNUE (for Easily Updatable Neural Network; no idea why they spelled it backwards...). This uses a conventional (unguided by any NN) search to calculate ahead, but at the end of each line evaluates by a NN of a peculiar design. It does not use explicit piece values, but calculates something very similar to Piece-Square Tables (which can be seen as a sort of piece values specified by location of the piece, and can simulate a plain piece value by specifying that same value on every square). Except that it does have such a PST for each location of the King. So the value of a piece cannot be dependent only on its absolute location, but also on how it is positioned relative to the King. (Well, this was invented for Shogi, and there proximity to the King is often more important than the intinsic strength of the piece type...). And it doesn't have one such a 64x64 table for each piece type, but 256 of them. And all these 256 values of each piece (on its current location, for the current King location) are than fed into a NN of 5 layers with 32 cells per layer, to combine them, until finally a single number appears at the output. This NN is then trained by tuning all the 256x64x64x6 values in the KPST, and the strength of the 4000 connections in the NN to reproduce the win probability of a huge data set of quiet positions, as good as it can.

This works, but after this no one knows what exactly the NN does. None of the values in the KPST in the optimally trained NN have the slightest resemblance to piece values as we know them. We cannot identify a King-Safety part, or a Pawn-Structure part, or a mobility part. It is just one totally integrated complete mess of totally meaningless multiplier parameters, that magically manage to conspire to give a very accurate prediction for who has the better winning chances in a given position. Stockfish and other strong engines now all use NNUE evaluation, (because they typically gain ~80 Elo compared to their original HCE), and the main development towards higher Elo comes from finding better sets for training it, or playing a little bit with the size of the NN. (Large NN can predict more accurately, but slow doen the engine, so that it cannot look as far ahead.)

The Alfils are placed such that two of the same color are bound to the same 8 squares. With as a consequence that half the squares cannot be reached by any Alfil of this color. And what is worse, these are the squares where all Alfils of the opponent are bound to. Two Alfils can never capture each other!

That seems pretty bad to me, and could make the game very drawish. By withdrawing the King to a square where no opponent Alfils can get the defender has an advantage of two Alfils, and the attacker only has 1 Dabbaba, 1 Ferz and 1 Wazir that could attack it (which the Defender also has). Trade an Alfil for the attacking Wazir, and then move to a square of another 'meta color' where you have two Alfils, and the attacker doesn't even have the Wazir anymore.

It would be better to swap the Dabbabas with the Alfils in the c- and f-files. Then each square can be reached by a single Alfil of either color.

Could you add the missing bnespearman to alfaeriePNG?

OK, done.

I don't think there is any need to show a separate image of an empty board. It is easy enough to recognize the board in the image where it has pieces on it.

The remark that "the black queen swaps places with the black king" is confusing rather than illuminating, because one could think this is an allowed move in the game. Presumably it intends to say that the initial setup is rotation symmetric rather than reflection symmetric, but the formulation doesn't make sense, because this is not an 8x8 board, there is no more commonly used start position on this board that has the black Queen and King in swapped locations, and to get from 8x8 FIDE to the given position you have to do a whole lot more than swap black King and Queen.

What does it mean that "a King cannot be checkmated"? A player is only allowed to deliver check when the opponent is left with at least one move that resolves this check? (A rule somewhat similar to the Shogi rule that you cannot checkmate by dropping a Pawn. It could also be formulated by saying checkmate is a win for the checkmated player.) [Edit] OK, I see that you answered that below. But it should be clarified in the article, not in the Comments.

'Columns' of a chess board are usually called 'files'. It would be clearer to write an explicit "(i-file for white, h-file for black)" rather than saying "(from each player's perspective)". And similar for 8th and 9th rank.

What if a normal Pawn ends up outside the central 8x8 area? Would it also promote on 12th or 5th rank, would it promote on 16th/1st rank, or can it no longer promote at all?

This is the case also in the original shatranj.

Indeed. But in original Shatranj you don't have both your Alfils on the same color, and not so many pieces are Alfils.

The piece colors don't look very aquatic to me; polution of the oceans isn't that bad yet... I would more expect something like #C0E0FF and #40D09C.

With pieces that capture as locusts it will be very difficult to checkmate a bare King, and consequently, the game will be very drawish. If my King can reach a corner (and I don't see how you could prevent me from doing that already in the opening) it has become impossible for you to win. None of the pieces can attack the corner, so my King is absolutely safe there. I can abandon all my other pieces, and it would still be draw. You can attack all squares around it, but that would stalemate me if I am in the corner, and just make me step back into the corner otherwise. (Compare the KBPK end-game with Rook Pawn and wrong Bishop.)

Variants with pieces that capture like this usually have an extra rim around the board where you are able to land after such a capture, but cannot otherwise move to (e.g. Roccoco). Of course you could declare stalemate a win. That would solve the safe-corner problem, so that you might be able to force stalemate with two Tritons. Note that Prawns, Seahorses and Nereids can never attack any edge square.

You could also make pieces check the same way as they move without capture, rather than as they capture. But that would make all checkmating of a bare King just normal Chess, which probably is less fun.