The Chess Variant Pages
Custom Search




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

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
This item is a computer program
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-01-23
 Author: Greg  Strong. ChessVThis item is a computer program
It belongs to categories: Orthodox chess, 
It was last modified on: 2020-01-23
 Author: Greg  Strong.. Missing description[All Comments] [Add Comment or Rating]
Greg Strong wrote on 2020-03-11 UTC

I think it would be nice to add a documentation of .cvc (ChessV Code) so I can understand more of how it works.

Indeed it would but writing documentation is very time-consuming.  That said, I do have a lot of reference material that I need to upload.  It does not explain all the details of the language, but it does at least document all the game classes with the pieces and game variables they expose.  This, combined with the 20 samples in the ChessV include directory should go a long way.  I will try to get this posted this weekend.


Anonymous wrote on 2020-03-07 UTC

I think it would be nice to add a documentation of .cvc (ChessV Code) so I can understand more of how it works.


H. G. Muller wrote on 2020-02-29 UTC

I am sad to say that there still seems to be a problem with the ChessV.Engine.exe WinBoard engine, which I failed to catch and report before, even though I should have realized something was amiss by the long time it took to load ChessV. When I run this engine from the command line, it nicely prints "feature done=1" at the end of a long list of features (ending with the variants feature), in response to "protover 2". But when I run it under WinBoard it does not do that. So that WinBoard, after a timeout (which fortunately occurs after 10 sec, as ChessV did not start with feature done=0), WinBoard qualifies it as a WB v1 engine, which apparently sets the variants list to just the current variant, 'normal'. (This is arguably a WinBoard bug, but it was a hack to make WB v1 engines dedicated to a specific variant, such as TSCP-G work.)

This doesn't seem just a failure to flush the feature done=1 when running under a GUI; in the WinBoard debug log the "feature done=1" never appears, but after sending the engine a move, before it starts thinking, it resends the option definition for "Weakening" instead.

Btw, the syntax of that option definition is wrong (which causes it to be rejected by WinBoard): the closing quote should be at the very end, not immediately after the option name, like

feature option="Weakening -slider 0 0 15"

[Edit] And from the command line it doesn't seem to respond to the 'quit' command.


Greg Strong wrote on 2020-02-21 UTC

I have posted a patch to bring ChessV2.2 up to Service Pack 1 (SP1).  This is a zip file that just contains replacements for the EXE and DLL files.  Unzip it into your ChessV2 program files directory to overwrite those files.  If you are still on Release Candidate 1 (RC1) that is ok, this will still bring you up to SP1.

Download ChessV2.2 SP1 Patch

This contains everything we discussed below plus a couple of other small fixes.

I will also be updating the regular installer version and source code.  I will post when those are updated, in case you prefer to download the full installer, uninstall, and reinstall.


Greg Strong wrote on 2020-02-17 UTC

Yup, I've tracked that down too.  Thanks for pointing it out!


H. G. Muller wrote on 2020-02-16 UTC

Well, while you are at it, could you also check out why the engine version prints such strange values for the time in CECP Thinking Output? That must be pretty trivial to fix.


Greg Strong wrote on 2020-02-16 UTC

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.


H. G. Muller wrote on 2020-02-16 UTC

