Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Earlier Reverse Order Later
Checkmating Applet[Subject Thread] [Add Response]
H. G. Muller wrote on Fri, Oct 5, 2018 08:14 AM UTC:
graphicsDir=/membergraphics/MSelven-chess/ whitePrefix=w blackPrefix=b graphicsType=png squareSize=35 symmetry=none promoZone=0 weak::vrWfF:marshall:h1 king::::h2,,d4

End-Game Tables with Fairy Pieces

I created an on-line EGT generator, which can be used to investigate mating potential of simple fairy pieces (non-divergent leaper / slider compounds) on an 8x8 board. It can also be used to practice end-games of (orthodox) King + one piece vs (orthodox) King. On my website I also added an interface where the user can define the moves of the piece he wants to investigate and then practice with. (See here.) In this comment I just set it to handle a fixed piece.

I wonder if it would be a good idea to host something like this on the CVP website. E.g. as a standard component of the Piececlopedia. An obvious problem would be that mating potential can be dependent on board size, while the piece descriptions are supposed to be board-size independent. We could also devote an article to it with a more flexible version (which can do all kinds of pieces, like on my website), but I am afraid it would be buried there just as much as it would be buried on my website or in this comment. If it wouldn't at least get a special mention in the topical index, I think we might as well not bother at all.

Some Challenges, for Fun

I have been toying with this a bit, to address the following questions:

  • What is the weakest piece that still has mating potential on an 8x8 board?
  • What would be the piece that might require most time to force such a mate in the worst case?
The Interactive Diagram above shows my attempt to answer the first question: a leaper with only 5 moves seems to be able to do the job. The moves are a subset of those of an orthodox King; in fact it is a Gold General that cannot step orthogonally to the left. There is a fairly large number of positons that are drawn, because the piece is isolated from its King, and can be chased by the bare King until it runs into the board edge, and is lost. (The same holds for a normal Gold General, but to a lesser extent.) But with the strong side to move, 9 out of 10 of all possible positions is a forced win. It is not proven that this is actually the least mobile (and thus presumably least valuable) piece with mating potential, so someone might come up with something even weaker.

For the second question I came up with the fhNfAbFbD. Although this must be a pretty strong piece (9 moves, very good forwardness, speed faster than Knight forward, and faster than King backward, reasonably good manoeuvrability.) This apparently needs up to 97 moves to force checkmate! Any move I deleted to handicap it would make it lose the mating potential altogether. Also here, people are encouraged to find even slower maters.

[Edit]I already found an even slower mater, which takes up to 130 moves!

Generating end-game table; Please wait.


Aurelian Florea wrote on Sat, Oct 6, 2018 09:59 AM UTC:

For how many pieces is it feasible? Like for CWDA is K+Woody rook+short rook vs K +waffle (WA) doable?


H. G. Muller wrote on Sat, Oct 6, 2018 10:52 AM UTC:

This is purely for 3-men end-games. There it takes typically 150-200 ms to generate the EGT. For each additional piece this increases by a factor 64, though. So if I would extend the generator to doing 4 pieces, it would already take 10-13 sec to initialize. For 5 pieces it would need 10-15 min, even if the browser would allow you to grab the required amount of memory (1GB).

Of course off-line EGT generators exist, which can be much faster (JavaScript is not the fastest programming language conceivable). E.g. Fairygen. This can do 5-men EGT, definitely for WD+R4 vs WA (although I am not sure if it could do it for totally unsymmetric pieces).


Aurelian Florea wrote on Sat, Oct 6, 2018 07:06 PM UTC:

Thanks for the info HG :)!


H. G. Muller wrote on Mon, Dec 17, 2018 11:15 AM UTC:

I still would appreciate some response from an editor on my proposal, even if it is just a firm rejection...


Ben Reiniger wrote on Mon, Dec 17, 2018 07:54 PM UTC:

