Comments by GregoryStrong

Thank you very much for the help.  I think I've gotten to the bottom it.  It was tricky because there were several things going on.

I think the main problem was indeed with the TT.  Those 169 scores you were seeing were mate positions but those weren't true mate scores.  Amateur mistake here ...  At some point I increased the value I was using to represent INFINITY (CHECKMATE) and I made the value larger than the number of bits I had reserve in my TT entry for storing the score.  So those 169 scores kind of worked - it still prefered them to other things and prefered quicker mate, but other things didn't work.  For example, the mate distance pruning didn't trigger because it didn't consider them mate scores.  I'm sure there are other places in the code with similar issues.

I found this last night but correcting for it did not solve my problem because I had since introduced a new problem since the release of version 2.2.  One of the things I'm doing for 2.3 is streamlining the code for Rules that store state information.  Instead of each Rule-derived class handling this itself, I now derive Rules that store state information from a template class RuleWithState.  Well, in doing that, I broke the DrawByRepetition rule and that was the reason I was still experiencing draws where there should have been wins.

Since things are still needing work on 2.3 and since this is a pretty major problem, I will release a service pack for version 2.2 today or tomorrow.  I will also add the feature for saving the games for games in run in batch mode.

Thank you for the help.  It is indeed pretty strange.

First, I should clarify a couple of things.  The problem isn't specific to KRK - I know it appeared in other situations as well, but KRK was an easily reproduced and extreme example.  Also, the special endgame code isn't specific to KRK, it is really KxK (King + plenty of material against bare king, probably the same idea as your bare king eval.)  This KxK code comes from Stockfish but adapted to do the right thing on boards of any size.  The other specific endgame evals I have so far are KRKP, KRKB, and KRKN (also from Stockfish.)  There is also some special handling for KPK which overwrites the eval to return draw scores on certain positions that are known to be draws (this is custom code based on Wikipedia's KPK article - the Stockfish KPK code uses a bitbase which doesn't help me given variably sized boards.)

The null move was a good idea, as well as draw scores getting into the TT, but neither of these seem to be the cause.  Null move is disabled with low enough material and disabling draw-by-repetition and/or 50-move rule didn't help.

With a fair amount of expirementation, I found another "solution".  If I change the TT cutoff condition at PV nodes from hash depth >= depth remaining to hash depth > depth remaining that solves the problem entirely and my searches seem totally consistent.  But I have "solution" in quotes because I'm not 100% sure this addresses the real problem either, but I think it probably does.  Somehow something is getting off by one somewhere.  I still need to understand it better because the underlying problem may be affecting non-PV nodes too resulting in weaker play that is not so obvious...

@HG:

I had a problem.  ChessV sometimes wasn't able to find the mate in KRK (for example), despite the fact that I have a custom endgame eval for this combination (which I'm sure is correct.)  I was able to solve this by no longer returning on TT hits on PV nodes.  This is an acceptable solution since you seldom get a cut-off on a PV node so it does not speed things up much, if at all, and it reports shorter PVs.  But I'd still like to understand the problem in case there is something else wrong.

I only return at a PV node if the TT entry depth >= depth remaining and the entry type is Exact.  I also shift mate scores by the ply before returning, as is typically done.  Do you have any insight why I might be missing mates and stumbling into draws by repetition or 50-moves?  I guess my TT code could have a bug, but I don't think so.

I've created a new piece set called Alfaerie: Eclectic Mix for these three games that has F=Frog, E=Elephant-Ferz (Modern Elephant), and W=Waffle so you can make these with single-letter pieces.  That may be why your functions aren't being called.  The functions for the Frog would now be FL and fL.  (Not sure how you would name them with the { and } characters in the piece titles.

You shouldn't need to call them directly.  They are called from the Checked function if I recall correctly.

Yes, it looks like it has the identies of the players backwards.  That's odd.

Look at the cwda include file:

https://www.chessvariants.com/play/pbm/includes/cwda.txt

Towards the end, the switch #wx and switch #bx are placing the appropriate pieces for each army on the board.  Maybe you can set the values for these to something > 4 before the line that includes this file to get around it.

Remove all the Game Code and it will work (although with no rule enforcement.)  Apparently the code in the preset doesn't support mixed pieces like that.

Cool.  Let us know the results :)

That's right.  If your games are all playing from the starting position, you would just paste those two lines over and over again.

The control file is a tab-delimited text file.  The first row is the header row identifying what is in each column.  Each row after is a game that will be played.

The required columns are:

Game - the filename of a saved-game file (*.sgf)

Engine1 - the engine playing player 1 ("ChessV", "Fairy-Max", etc.)

Engine2 - the engine playing player 2 ("ChessV", "Fairy-Max", etc.)

Time Control - the time controls (“1:30” would be entire game in 1 minute 30 seconds, “0:10+2” would be a base time of 10 seconds, plus an increment of 2 seconds for each move.)

Other columns are optional:

ID - If you want to identify the games in some special way.  By default they will just be identified by row number.

Variation - The variation of play (“None”, “Small”, “Medium”, or “Large”.  Default is None.)

Player1 and Player2 - How you want the sides identified for purposes of counting up statistics.  By default, it will use the engine names.  Which is reasonable if the purpose of the test is to pit ChessV against Fairy-Max and see which one does better.  For ChessV vs. ChessV, it won’t accomplish much.  In your case, you are testing Augmented Knight vs. Extra Pawn, so name your player accordingly.  Also note this can do variable substitution in the form of #{variable}, so for testing different armies, you would specify #{WhiteArmy} for player 1 and #{BlackArmy} for player two.

For your purposes, let’s say you have two saved game files - WhiteAugmented.sgf and BlackAugmented.sgf.  They don’t need any moves in them unless you want to have multiple files from different start positions.  Given this, your control file could look like this:

Game    Engine1    Engine2    Time Control    Player1    Player2    Variation
WhiteAugmented.sgf    ChessV    ChessV    0:30    Augmented Knight    Extra Pawn    Small
BlackAugmented.sgf    ChessV    ChessV    0:30    Extra Pawn    Augmented Knight    Small

Actually, this does not quite work.  Waffle Chess has a unusual castling rule (which is why it was not included.)  I had planned to add support for "Fast Castling" but it didn't make it into this release.  Probably it will be in the next one.