Ratings & Comments
H. G. Muller wrote on Tue, May 21, 2019 07:25 AM UTC:It would be really, really awesome to make it smart enough that, when a game starts, even if it is a user-define game through an include file, it does enough endgame table generation to make some basic decisions about this stuff, but that is probably a long way off.
I think Sjaak II makes an attempt at that. Of course there are some cases where this is obvious, such as not attacking any orthogonally adjacent squares. Beyond that heuristics quickly get as complicated as a single iteration of EGT generation, meaning that code-wise there is litlle to gain, and you might as well put the loop around it to do the full generation, if you can afford it timewise. Without full generation you would probably never see that a Silver General has no mating potential, or that the forced mate with a 'Turtle' (fhNfAbF) is almost entirely cursed because it takes on average 100 moves.
This is not out of the question; even the JavaScript generator in the checkmating applet typically needs under 100 msec to solve a 3-men 8x8 ending. And you could have the engine maintain a file where it 'caches' the conclusions from such EGT generation on disk. It could consult that file whenever a new variant is selected (or even just at the start of every game), to see if it contains data on all of the participating pieces, and if not, generate the EGT and add the data. With such a design it could even be acceptable to generate all 4-men of the participating pieces, to know what in general draws what, and which pairs of minors can checkmate. It only means that first time you use a newly defined variant it takes a few minutes to start.
A nasty aspect of EGT generation is that you don't just need the normal moves of the piece, but also the retrograde moves. For point-symmetric leapers and sliders these are the same, and even for asymmetric pieces you can just use the flipped version of the piece for the retrograde moves. But for bent sliders the moves are fundamentally different, and would need a separate provision in the move generator.
Greg Strong wrote on Mon, May 20, 2019 10:22 PM UTC:You are taking on a couple of difficult problems ...
Being able to mix-and-match pieces is obviously difficult and the CECP isn't really suitable for this. External configuration with a text file is probably what is required. It wouldn't need to be all that sophisticated if your configurablity is limited to adding new piece types. ChessV does offer a simple scripting language that will let you accomplish this. What it supports is hit-and-miss but just adding new (basic) piece types is no problem. Your ski-jump move is not presently supported however. I need to add that anyway for the Grand Accetrix Griffin, but it won't make this next release. It has been almost a year and a half since I've put out a new version and I have added so much new stuff since then that I just need to wrap up and get it out.
Knowing when to end a game due to insufficient mating material and when to return a zero evaluation is also obviously tricky. The currently released ChessV 2.1 doesn't do anything about this at all. IIRC, you can be down to two kings and it'll happily wander around until the 50-move rule is triggered. The new version is somewhat better. It knows about endings with standard chess pieces, and even includes customized evaluation for a few combinations (KRKP, KRKB, and KRKN), plus a "mop-up" evalution for lone king vs. rook or more. But throw in any non-standard pieces and it goes back to not making any decisions... King + Camel vs. King and you are back to wandering around for 50 moves with it stupidly thinking the side with the Camel is ahead (although it is smart enough to know that if the other side has a pawn then the side without and less than a rook's worth of material should be scaled down massively.) I would like to program in more smarts here, too, especially in light of all your work to quantify these endings. I now have a material hashtable so it could be done without worrying about computational cost, but probably won't get to too much of this for this version. Looking for low-hanging-fruit, like a simple piece property that says "this piece can't mate without help." It would be really, really awesome to make it smart enough that, when a game starts, even if it is a user-define game through an include file, it does enough endgame table generation to make some basic decisions about this stuff, but that is probably a long way off.
H. G. Muller wrote on Mon, May 20, 2019 09:04 PM UTC:I would think this is impossible. Diagonal moves of a certain length L have always lower average mobility than orthogonal moves of the same length: (S-L)*(S-L)/(S*S) instead of (S-L)/S, where S is the board size. They would get the same reduction factor because of board population, so blocking of moves doesn't alter that, no matter how you calculate it.
I have written a small c++ program that calculates the crowded board mobility (betza style : https://www.chessvariants.com/d.betza/pieceval/betterway.html).
For a future variant I have studied what I'd prefer for now to call 2-picket bishop and 2-picket rook. Meaning a bishop that moves at least three squares (has 2 long mandatory blind slides before) and a rook that does the same.
It seems that the 2-picket bishop is slightly stronger than a than a 2-picket rook 12x12 and I think I figured out why, but first I'm curious on other opinions. The results averaged over the board having between 10 and 84 pieces (so 75 different cases) are
2pb mobility: 4.52381
2pr mobility: 4.22735
Sure there is still the issue of colour boundness but for compund pieces it is quite an interesting observation, I think!...
H. G. Muller wrote on Sun, May 19, 2019 08:45 PM UTC:That's indeed great news! I haven't been able to do any further work on KingSlayer yet; this entire weekend I spent at the semi-annual tournament of the Dutch Computer Chess Association where my engine Spartacus scored 0 out of 7...). Now that most of the end-games have been solved, I am ready to progress with that. 'Army picking' is an issue that I have no clear idea on how exactly to implement, though. Of course I want the engine to be able to do games between all the standard armies, controlled by the CECP name of the (sub-)variant (like cwda~nutters~fide).
But I want it to be able to do more than that, because my main reason for converting KingSlayer was to be able to improve the accuracy of piece-value measurements over what Fairy-Max was capable of, by taking into account pair bonuses and mating potential in the eval, and providing a generally better level of play (to be exploited by being able to do more games of the same quality in the same time). For this reason I want to embed pieces in armies to which they do not belong, so that they are part of the only imbalance in otherwise symmetric setups. This requires 5 piece types per player (plus Pawns plus King), which should not be a major problem, since the internal piece encoding uses 3 bits for piece type (while white and black pieces are independently specified), code 0 being reserved for empty squares.
So I would need some manner to specify 5 pieces for each side, taken from the total collection of all supported pieces, independently. This would not be so much of a problem for properties of a single piece, (such as value, mating potential or color binding) which could just be copied from a table. But it is more problematic to get properties concerning multiple pieces, such as the winning prospects of 5-men end-games. If armies can be arbitrarily composed there would be 16000 of those (for 5 armies), most of which I have not calculated yet because they would consist of unnatural or impossible combination. And I want to be able to test pieces not in any of these armies as well (such as R3, RF).
Perhaps the best method would be to program a heuristic for determining the winning-prospects based on the individual properties of the participating pieces (piece value, mating potential, color binding) that roughly captures the general trends that were revealed by the EGT generation I did so far, and then supplement that with a list of exceptions located in an external file. To be fully accurate it would be enough to only have the exceptions in that file that can occur with the piece sets currently in use (which, for unconventional combinations, could be calculated by EGT generation for the purpose, if not yet available).
Perhaps I should define a general variant 'cwda', which would be entirely configurable through an external file, the latter containing the info which of the programmed pieces occur in either army, and under which single-letter ID. Where piece number 1-20 are those of the 5 standard armies, (hard-coded in KingSlayer) and 21-26 would be configurable through the same file (as any combination of possibly divergent finite-range slides).
Greg Strong wrote on Sun, May 19, 2019 04:27 PM UTC:Good news. I think I have ChessV working as a stand-alone CECP engine now. I've played a few variants with it under Winboard and it seems to be working pretty well. There's a little more that could be done but all the core functionality is there.
I haven't messed with programming Quadrox for CwDA yet but ChessV is ready when Kingslayer is (although I have not programmed understanding of all the endgames you've categorized yet...) I've also been putting a lot of work into increasing its strength. I have been playing 1600 game matches against FairyMax, Capablanca and variants, and it is now testing 106 ELO stronger than FairyMax. I haven't tested recently, but it is probably still a good 150 ELO weaker than Joker80.
H. G. Muller wrote on Fri, May 17, 2019 09:48 PM UTC:The Tamerlane Giraffe is a Gryphon with many blind steps. One could also have ski-sliders that skip several squares. In a sense the Picket is a 'lame' Ski-Bishop. And ski-sliders are a 'degenerate' case of bent sliders, which do change their step at some point (A->F or D->W), but not the direction.
IIRC an anti-slider is a piece that starts its move where the ray through it hits the board edge, and moves towards its old location from there. An equivalent way to describe that is a multi-hopper that must hop all pieces on the ray, except perhaps the last one, which it could also capture (if it is an enemy).
I know in Tamerlane chess the picket piece is a bishop that cannot move just one step but must cross the first step. What is the rook's counterpart for this piece? What about longer "blind" steps? I remember Ralph Betza naming a piece anti-rook. But I think it was different, although I don't recall the details!...
I just updated the database server to version 10 of MariaDB.
H. G. Muller wrote on Wed, May 1, 2019 09:37 PM UTC:XBoard supports Maka Dai Dai with its 19x19 board and 50 piece types? Holy crap!
Well, it depends on what is meant by 'support'. Problem is that 50 is just the number of unpromoted piece types, and that there also are a lot of promoted types (although many promote to Gold, and some not at all). The standard edition of XBoard comes with SVG images for 66 piece types, and falls just short of the mark. In the development version I have increased the number of piece types, but not the number of supplied SVG images. The additional piece types thus can only be used when external piece images are supplied by the user. (WinBoard already used that strategy for a long time, as it has fewer than 66 built-in bitmaps.) The idea was that only Shogi variants have such a large number of pieces, and that people that want to play those would want to use traditional kanji pieces rather than XBoard's default pictograms, and thus would have to supply external piece images anyway. And I added special support for kanji pieces, through a general -inscriptions option, which can define an arbitrary UTF-8 string, the characters (or pairs of characters) of which will be printed on top of the corresponding pieces (upside-down for black). So all that has to be supplied is 5 or 6 SVG images of blank Shogi tiles in various sizes, and with the aid of those XBoard can be configured for any Shogi variant.
fig 1 - XBoard using kanji-inscribed Shogi-tile images.
The piece IDs and the way the pieces promote would come from the -pieceToCharTable option, or the 'setup' command received from the engine, and likewise the initial position (and board size) from the -fen option, a PGN tag, or the 'setup' command. And the way the pieces move would come from the -men option, a PGN "VariantMen" tag or the 'piece' commands received from the engine.
I must admit I did not really try that for Maka Dai Dai Shogi; just for my own shrunken (13x13) version of it, Macadamia Shogi. Which can be done with the default pictogram pieces, already in XBoard 4.9.
For WinBoard there is the 'Alien Edition'; this really does have Maka Dai Dai Shogi as a standard variant, and contains built-in kanji and move tables for all variants up to Tai Shogi, and in two of the 18 board sizes generates mnemonic piece images from the move table. This doesn't support the dressed-letter IDs, though, so FENs do not work there.
fig 2 - part of the board of the WinBoard Alien Edition set for 'variant maka' (board size 'Petite').
fig 3 - The WinBoard Alien Edition configured for Macadamia Shogi (board size 'Mediocre').
Greg Strong wrote on Wed, May 1, 2019 06:43 PM UTC:Except for the promotions to Buddhist Spirit / Teaching King because of 'contageon' in Maka Dai Dai Shogi
XBoard supports Maka Dai Dai with its 19x19 board and 50 piece types? Holy crap!
Fairy-Max not supporting under-promotion, and only allowing promotion to the army's own superpiece, this problem so far did not occur in CwDA. I still have the feeling that this promotion to opponent piece types is an ugly solution to a non-existent problem, as the armies that supposedly would be disadvantaged by promotion to own pieces are already overly strong without that.
Yeah, I'm not sure this rule really needed to be this way. The Nutters are the ones most likely to promote to another piece since their pieces can't move backwards quickly and so a promoted piece is stuck, greatly reducing the value of promotion. But that army also seems to be over-powered and it is not obvious how to weaken it. Preventing promotion to a piece from the other army might be a good way to go, but that would be a change to the game and not just a change to the army.
Any guess when you think you'll have your new cwda engine ready for testing?
H. G. Muller wrote on Wed, May 1, 2019 04:18 PM UTC:Well, the U.S. is full of awesome places in itself. These national parks and forests are amazing. But indeed, trans-Atlantic travel is a pain.
And yes, the promotion suffix in this case would always need to be properly punctuated. This is one of the things I still have to fix in XBoard; as so far only the large Shogi variants taxed the alphabet so much that the punctuation had to be invoked, and promotion there is indicated by a '+'', I could so far ignore that problem. Except for the promotions to Buddhist Spirit / Teaching King because of 'contageon' in Maka Dai Dai Shogi. But I worked around that by using XBoards feature that allows defining a second 'nickname' ID for any piece (originally added to handle the frequently encountered non-compliant FENs for Xiangqi that use N for H and B for E) to assign letters that otherwise were in very low demand as nickname to BS and TK, and have XBoard use the ninckname as promotion suffix when the real ID has punctuation.
Fairy-Max not supporting under-promotion, and only allowing promotion to the army's own superpiece, this problem so far did not occur in CwDA. I still have the feeling that this promotion to opponent piece types is an ugly solution to a non-existent problem, as the armies that supposedly would be disadvantaged by promotion to own pieces are already overly strong without that.
Greg Strong wrote on Wed, May 1, 2019 02:01 PM UTC:Congratulations on the new kitchen, and the Cyprus vacation. That's certainly one thing I envy about Europeans - being able to pop off to so many awesome places without having to cross the Atlantic (which is a major PITA.)
Regarding SAN, for promotion, wouldn't you need to rely on presence or absense of the quote to determine which piece was being promoted to? Note that I have no strong feelings about SAN. ChessV doesn't do anything with it at present.
I was thinking. If you're making a strong engine for cwda, I think I will join in and add cwda support to Quadrox.
H. G. Muller wrote on Wed, May 1, 2019 06:52 AM UTC:Great! My kitchen is finally installed, nearly a week behind schedule due to several setbacks. (It was supposed to be finished while I was on holiday in Cyprus.) But my home is still a shambles, so it might take another week before things are back to normal here.
About the use of 'dressed letter' IDs in SAN (not really a protocol matter!): perhaps it is best to treat the punctuation just as an alternative form of disambiguation in the SAN parser. So that 'B' in the SAN move would match B, B', B", B!, ... A 'tie breaker' rule could solve cases where both a bare B and a punctuated B would match the input move, in favor of the bare B.
This would allow the user (or GUI designer) to generate the kind of SAN he likes best: either always writing puctuation, or never writing it, and rely on the usual coordinate disambiguation to indicate which piece was moved.
Greg Strong wrote on Sat, Apr 27, 2019 04:59 PM UTC:Ok, I've completed the change and everything seems to work. The two sides can now have different notations for the same piece, so long as player 1's is upper-case and player 2's is lower-case. When defining piece types when we aren't using this feature, the type notation is specified as it is for white and will automatically be changed to lower-case for black as it has always been so no existing code should break. To specify notations when the players use different ones, just put a slash in between. For example: "B'/b"
Here is a summary of what notations are now supported. A notation can be a single letter. It can be a single letter followed by ' or !. It can also be two letters. If the first letter of a two-letter notation conflicts with a single-letter notation, it must be prefixed by an underscore. Use of an underscore is permitted even if there is no conflict. The underscore is never displayed to the user.
Possible variant on that: use Q' etc. to indicate the pieces of black's starting army, and the plain letters for white's. That way, each symbol still means the same thing no matter which side it's on.
Thanks for the suggestions, but I don't think this is an improvement. With H.G.'s approach, the apostrophe is only necessary in the rare case where a pawn promotes to a piece from the other player's army. Also, his suggestion is backwards-compatible with Chess. In CwDA, if both players are playing the FIDEs, everything should be identical to chess. With this proposal, black's pieces would all have apostrophes. Sure, you could further stipulate that the apostrophe is only used for pieces not found in the other army, but that requires additional logic for no obvious benefit.
Or use English symbols QRBN for one color and German symbols DTLS for the other
I don't think this solves any problem. You could still have conflicts with other armies. Besides, what's German for Bede?
Possible variant on that: use Q' etc. to indicate the pieces of black's starting army, and the plain letters for white's. That way, each symbol still means the same thing no matter which side it's on.
Or use English symbols QRBN for one color and German symbols DTLS for the other...
H. G. Muller wrote on Fri, Apr 26, 2019 06:57 PM UTC:This is indeed the way XBoard does it; for protocol moves it forces the promotion suffix to lower case, for SAN to upper case. (Also in drop moves, btw.) In these contexts case sensitivity would not provide essential info, as it is known who is on move. I don't know any variant where one can promote to pieces of the opponent's color.
For FEN XBoard strictly adheres to the convention that upper case is white and lower case is black, even when asymmetry of the armies would not make this strictly necessary because the type already implies the color.
I don't see how this interferes with white and black using different ID for the same piece type, though. If they would take the ID from the same table they would certainly have to do a case conversion for one of the colors, or either in SAN or CECP moves. That they now take it from a twice larger table without first masking away the color info doesn't change that.
Greg Strong wrote on Fri, Apr 26, 2019 03:03 PM UTC:That is indeed a clever workaround, but it is a fairly ugly hack. So I've started the painful process of having different piece -> notation mappings for each player. Hopefully it won't be too bad.
I have hit my first road block however. It seems that communication of promotion moves in CECP always uses the lower-case. The example given in the standard documentation is "e7e8q". Clearly, this is white's move, but the q is lower-case. This far, I have always been sending in lower case. How do we address this? If I go forward with this change blindly, it will send promotion q for black but Q for white - which totally makes sense, but I'm afraid it will break engines that aren't expecting it. An alternative, which seems ok (but please check my logic here) is to send the notation for the player which is moving, but forced to lower-case. This shouldn't break anything, and it seems it will still work with what you are proposing.
H. G. Muller wrote on Thu, Apr 25, 2019 04:02 AM UTC:Well, a work-around could be to define the FIDE and Clobberer Bede as different piece types, which just happen to have the same move. (And similar for Bishop.) As IDs would only occasionally clash, this means most of the time you would need 12 piece types for CwDA, instead of 10, which is probably well within the capability of ChessV. In Fairy-Max I often have to do that too, not because of the ID, but because it doesn't automatically flip the moves of black pieces. So pieces like Pawns always have to be defined as a white and a black variety. (And this posed the problem of allowing 'different' white and black pieces with the same ID.)
Greg Strong wrote on Wed, Apr 24, 2019 08:13 PM UTC:Oh, I certainly agree with those advantages. I'm just concerned that this will require changes in tons of places. Let me look and try to get a feel for just how much changing will be required...
H. G. Muller wrote on Wed, Apr 24, 2019 08:02 PM UTC:I liked the idea because it creates complete freedom in the choice of id for any army, without having to worry about 'collisions' with other armies. Otherwise you would always get into trouble once the number of different armies gets large enough. It also looks a bit cumbersome to use unnecessary complex ids in a game between two given armies just because there exist other armies with which the ids would collide, while no actual collison occurs between any of the actually allowed pieces.
Greg Strong wrote on Wed, Apr 24, 2019 03:46 PM UTC:On vacation with only a phone so I can't type a long response. I'm sorry, but I am not in favor of this idea. ChessV expects pieces to have the same notation for both players (except for case.) It would require a lot of changes to change that. I don't mind changing things if there is a good reason but I don't like to complicate the system just to benefit one game. I am doubtful this has any real advantage outside CwDA. I think two letter notations would be best, but I understand that could be a radical change (needing to code in understanding of the prefix.) I can live with heavy use of the suffixes.
H. G. Muller wrote on Tue, Apr 23, 2019 04:24 AM UTC:This night it occurred to me that for CwDA we could adopt the convention that L' means a piece that is normally in the opponent army. Then B can be Bishop for FIDE and Bede for Clobberers, and in the extremely unlikely case FIDE would want to promote to a Bede, this would become B'.
H. G. Muller wrote on Mon, Apr 22, 2019 08:13 AM UTC:Actually, you can't count on that. A pawn may promote to any piece from either army.
O sh*t, I hadn't thought of that. Probably because it cannot happen in Fairy-Max. I still wouldn't be unhappy with the dressed-letter approach, though. Charging R and N could be R' and N', Bede could be B'. To me that doesn't look any worse than CN, RN and Bd. For the classical armies this would give: NBRQ, WFB'A, F'N'R'C, W'HSM. In almost any situation the punctuation would be irrelevant, as you would virtually never promote to Waffle, Fibnif, Woody Rook etc. So if we choose to use conventional disambiguation in SAN rather than punctuation, it would never virtually never need to disambiguate anything. And if the FEN is considered just an arbitrary string for computer consumption, it becomes irrelevant how it is done there anyway.
I use an underscore as a prefix to force recognition of two-letter notations.
I did something similar for the internal representation of start positions in my engine HaChu, using colon instead of underscore, but I wasn't very happy with the result. If auxilary symbols are used, you might as well just require all pieces to be separated by commas. (This is the notation that is also used in the TSA rule books for the various Shogi variants.) Forsyth notation was originally conceived for human reading, in newspapers. For computers it would be much more convenient to have some fixed-length format. You either don't care much about the length, (like in GUI-engine communication), or you care so much (in database applications) that FEN is hopelessly inefficient size-wise.
My problem has always been that XBoard would have to be changed in uncountable places to support even just 2-letter IDs. Which makes me inclined to consider options that objectively might not be the best. With the dressed letters the Id currently still fits in a byte, and only on reading or writing a mapping has to take place of the ASCII range 64-128 on the three other available 64-bit ranges. If I would manage to change all variables ever used to hold piece IDs to ints, I could use a similar strategy in storing mult-letter IDs e.g. as firstLetter + 256*secondLetter + ...
25 comments displayed
Permalink to the exact comments currently displayed.
Yes, I rethought it and it's probably a programming error!...