Initial thoughts (mostly the ones I had but didn't post a couple of months ago; sorry):

I like the tool a lot; thanks for creating and sharing.  For individual piece(clopedia) pages, I wonder whether something static would be better.  I think the whole table is a lot more in-depth than many of our piece pages, so maybe a summarized version (if necessary for a couple of board sizes?) would be a better fit for those.  (On that note though, I have at various times wanted to expand on and standardize piece(clopedia) pages...)  I think the entire tool itself would work well as its own page, maybe listed as Primary (so displayed at the top of searches) in the Piece(clopedia) page type?


H. G. Muller wrote on Tue, Dec 18, 2018 02:34 PM UTC:

I agree that the whole table hardly contains relevant information. (The reason I had the applet displaying it was mostly for debugging, to compare with the known statistics of orthodox pieces.) It would be sufficient to just print percentages won and drawn, and the average and maximum number of moves needed to force mate in a won position. It would of course be easy to suppress the more detailed info.

The applet is inherently dynamic, and only calculates information for the board size seen in the accompanying diagram where when can practice the end-game. The time needed to calculate the End-Game Table for an 8x8 board is pretty short, but it rises quickly with board size (as the cube of the number of board squares), so that doing many different board sizes (some large) at once would be a bad idea. If static information on the end-game statistics for several board sizes is the only thing that is desired for a Piececlopedia page, (accompanying a sentence that points out the piece has mating potential), it would be best to just hard-code that in the HTML. (The applet could still be used to calculate the required info before incorporating it into the page, of course.) There would be no need for a diagram in that case; the latter only serves the function of allowing interactive play.

If the applet would have its own page, it might be possible to set it up such that individual Piececlopedia pieces can link to it through some standardized link (saying something like "Practice checkmating with this piece"), in such a way that the page opens configured for the piece in question. (E.g. by passing the Betza descriptor for the move as a CGI argument in the URL.) We would have to pick a default board size, though. (8x8 seems the obvious choice.) The applet page itself could allow the user to alter the board size, within reasonable limits.

Of course not all pieces have mating potential. So deciding which pages should have a link to the applet should be done 'by hand'. This is probably necessary anyway, because the info for how the piece moves would have to be provided with the link. So all the Piececlopedia pages for pieces with mating potential would then have to be hand-edited.


Ben Reiniger wrote on Wed, Dec 19, 2018 04:27 PM UTC:

That's all pretty much how I was thinking of how to implement it too.  Since the Piececlopedia is fairly small, I'm inclined to just edit by hand.

I've been wanting to database-ify some Piece information; maybe linking to the applet page with piece Betza notation, drawn from such a table, would be a good starting point.


Greg Strong wrote on Wed, Dec 19, 2018 06:10 PM UTC:

I like the approach being described.  The endgame-generator is awesome and we should certainly make it available here, so long as the actual computation is done client-side.  (Our hosting provider terminates the entire server when our CPU quota is exceeded.)


H. G. Muller wrote on Thu, Dec 20, 2018 10:25 AM UTC:

The calculation is entirely done client side, so that is no problem. I will try to prepare a version that takes the Betza description of the piece from the URL. (And perhaps the name of the image to be used for this piece as well.) And it will just print a statistics summary rather than the entire DTM table. I will also omit the interface for letting the user design its own pieces.


H. G. Muller wrote on Sat, Dec 22, 2018 11:03 AM UTC:

It appears that the JavaScript version of the EGT generator has too much 8x8 logic hard-coded into it that for now I cannot easily change it to also do other board sizes. I posted a version of the page on my website that only prints a summary of the statistics, and can accept arguments w.r.t. the image, move and name of the piece as 'get' arguments to the URL. Like:

http://hgm.nubati.net/rules/EGT_CVP.html?name=archbishop&betza=BN&img=cardinal

It already links to images and the diagram JavaScript present on the CVP website (I used Alfaerie .gif images), but from my own website this of course had to be done through "off-site" links of the type "http://www.chessvariant.com..."; when it would be on the CVP site the initial site address could be omitted from those links.

Perhaps a CVP editor can copy the page to the CVP website (and possibly dress it up with CVP logos). Apart from the link to the diagram's betza.js script in <script> tags and to the directory with piece images as graphicsDir in the diagram's description, and a link to the directory with marker symbols for the diagram at the end, the page is 'self-contained'. (I.e. the JavaScript for building the EGT and probing it during play is inside the page.)

Beware that the EGT generator currently can only do regular sliders and leapers, and that it would be blind to more advanced modifiers supported by the diagram, such as divergence, multi-leg moving or hopping. Pure hoppers would not have mating potential with only their King as support, though, and most other pieces in the Piececlopedia are regular slider/leaper compounds, so this doesn't seem much of a problem. (Bent sliders are a problem, though, so the Gryphon cannot be handled yet.)


Aurelian Florea wrote on Sat, Dec 22, 2018 10:05 PM UTC:

HG,

Hello!

Earlier on this post you had mentioned Fairy Gen.

I have a few questions:

1. Where  can I find it?

2. Is it yours? Who has authored it?

3. Is it open source? Can I see the code?


Aurelian Florea wrote on Sat, Dec 22, 2018 10:20 PM UTC:

@HG!

I had found it by google, in the end, here:

http://home.hccnet.nl/h.g.muller/EGTB.html

So I guess that settles it.

Thanks, HG!


Aurelian Florea wrote on Sat, Dec 22, 2018 10:24 PM UTC:

@HG

What I had found is something else!

So back to square one! Silly me!


Ben Reiniger wrote on Sun, Dec 23, 2018 12:43 AM UTC:

Would it be better to work in as something you can edit directly later?  IIRC, the way your interactive diagrams are hosted through a post-your-own-page attachment?  I think we can reindex correctly; I'll look into that later, but want to throw the idea out now in case you see another problem with it.


H. G. Muller wrote on Sun, Dec 23, 2018 07:52 AM UTC:

@Aurelian:

FairyGen can be downloaded from http://hgm.nubati.net/fairygen.zip . The archive contains a README.txt with an extensive description for how to use it.

@Ben:

This is a nice idea. But I think the initial posting would still need editor assistance to upload it as an attachment, as *.html is not one of the allowed file types in the upload script. Fergus made some special provision in that script which allowed me to update the /membergraphics/MSinteractive-diagrams/betza.js file, and I hope this works by allowing the use of any filename that already exists, so that it would also work for an already-present .html file. (I have no way to test that, though.)

So perhaps you should just put a (dummy) file /membergraphics/MSinteractive-diagrams/EGT.html on the server, so I can update it to the real version, and later edit it when necessary. I don't think there is any need to create a separate member-submitted article just for the purpose of hosting the EGT.html attachment; I would not really know what to write in there, and the article format enforced on member submissions is not very suitable for anything other than chess-variant descriptions anyway.


Aurelian Florea wrote on Sun, Dec 23, 2018 09:36 AM UTC:

Thanks!

The actual thing I'd like to use if for is to test the 5 man endgames for my 2 apothecaries games.

That is beyound the scope of the program as the 2 apothecary games are 10x10 and even worse it uses the joker (fool, imitator) which is not being defined in FairyGen.

But there seems to be enough information for me to build the program myself for a more general purpose. The main dificulty is probably the board representation as an 64 structure bits is not usefull any more. The joker implementation should be more staightforward but there maybe have to be some recurrence there too. I still have not though about it :)!