I presented the position to ChessV 2.2RC1, and after 5 min (the time it reports itself is bogus!) it produced a move at 32 ply:

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
32	+169.59 	106.2M	8:50:53	f2f3 f5e5 d4d1 e5e6 f3f4 e6f6 d1e1 f6g6 f4g4 g6f6 g4f3
31	+169.59 	45.1M  	3:35:35	f2e3 f5f6 e3e4 f6g5 d4d3
30	+169.58 	28.1M  	2:11:14	f2e3 f5e5 d4d3 e5f5 e3d4 f5f6 d4e4 f6e6 d3d5
29	+169.55 	19.1M  	1:25:46	f2e3 f5e5 d4d1 e5f5 d1d5 f5f6 e3e4 f6e6 d5d2 e6f6 d2a2 f6e7 e4e5 e7d7 e5d5 d7e7 a2a5 e7f7 a5a3 f7f8 a3a7 f8g8 d5d6 g8f8 a7b7 f8g8
28	+169.55 	15.9M  	1:08:52	f2e3 f5e5 d4d1 e5f5 d1d5 f5f6 e3e4 f6e6 d5d2 e6f6
27	+169.55 	13.3M  	56:28.33	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7
26	+169.55 	11.1M  	46:51.12	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7
25	+169.55 	8.86M  	37:24.84	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7
24	+169.55 	6.49M  	27:22.68	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f6 d1d6 f6e7 f4e5 e7f7 e5e4 f7e7 e4d5 e7f8 d6e6 f8f7 e6e1 f7f8
23	+169.55 	5.23M  	22:09.12	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8 f5e5 f8f7
22	+169.55 	3.91M  	16:38.40	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8 f5e5 f8f7
21	+169.55 	2.79M  	12:06.96	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f7 d2d8 f7e7 d8d5 e7f8
20	+169.55 	2.39M  	10:25.56	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f8 d2d8 f8f7 d8d5 f7e7 d5d3 e7f8 d3d6 f8f7 d6e6
19	+57.24 	1.85M  	8:09.84	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2
18	+169.56 	1.42M  	6:22.20	f2e3
17	+169.56 	1.13M  	5:12.00	f2e3
16	+169.56 	895583	4:14.28	f2e3 f5e5 d4d1 e5f6 e3e4 f6e6 e4f4 e6f7 f4f5 f7e7 d1d2 e7f8 d2d8 f8f7 d8d5 f7e7 d5d3
15	+57.24 	696806	3:22.80	f2e3 f5e5 d4d2 e5f6 e3e4 f6e6 d2d5 e6f7 e4f5 f7e7 d5d3
14	+57.04 	435297	2:11.04	f2f3 f5e5 f3e3 e5f6 e3f4 f6e6 d4d3 e6e7 f4f5 e7f7 d3d7 f7e8 f5e6 e8f8 e6d6
13	+56.96 	285881	1:27.36	f2f3 f5e5 d4d3 e5f6 f3f4 f6e6 d3d4 e6e7 f4e5 e7f7 e5f5 f7e7 d4d5
12	+56.88 	187028	0:57.72	f2e3 f5e5 d4d3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5 e7f7 d3d7 f7g6 e5f4
11	+56.80 	115957	0:34.32	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4d5 e6e7 e4e5 e7e8 e5e6
10	+56.72 	68603  	0:20.28	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5 e7e8
9	+56.72 	39705  	0:12.48	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 e4f4 e6e7 f4e5
8	+56.64 	23739  	0:07.80	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4c4 e6d6
7	+56.64 	12952  	0:04.68	f2f3 f5e5 f3e3 e5f6 e3e4 f6e6 d4c4
6	+56.64 	5601    	0:03.12	f2f3 f5e5 f3e3 e5e6 e3e4 e6e7
5	+56.64 	2579    	0:01.56	f2f3 f5e5 f3e3 e5e6 e3e4
4	+56.52 	1034    	0:01.56	f2f3 f5e5 f3e3 e5e6
3	+56.56 	418      	0:01.56	f2f3 f5e5 f3e3
2	+56.52 	121      	0:01.56	f2f3 f5e6
1	+56.64 	28        	0:01.56	f2f3
0	#

So like micro-Max it finds a mate score pretty fast; difference is that it seems to be that the pretty slow over-the-horizon mate it finds first isn't improved as much as the depth goes up. Still it is strange that it wouldn't simply play out the mating line it found, and is now in its TT, in the following moves.

[Edit] Umm, I might misinterpret the 169.xx scores as mate scores: when I let ChessV play out this position against itself there do appear standard mate scores at the end. Strange thing is that after the black engine admits to being 'mated-in-1' is its last move, the white engine crashes without performing the checkmate.


