Comments by HGMuller

Well, perhaps I would be less alarmist when I knew how many of these 1300 presets are actually rule-enforcing. (Or more, as the case may be...) And if the result of a discussion could be that this number could easily be raised to 1300 I would consider that 'productive'. One should never set one's aim too low, nor give up too easily.

That we are volunteers with limited time is all the more reason not to scare people away that could improve something.

And the Bishop conversion rule is not so exotic. It is just an example of a special kind of 'initial move', which does not work per individual piece, but per piece type. Perhaps such a thing deserves to be a standard option offered by a wizard, whenever one defines an initial move on a piece type. Like "can be made by all / can be made only once / can be not made only once".

@Kevin: I was mostly worrying about the existence of non-rule-enforcing presets, which I think we should not have at all. I would have thought that creating such presets would almost never present any problem, as it basically just requires specifying a board size and topology (square/hex), putting a number of piece images on a board in the desired (starting) location, or put them in a 'holdings' next to the board. This doesn't seem to require any special skills beyond those needed to use a computer in general (i.e. using mouse and keyboard). So I am shocked that you say over half of the popular CVs would be beyond your abilities. And I fear the answer to the question of how many rule-enforcing presets you would be able to make for those 107 variants.

I think this is pretty serious, because I consider you as a quite representative example of our target audience. Since you have already investigated the matter, can you give a few examples of CV traits that made you decide creating even a non-rule-enforcing preset was beyond you?

I don't see why it should ever be a problem to define a rule-enforcing preset for a CV with "just sliders/leapers on a rectangular board". Specifying a move on each of the pieces does seem a rather trivial task. And perhaps not even needed for most pieces, as the piece images could have a default move associated with them, so that you only would have to take care of this when you wanted to change that move into something unusual. I would be very surprised is CVs that use the Bishop image (say) would not have it move like an orthodox Bishop in >95% of the cases.

For the second, I would be grateful if you, Fergus, HG or anyone else tell me of any program (preferable of chess or chessvariants) that I could download.

There is Fairy-Stockfish, which is very much worth having. But it is not an independent app that goes accompanied with an installer. Just something you unzip in a folder of your choice, after which you have to point WinBoard to the executable through the Load Engine dialog, so that it can use it as an engine.

The same holds for Nebiyu, which is not as strong as Stockfish, but rather easy to configure for playing new chess variants.

This is a trial for using the Interactive Diagram for Alice Chess. Custom-supplied functions BadZone and WeirdPromotion take care of refusal of moves to squares of which the mirror square is occupied, and take care of shuttling the moved piece to the other board, respectively. The boards are separated by strip of 'hole' squares, which has to be two files wide to prevent Knights from crossing it.

I implemented e.p. capture as a move by the Pawn on the board where the doubly pushed Pawn started. This seemed the least illogical way to do it, as the e.p. square on that board will always be empty (or the double push would not have been allowed). And it is the square the double push really passed over, and thus where it could have been blocked. The move could still be illegal because the corresponding square on the other board is occupied, but that is normal for any move to an empty square in Alice Chess that would be legal on its own board. There has to be no extra rule to prevent double capture this way. This method of e.p. capture corresponds to one where the doubly pushed Pawn must first make a single retrograde step before being captured, rather than replacing its double step by a single step. That this is not the same is the fault of an Alice double push not really being two consecutive single pushes.