Aurelian Florea wrote on Sun, Dec 23, 2018 09:45 AM UTC:

@HG

By the way in the definition of the default file as it is downloaded you are trying to define an U (probably an unicorn or nightrider) but you are just putting down another knight. An extra "s" is required maybe. That is for future not carefull users. Also for the V and S pieces you defined an camel zebra compound twice. No ideea what is all that about :)!


H. G. Muller wrote on Sun, Dec 23, 2018 10:48 AM UTC:

In WinBoard I use the Unicorn image as the Royal Knight in Knightmate, so I was probably thinking of that. The Camel-Zebra compound is usually referred to as Bison, but the lame multi-path version of it is George Duke's Falcon, and in WinBoard I use the letter V for the Falcon symbol. (Because F was already taken by Ferz, and Dutch for Falcon is 'Valk'.) Not sure why I gave S the same move. Anyway, the main idea of the piecedef.ini file was that people could put their own piece definitions in there.

Note that the basic version of the generator assumes total symmetry and an 8x8 board. If you undefine the symbol DIAGSYM in the source code and recompile it would only assume 4-fold symmetry. This is not only needed for doing less symmetric pieces, but also for non-square boards. The way diagonal symmetry is implemented is leaning very much on the board size being 8x8, because it extracts the X and Y coordinates of the pieces by masking out groups of 3 bits from the index (through the RANKS and FILES masks) to be able to swap those. Even without diagonal symmetry it would not be so easy to adapt to other board sized; e.g. the tables bcode[] and deltaVec[] assume '0x88' square numbering, and would have to be changed.