H. G. Muller wrote on 2020-02-16 UTC

It could be that the new condition just makes hash cuts so rare that the damage they do is not apparent. And can you still solve Fine #70 with this new condition?

Some of these end-games are really difficult (like KBNK), but KRK is not amongst those. If the start position is not extremely unfavorable (like the shown mate-in-12 rather than the worst-case mate-in-16), a fresh search should show you a mate score after a few seconds. Once there is a mate score, it should just start playing from the mating line that is now in the TT. Just walking the winning King to the center should already be enough to get better than mate-in-12.

How long does it take ChessV to get a mate score from the given KRK position, and what depth does it reach? Not being able to act out an already found mate would point to entirely different problems than not finding the mate in the first place.


Greg Strong wrote on 2020-02-16 UTC

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...


H. G. Muller wrote on 2020-02-15 UTC

This is very strange. Why do you need custom evaluation for KRK in the first place? Fairy-Max had absolutely no trouble to win KRK on its normal evaluation. (Which has Rooks completely neutral, and use the parabolic centralization table for Kings.) In the latest Fairy-Max version I use what you could call custom evaluation for checkmating a bare King (it just multiplies the centralization bonus for that King by a large factor), but that was only needed for end-games with many centralizing pieces (such as KFFFK in Makruk), because these did not bother to leave the center just for driving a single piece into a corner. Checkmating with Rook is very easy on any size board; you almost need no search depth for it at all. You just shephard the King towards the corner with your Rook, keeping the latter protected from behind by your King.

I suppose you do switch off null move?

The only thing I can think of that causes what you describe is contamination of the hash score with draw scores resulting from repetitions. What happens when you disable repetition detection (accepting PV hash cutoffs)? I don't really understand how a line that makes progress could get draw scores from this, though.

Can you post a game of how it typically plays KRK? (Best would of course be one that it bungles.)

Here is thinking output from a version of Fairy-Max that doesn't use the special bare-king evaluation, for position 8/8/8/5k2/3R4/8/5K2/8 w - 0 1 :

mover viewpoint		fewer / Multi-PV margin = 0 / more
exclude: none best +tail                                          
dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
28	  #12 	121.4M	1:17.65	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Re4 Kg6 7. Rf4 Kh6 8. Kf5 Kg7 9. Kg5 Kh7 10. Kf6 Kh8 11. Kf7 Kh7 12. Rh4 
27	  #13 	61.4M  	0:40.03	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re6 Kf5 5. Re4 
26	  #12 	46.8M  	0:30.38	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
25	  #12 	28.3M  	0:18.23	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
24	  #12 	15.6M  	0:09.85	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Kg3 
23	  #12 	10.3M  	0:06.45	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
22	  #13 	7.44M  	0:04.55	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re2 Kg5 5. Re5 
21	  #14 	5.88M  	0:03.52	1. Kf3 Ke5 2. Rd3 Kf5 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Kf4 
20	  #18 	4.72M  	0:02.74	1. Kf3 Ke5 2. Rd1 Ke6 3. Kf4 Kf6 4. Re1 Kg6 5. Re3 Kf6 6. Re5 Kg6 7. Kg4 
20	  #22 	4.50M  	0:02.59	1. Ke2 Ke6 2. Kf3 Kf6 
20	+4.59 	3.68M  	0:02.07	1. Ke3 Ke5 2. Rd8 Kf5 3. Re8 Kg5 4. Ke4 Kf6 5. Re5 Kg6 
19	+4.57 	2.37M  	0:01.27	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kc6 4. Kd4 Kd6 5. Re5 Kc6 6. Rd5 Kc7 7. Kc5 Kb7 8. Rd6 Kc7 9. Kd5 Kc8 10. Ke4 
18	+4.56 	1.54M  	0:00.81	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kh5 6. Rg4 Kh6 7. Rg8 
17	+4.55 	1.12M  	0:00.57	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kg6 6. Kh4 Kg7 7. Kg5 Kh7 8. Rf7 Kg8 9. Kf6 
16	+4.54 	729185	0:00.35	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
15	+4.54 	518699	0:00.25	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
14	+4.54 	354924	0:00.15	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kc7 6. Kd5 Kd7 7. Ke5 
13	+4.53 	218794	0:00.09	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kb5 6. Kd5 Kb4 7. Ke5 
12	+4.53 	150300	0:00.06	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg5 4. Rf4 Kg6 5. Kg4 Kh6 6. Kf5 Kh5 
11	+4.52 	107753	0:00.04	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Kf4 Kf6 5. Re3 Kg6 6. Ke4 
10	+4.50 	54436  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 Kf6 
9	+4.52 	36093  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 
8	+4.51 	20251  	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 
7	+4.50 	9192    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Re8 Kf6 4. Ke4 
6	+4.49 	5719    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 
5	+4.49 	2747    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 
4	+4.48 	559      	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 
3	+4.48 	223      	0:00.00	1. Ke3 Ke5 2. Re4 
2	+4.48 	23        	0:00.00	1. Ke3 Ke5 
1	+4.49 	13        	0:00.00	1. Ke3 

