H. G. Muller wrote on Sun, Mar 31, 2019 12:32 PM UTC:
@Greg
Any progress on this? I am contemplating to also return to piece-value measurements. Because I want to measure the more subtle effects, such as mating potential and pair bonuses, this will require a less course approach than Fairy-Max. I have started to extend the capabilities of my engine KingSlayer (originally released as 'Simple', until I was told that name was already taken), which I wrote a few years ago as a demo source code for orthodox Chess somewhat more advanced than TSCP, to also support fairy pieces. And in particular CwdA. So I changed the move generator to support limited-rage sliding/riding on a per-move basis. (For Chess it was done on a per-piece-type basis, and the range could only be 1 or infinite.)
As that engine only supports 6 piece types per side (which, with a little bit of work, could be expanded to 7), I implemented this by initializing the tables with piece properties it uses during play from a larger table that contains descriptions of all supported piece types. (So far the 16 piece types of the 4 classical CwdA armies.) For a particular game it then just picks up to 4 of these in addition to the always participating P and K. Unlike Fairy-Max, this engine has a dedicated check test (rather than just trying a null move and wait for a King capture), and this had to be extended too in order to handle the new moves. Basically it works by having a 15x15 'board' indexed by the relative distance, where for each step a bitmap indicates which piece type in principle could make such a step, where for sliding moves a contact threat is distinguised from a distant one (to easily see if you need to test for blocking). By making use of the fact that some pieces are compounds of others (like Q=R+B), and decomposig some pieces into 'primitives' to make even better use of that, the number of different primitives needed to support CwdA was 13, too large for the byte originally used for this purpose, but less than half a 32-bit integer, so that I can now even use separate bits for white and black attacks, eliminating the need to test the piece for being an enemy by other means. This type of check test would become more cumbersome with hoppers (where you don't only have direct and discovered checks, but also have to deal with 'activation' by interposition), and very awkward in the presence of bent sliders (like the Gryphon). So this engine will probably never support those kinds of moves. Divergent pieces would still be a realistic possibility, though.
Unlike Fairy-Max this engine does have an advanced Pawn-structure evaluation, (e.g. passer recognition), which is directly usable in CwdA, as that uses the same Pawns. It did keep track of the number of pieces of each type that are still present, and used this to award a Bishop pair bonus (if there were two), or discount the static evaluation score when mating potential gets into jeopary for lack of Pawns (i.e. with 1 Pawn or less). This will have to be substantially refined, though, as with multiple color-bound types cross bonuses are to be expected, and you cannot conclude from the piece counts alone whether you have a pair or not. Also drawish cases similar to 'unlike Bishops' cannot be recognized this way, which was already a weakness in regular Chess. So I plan to add a 'material hash', which uses a hash key that depends on the present material, but counts color-bound pieces of the same type but on different square shades as different. (This can be done through a Zobrist-like hashing scheme that doesn't assign a different key to a piece type for each board square, but just one for each 'meta-color' relevant for that type.) Which piece combinations will have mating potential will now depend on the army, and will thus require a more complex analysis, but if the results of that analysis are kept in a hash table, this will not impact engine speed.
BTW, other types of (meta-)color binding can be interesting as well. E.g. odd/even file binding, such as for vRsD, which does have substantial mating potential. (Although a fortress draw is possible when the bare King cannot be cut off from the safe edge. A vRsDD would even be better in preventing that.)
You mentioned lack of standardization presenting a problem for having XBoard engines playing CwdA in ChessV. What would be needed here? Now that I am making KingSlayer into a CwdA engine, it might be good to have a closer look at the specific problems, and try to find ways to remove those. At the moment I have KingSlayer report in the CECP variants feature that it supports variant 'fairy', and gave it engine-defined combo options 'White Army:" and "Black Army:" that can be used to select the flavors FIDE, Clobberers, Rookies or Nutters, and will determine what variant fairy means. But in addition to that I could allow setting of the default value of those options through arguments in the engine command (so that you would never have to bother setting the option).
@Greg
Any progress on this? I am contemplating to also return to piece-value measurements. Because I want to measure the more subtle effects, such as mating potential and pair bonuses, this will require a less course approach than Fairy-Max. I have started to extend the capabilities of my engine KingSlayer (originally released as 'Simple', until I was told that name was already taken), which I wrote a few years ago as a demo source code for orthodox Chess somewhat more advanced than TSCP, to also support fairy pieces. And in particular CwdA. So I changed the move generator to support limited-rage sliding/riding on a per-move basis. (For Chess it was done on a per-piece-type basis, and the range could only be 1 or infinite.)
As that engine only supports 6 piece types per side (which, with a little bit of work, could be expanded to 7), I implemented this by initializing the tables with piece properties it uses during play from a larger table that contains descriptions of all supported piece types. (So far the 16 piece types of the 4 classical CwdA armies.) For a particular game it then just picks up to 4 of these in addition to the always participating P and K. Unlike Fairy-Max, this engine has a dedicated check test (rather than just trying a null move and wait for a King capture), and this had to be extended too in order to handle the new moves. Basically it works by having a 15x15 'board' indexed by the relative distance, where for each step a bitmap indicates which piece type in principle could make such a step, where for sliding moves a contact threat is distinguised from a distant one (to easily see if you need to test for blocking). By making use of the fact that some pieces are compounds of others (like Q=R+B), and decomposig some pieces into 'primitives' to make even better use of that, the number of different primitives needed to support CwdA was 13, too large for the byte originally used for this purpose, but less than half a 32-bit integer, so that I can now even use separate bits for white and black attacks, eliminating the need to test the piece for being an enemy by other means. This type of check test would become more cumbersome with hoppers (where you don't only have direct and discovered checks, but also have to deal with 'activation' by interposition), and very awkward in the presence of bent sliders (like the Gryphon). So this engine will probably never support those kinds of moves. Divergent pieces would still be a realistic possibility, though.
Unlike Fairy-Max this engine does have an advanced Pawn-structure evaluation, (e.g. passer recognition), which is directly usable in CwdA, as that uses the same Pawns. It did keep track of the number of pieces of each type that are still present, and used this to award a Bishop pair bonus (if there were two), or discount the static evaluation score when mating potential gets into jeopary for lack of Pawns (i.e. with 1 Pawn or less). This will have to be substantially refined, though, as with multiple color-bound types cross bonuses are to be expected, and you cannot conclude from the piece counts alone whether you have a pair or not. Also drawish cases similar to 'unlike Bishops' cannot be recognized this way, which was already a weakness in regular Chess. So I plan to add a 'material hash', which uses a hash key that depends on the present material, but counts color-bound pieces of the same type but on different square shades as different. (This can be done through a Zobrist-like hashing scheme that doesn't assign a different key to a piece type for each board square, but just one for each 'meta-color' relevant for that type.) Which piece combinations will have mating potential will now depend on the army, and will thus require a more complex analysis, but if the results of that analysis are kept in a hash table, this will not impact engine speed.
BTW, other types of (meta-)color binding can be interesting as well. E.g. odd/even file binding, such as for vRsD, which does have substantial mating potential. (Although a fortress draw is possible when the bare King cannot be cut off from the safe edge. A vRsDD would even be better in preventing that.)
You mentioned lack of standardization presenting a problem for having XBoard engines playing CwdA in ChessV. What would be needed here? Now that I am making KingSlayer into a CwdA engine, it might be good to have a closer look at the specific problems, and try to find ways to remove those. At the moment I have KingSlayer report in the CECP variants feature that it supports variant 'fairy', and gave it engine-defined combo options 'White Army:" and "Black Army:" that can be used to select the flavors FIDE, Clobberers, Rookies or Nutters, and will determine what variant fairy means. But in addition to that I could allow setting of the default value of those options through arguments in the engine command (so that you would never have to bother setting the option).