FairyGen doesn't use any bitboard techniques, so the fact that the word length of a computer is only 64 bits in principle should not pose any limitation. It is just that everything having to do with square numbering and index calculation would have to be changed.


Ben Reiniger wrote on Sun, Dec 23, 2018 03:30 PM UTC:

That was my understanding of how Fergus reworked the upload script.  I've put such a placeholder file there, so we'll see soon whether that's right.

I could see the checkmating applet fitting in its own page.  If nothing else, that'd be a little more convenient for linking to, and would give it its own index entry for comments.

(And, a little hack for more flexible formatting: if the Introduction section is the only non-empty one in a member submission, the header is suppressed, and you can use your own html headers directly.)


Greg Strong wrote on Sun, Dec 23, 2018 05:22 PM UTC:

(And, a little hack for more flexible formatting: if the Introduction section is the only non-empty one in a member submission, the header is suppressed, and you can use your own html headers directly.)

Oh wow, I didn't know that!  Thanks :)


H. G. Muller wrote on Sun, Dec 23, 2018 09:01 PM UTC:

Indeed, that is a very useful feature!

I now uploaded the EGT.html to the Interactive Diagrams membergraphics folder. It can be linked to from the Piececlopedia pages, with the arguments to specify the move, name and symbol for the piece in question through the parameters 'betza', 'name' and 'img' (where the latter should be the root Alfaerie name, i.e. without the w/b prefix and extension). I guess we would want to do this both for pieces with general mating potential, and pieces that can only force mate in exceptional cases, but perhaps through different remarks. E.g.

  • This piece can almost always force checkmate on a bare king. Try it!
  • This piece can only force checkmate on a bare king from some very favorable positions. Try it!
  • It is not possible to deliver checkmate with just this piece and a King.

I also submitted an article, called 'Checkmating Applet', with the more general version of the applet that I had on my website. This includes the interface for defining piece moves. (I left out the button for some specific (mainly Musketeer Chess) pieces.)

While doing this it turned out the form for editing a submission has a pretty bad bug: in the first draft I had forgotten to adapt some links, and it included a header that turned out redundant. But when I try to edit, the edit window initializes each time with the first version I submitted, reverting all the changes I made in previous edit sessions, I then have to redo all these, and not forget a single one, or I would be back to square a1...


Ben Reiniger wrote on Mon, Dec 24, 2018 03:38 AM UTC:

Re: earlier points, see the applet's page.

On the other note:

While doing this it turned out the form for editing a submission has a pretty bad bug: in the first draft I had forgotten to adapt some links, and it included a header that turned out redundant. But when I try to edit, the edit window initializes each time with the first version I submitted, reverting all the changes I made in previous edit sessions, I then have to redo all these, and not forget a single one, or I would be back to square a1...

I played around with this for a little bit, and I think it's your browser caching the old submission data.  Refreshing the page fixed the problem for me.  (We could add a dummy variable to the end of the url as Fergus did for the Random Game menu link, but that might cause worse issues for using the browser's back button when submission fails e.g. because of being logged out?)


23 comments displayed

Earlier Reverse Order Later

Permalink to the exact comments currently displayed.