Greg Strong wrote on 2020-02-15 UTC

@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.


Aurelian Florea wrote on 2020-01-28 UTC

Actually saving each game could help beacause I can't stare all day at the monitor and the aftergame survelliance could be fun! For know nothing more. Good luck, Greg!


Aurelian Florea wrote on 2020-01-28 UTC

It was a FF-CC game (could have been reversed). An option to save all games could come in handy!...


Greg Strong wrote on 2020-01-28 UTC

I'd need a saved game file to investigate.  You should be able to save even during self-play but you have to catch it before the game ends.  Or I can modify it to save out all games.  What armies were you using?


Aurelian Florea wrote on 2020-01-28 UTC

I have tried similar experiments for Chess with different armies. It seems the endgame is bad as the computer leaves without reason pieces en prize. Tell me how to help you reproduce this bug. That has probably made results skewed in ENEP games, to!


Aurelian Florea wrote on 2020-01-28 UTC

Final results on the enep experiment. There were 100 games at 1 minute + 3 seconds of added time.

 

enhanced knight 42

extra pawn 58

from which draws were 48 games


Aurelian Florea wrote on 2020-01-28 UTC

The final batch of games is over:

augmented knight 17

extra pawn 23

with 22 draws


Greg Strong wrote on 2020-01-27 UTC

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.


pallab basu wrote on 2020-01-27 UTC

I am wondering why that is so? I don't clearly see anything in the code that precludes mixed pieces.


Greg Strong wrote on 2020-01-27 UTC

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.


pallab basu wrote on 2020-01-27 UTC

I am testing with a modified preset

/play/pbm/play.php?game%3DAssymetric+army%26settings%3DFIDE-Assym1

But whenever I tried to actually play a RR vs FF preset appears, not my modified army. I would appreciate any help.


Aurelian Florea wrote on 2020-01-27 UTC

A third batch of 20 games resulted in:

enhanced knight 7.5

extra pawn 12.5

there were 9 draws.


Aurelian Florea wrote on 2020-01-27 UTC

Another batch of 20 games resulted in:

augmented side 8.5

extra pawn side 11.5

with 7 draws.

The bug appeared again. It seems it does not get the time to increment itself or somethig.


Aurelian Florea wrote on 2020-01-27 UTC

The results for enep with time control 1 min and 3 sec/turn, with 20 games played ,are:

Augmented side 9

Extra pawn 11

There were 10 draws

But the program displayed 8-11. For some reason game (victory for the augmented side) 20 did not get counted. A small bug in here Greg. Also if I may a suggestion it would be nice if in the output file the final score is written at the end!...

 


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.