I still have a comment to make about the legality of moves (an aspect that the diagram doesn't address). The ambiguity here seems to be caused by not making proper distinction between legal and pseudo-legal moves, but heaping them all under the term 'legal'. A more precise description would have said that a move in Alice Chess is pseudo-legal if (before transfer) it would have been pseudo-legal in orthodox Chess on the board where it is made, and the target square on the other board is empty. And then an Alice move is legal (as usual) when it does not expose the King to pseudo-legal Alice capture. This prevents solving distant checks by interposing a piece that was on the board where the checked King resides (but then disappearing to the other board, so that the King can be captured) from being considered legal. Despite the fact that they would have been perfectly legal orthodox Chess moves on the board with the King.

Is it better than Nebiyu?

I though about castling for a while but it does not seem a good thing. It would have involved one step diagonally back which is also uncomfortable. Any thoughts are appreciated.

For this reason I did start the King in Elven Chess on the back rank, and put one of the unorthodox pieces (the Lion) in its place next to the Queen.

@Dax00: I agree completely that calculatory methods for piece values are usually no good. They qualfy as 'fact-free science'. The known values of the six orthodox pieces can be reproduced by infinitely many numerological recipes, which can be designed to give arbitrary values for any fairy piece.

I therefore do always determine piece values in an empirical way, by having a computer program play games in which the pieces are pitted against a combination of pieces of known value, and measure their performance. Through such measurements the Gryphon turned out to be worth about 8.3 on 8x8 (IIRC), on a scale where Q=9.5.

It seems pretty obvious that this piece should be far stronger than an ordinary Bishop. Even the "chiral half" of it (which only has the moves that start with a turn in the same relative direction) has on average more moves than an ordinary Bishop; on non-edge squares it in fact has the same number of moves as a Rook. With both the left-handed and the right-handed moves it doesn't really have double the number of moves, as half of the moves overlap. But even then being able to go there along two paths must be worth something extra beyond having just a single way to get there. (There is no compensation for the fact that the left-handed and right-handed moves overlap on the F-squares, though, as these moves were unblockable anyway.)

No, it would not. Betza atoms never describe null moves (unless one would have defined an atom especially for that), and even if the number of steps is variable, such as in B or R, it must at least make one step and cannot stay in place. The use of the 'a' modifier to define multiple legs doesn't alter that: each leg must at least take 1 step (and if it is a leaper leg, that would be the only step). All the moves you specified are bent two-leg moves, (they have 'fs' after the 'a'), and a Rook move isn't.

BTW, I would use gafscF instead of pafscB1; 'g' describes a range-toggle after hop, as in the Grasshopper (slide -> leap) or Contra-Grasshopper (leap -> slide). What you wrote should also work, but is a bit more cryptic. gafscF means an F step to the mount, followed by a Rook slide that can only capture.

As far as I am concerned, something is broken when doesn't fully work as it should. But this doesn't seem worth quibbling about, as long as we agree there is an issue.

It is unfortunate enough that the list of comments to the Betza Notation article gets cluttered with messages like this not directly related to the topic, and losing all relevance in a short time.

@Ben:

How do you know it is the browser? It doesn't look like it is the browser to me. In FireFox, when I press Shift during reload, it will always bypass the cache for the files the main document links to (like images or JavaScript code). And the main page will never be cached. But that does not happen here: I access chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js directly (so that the browser should never have cached it), and it still shows the old content. When I load the directory it is in, it gives the file with today's download date, so the correct file must be on the server.

When I append the requested betza.js link with a dummy CGI argument "t=19", to be sure no one can cache, I do see the altered content. But if I then omit it again, it reverts to the old content.

This happens on two browsers (FireFox and Chrome). After I use the Chrome menu to delete all cached files, I still get the old contents. I don't think it are the browsers.

I guess adding a dummy CGI argument that contains a dynamically requested time to the link in the page that refers to betza.js should fix it. But it is crazy that such a work-around would be needed.

[Edit] I added the dummy "?t=19" suffix to the link to betza.js in the Betza Sandbox comment, so that this at least uses the updated version. But it is not really a feasible solution to do that in every page that refers to the file. And when I update again the "?t=19" would be the cached version, and all the suffixes would have to be updated to a value never used before...

I discussed this once with an official of the Japanese Chu Shogi Association, who wanted to revive the interest in Maka Dai Dai Shogi, and had written a manuscript defining the 'modern' rules. He insisted that it would be the last piece captured. And for a Lion Dog he insisted that jumping two squares out to capture something, and then retract one square to capture what you jumped over, was not a legal Lion-Dog move, but that you would always have to capture what is on the adjacent square in the outgoing leg if you wanted to finish there.

It didn't make much sense to me. I would also be happy if you were allowed to choose. Of course this is all highly theoretical; no one would allow both his most-valuable pieces to be in Lion or Lion-Dog range.

Such a setup breaks the possibility to change any of the articles and their associated uploaded files, as these are not PHP scripts. It makes you entirely dependent on manual intervention, because any update will with certainty be screened from all remote clients. If you want that, notification of the site admin or an editor that such intervention is needed should be automatic; having to post requests through the comments channel clutters the comments with garbage, as is now happening to this article.

Can the submission / upload script not automatically notify an empowered person that action is required, through e-mail or some specific requesting mechanism? It would of course be even better if these scripts would invoke a program that would purge the cached version in Cloudfare automatically.

Strange anomaly

I have started an attempt to determine piece values on a 12x12 board, about which very little is known. I use Fairy-Max self-play for this. To not make the games too long, the basic start position I use consists of a FIDE army augmented with 4 Pawns (to close the Pawn rank). So the board is pretty thinly popuated. The 4 central Pawns start on 4th rank, to speed up engagement, but the 3 Pawns in each wing start on 2nd rank, to provide some King shelter. The Knights also start in a somewhat advanced position, on 3rd rank behind the central Pawns, as does the Queen (to not have too many unprotected Pawns in the start position.

To determine piece values I delete some pieces from this setup, or sometimes replace them by fairy pieces. The side with the weaker piece can be compensated by giving the opponent Pawn odds, for which I always delete the same Pawn (on the h-file). Such Pawn odds alone results in a 68-70% win of the side with the extra Pawn. I only trust results when the total advantage is closer to equality than Pawn odds.

I don't want to delete more than a single Pawn, because Pawns are highly cooperative pieces, and I cannot be sure that deleting two Pawns gives twice the advantage of deleting a single one. By always granting the same simple Pawn advantage (or none at all), I can get a reliable 'measuring stick' on which the values of other pieces can be mapped. This poses a problem if there is a gap of more than 2 Pawns in the 'piece-value spectrum', though: I cannot play those 1-on-1 without getting an imbalance that is too extreme. I solve that by also introducing fairy pieces with values in the gap, and also determine their value.

I try to avoid Bishops, (and color-bound pieces in general) because of the pair-bonus problem, which would introduce yet another unknown. Which, if not handled properly by the engine, might invalidate the results. So I tried to find a very 'Bishop-like' piece that is not color bound. My first choice was this: to break the color binding of a Bishop, I gave it Wazir moves. To compensate for that (and prevent mating potential), I take away the Ferz moves. But to not affect the more distant B moves, they can still be blocked on the F squares. (So basically this is a Tamerlane 'Picket' + Wazir.)

Such a modified Bishops beats a Knight on 12x12 (as ordinary Bishops also do). The strange thing is that when I then handicap them with Pawn odds, they still beat the Knight, by about the same score. The extra Pawn doesn't seem to help the Knight at all! I have never seen that before; normally deleting a Pawn lowers the score by about as much as the pure Pawn-odds advantage. I watched a few games, and often they end in Knight + Pawns vs modified Bishop + Pawns, where the Knights are still judged by the engine to be ahead (because there are more Pawns on their side). But the Knight then almost always loses. The 'WazirPicket' can easily prevent advance of many isolated Pawns, by guarding a diagonal. And by just stepping in front of a Pawn it attacks as well as blocks it, so that the Pawn easily falls. Even connected passers are easily destroyed this way, if they still have far to go. (And on 12x12 they usually have; I use promotion on last rank only.)

I guess the WazirPicket is just unrepresentatively dangerous to Pawns, in the absence of pieces that can protect those. (And Knights are pitifully slow on 12x12...) So that the value of opposing Pawns shrinks to almost nothing in the late end-game.

My next attempt at a non-color-bound substitute for a Bishop will only change the mF moves of a Bishop to mW, but leaves the captures in place. This will also have the advantage that it cannot be blocked on a square that it doesn't attack, so that it cannot be blocked with impunity (as lame leapers can). Such a piece cannot do more damage to Pawns than ordinary Bishops can, but the mW move does allow it to switch color on non-captures. (Hence I dubbed it Swishop.)

This is very strange. Why do you need custom evaluation for KRK in the first place? Fairy-Max had absolutely no trouble to win KRK on its normal evaluation. (Which has Rooks completely neutral, and use the parabolic centralization table for Kings.) In the latest Fairy-Max version I use what you could call custom evaluation for checkmating a bare King (it just multiplies the centralization bonus for that King by a large factor), but that was only needed for end-games with many centralizing pieces (such as KFFFK in Makruk), because these did not bother to leave the center just for driving a single piece into a corner. Checkmating with Rook is very easy on any size board; you almost need no search depth for it at all. You just shephard the King towards the corner with your Rook, keeping the latter protected from behind by your King.

I suppose you do switch off null move?

The only thing I can think of that causes what you describe is contamination of the hash score with draw scores resulting from repetitions. What happens when you disable repetition detection (accepting PV hash cutoffs)? I don't really understand how a line that makes progress could get draw scores from this, though.

Can you post a game of how it typically plays KRK? (Best would of course be one that it bungles.)

Here is thinking output from a version of Fairy-Max that doesn't use the special bare-king evaluation, for position 8/8/8/5k2/3R4/8/5K2/8 w - 0 1 :

mover viewpoint		fewer / Multi-PV margin = 0 / more
exclude: none best +tail                                          
dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
28	  #12 	121.4M	1:17.65	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Re4 Kg6 7. Rf4 Kh6 8. Kf5 Kg7 9. Kg5 Kh7 10. Kf6 Kh8 11. Kf7 Kh7 12. Rh4 
27	  #13 	61.4M  	0:40.03	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re6 Kf5 5. Re4 
26	  #12 	46.8M  	0:30.38	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
25	  #12 	28.3M  	0:18.23	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
24	  #12 	15.6M  	0:09.85	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Kg3 
23	  #12 	10.3M  	0:06.45	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
22	  #13 	7.44M  	0:04.55	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re2 Kg5 5. Re5 
21	  #14 	5.88M  	0:03.52	1. Kf3 Ke5 2. Rd3 Kf5 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Kf4 
20	  #18 	4.72M  	0:02.74	1. Kf3 Ke5 2. Rd1 Ke6 3. Kf4 Kf6 4. Re1 Kg6 5. Re3 Kf6 6. Re5 Kg6 7. Kg4 
20	  #22 	4.50M  	0:02.59	1. Ke2 Ke6 2. Kf3 Kf6 
20	+4.59 	3.68M  	0:02.07	1. Ke3 Ke5 2. Rd8 Kf5 3. Re8 Kg5 4. Ke4 Kf6 5. Re5 Kg6 
19	+4.57 	2.37M  	0:01.27	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kc6 4. Kd4 Kd6 5. Re5 Kc6 6. Rd5 Kc7 7. Kc5 Kb7 8. Rd6 Kc7 9. Kd5 Kc8 10. Ke4 
18	+4.56 	1.54M  	0:00.81	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kh5 6. Rg4 Kh6 7. Rg8 
17	+4.55 	1.12M  	0:00.57	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kg6 6. Kh4 Kg7 7. Kg5 Kh7 8. Rf7 Kg8 9. Kf6 
16	+4.54 	729185	0:00.35	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
15	+4.54 	518699	0:00.25	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
14	+4.54 	354924	0:00.15	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kc7 6. Kd5 Kd7 7. Ke5 
13	+4.53 	218794	0:00.09	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kb5 6. Kd5 Kb4 7. Ke5 
12	+4.53 	150300	0:00.06	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg5 4. Rf4 Kg6 5. Kg4 Kh6 6. Kf5 Kh5 
11	+4.52 	107753	0:00.04	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Kf4 Kf6 5. Re3 Kg6 6. Ke4 
10	+4.50 	54436  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 Kf6 
9	+4.52 	36093  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 
8	+4.51 	20251  	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 
7	+4.50 	9192    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Re8 Kf6 4. Ke4 
6	+4.49 	5719    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 
5	+4.49 	2747    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 
4	+4.48 	559      	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 
3	+4.48 	223      	0:00.00	1. Ke3 Ke5 2. Re4 
2	+4.48 	23        	0:00.00	1. Ke3 Ke5 
1	+4.49 	13        	0:00.00	1. Ke3 

You do realize that this drives up the bandwidth it requires to download the page, and increases the server load? Browsers would display a table of individual piece images without any further server access, once the complete Alfaerie set is in their browser cache. And the most commonly used pieces certainly would be, from visiting other pages on this site. Perhaps a rare piece (such as the Grasshopper) would have to requested once (from Cloudfare!), and then the user would have that cached too.

A monolythic image of the entire position would be unique for every article though, and have to be downladed. Using a PHP script to generate the image 'on the fly' means it cannot even be cached by Cloudfare.