Comments/Ratings for a Single Item
Greg Strong wrote on Tue, Jun 4, 2019 11:52 PM UTC:Yes, you're right, I was still on 1.2 somehow. I will test with 1.3.
Greg Strong wrote on Sun, Jul 7, 2019 07:32 PM UTC:I have had some more time to test. This is a really an excellent CwDA engine. I think I have found another bug though. In one game, it insisted ChessV made an illegal move when the move was fine. In that game, ChessV was white playing the nutters and KS was black playing the rookies. KS promoted a pawn on g1 and chose to promote to a colonel. ChessV then moved the king to g4 and KS called this an illegal move, presumably thinking that its colonel on g1 attacked it.
So I think the issue is that when KS plays black and promotes a pawn to a piece from white's army, it thinks that the piece moves "forward" as a white piece instead of as a black piece.
Also, good catch about the memory usage. ChessV does not yet offer an xboard engine's configuration options but as a stop-gap I have added settings for the generic "memory" and "cores" options and it will supply them to xboard engines that support those featuers.
H. G. Muller wrote on Mon, Jul 8, 2019 06:56 AM UTC:Your diagnosis is entirely correct. Because KingSlayer was originally designed with only (2x) 7 piece types, it initializes the move-generator data for the four variable types from a larger list of all types depending on the army choice. But when 'Traitor promotion' is set it initializes the 5th variable type as a copy of the 4th, in the table for the opponent. But I forgot to flip the orientation. I will add a note to this posting when I have fixed it.
Good that ChessV now gives a memory command. I already had made KingSlayer a bit more robust to not receiving one, by having it interpret memory size 0 as 128KB and launching it with that size, and then check the memory size at the start of every search to see if it is still at 0, and allocating 64MB if it is. But relying on default hash sizes is likely to give rise to unfair use of resources.
[Edit] OK, I uploaded a version (0.1, same link) where the traitor orientation should be fixed. This was a bit tricky, as the initialization also collects all sliding directions of an army, to know from which directions it should expect discovered checks.
4 comments displayed
Permalink to the exact comments currently displayed.
Are you sure you got the new version, and that there was no problem with your browser caching the old version? It should say cwda-1.3 for the version number, and have 'dragons' as one of the options for the White/Black Army (not properly working yet, though). I tested it with a position "8/6P1/6k1/8/8/8/8/1K6 w - - 0 1" in FIDE vs Rookies, and it does play g7g8q without quote in that position.
In earlier versions I had some crashes too, which seemed to occur when the score got extreme. This disappeared after I calculated the interpolation between opening and end-game evaluation in a less overflow-prone way, and the version I originally posted had played several hundred games against Fairy-Max without a single crash. It could be that I broke something when changing the check test to also work with ski-slides. (But I see in the log that this happened for 1.2, so this cannot be the explanation.) This crash also doesn't reproduce.
Indeed I did not put equal armies in the list it announces in the variants feature. It would recognize the names in the 'variant' command, but of course a proper GUI would never send those if the engine did not announce it supported those. It is possible to play equal armies by selecting those through the White/Black Army options, and then select variant fairy. (This is how I test, as it currently is the only method where it is compatible with Fairy-Max, when I tick the option for old piece names, and turn traitor promotion off.)
BTW, in the log I see that you did not send a 'memory' command to set the hash size. That means KingSlayer would use its default hash size, which is only 1MB.