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 2021-01-24 UTC

If you're deriving from one of the board-size specific games then there are shortcuts to enable these easily. But the options vary depending on the board size, so for unusual sizes it is a little more work.

You can look at the include file for Duke of Rutlands Chess for an example but here are the relevant bits. For castling, conventional chess would be:

            AddCastlingRule();
            CastlingMove( 0, "e1", "g1", "h1", "f1", `K` );
            CastlingMove( 0, "e1", "c1", "a1", "d1", `Q` );
            CastlingMove( 1, "e8", "g8", "h8", "f8", `k` );
            CastlingMove( 1, "e8", "c8", "a8", "d8", `q` );

The arguments to CastlingMove are: player (0 or 1); the square the king starts on; the square the king ends on; the square the other piece starts on; the square the other piece ends on; and a single character specifying what letter should be placed in the FEN to represent the availability of this move.

For the two-space pawn move, in chess it would be:

    Pawn.AddMoveCapability( MoveCapability( <1, 0>, 2, 2, false, false ) ).Condition = { location: location.Rank == 1 };

The last bit, { location: location.Rank == 1 } is a lambda function taking a location and returning true or false specifying where on the board this new move should be available.  Ranks are counted starting at zero, so Rank == 1 means whenever on the second rank.  The arguments sent to the constructor of MoveCapability are: the direction of the move, <1, 0> means rank offset of 1 and file offset of zero; minimum number of steps; maximum number of steps; is capture allowed; and is capture required.  We did not set the minimum number of steps to 1 because the pawn already has a single-space move and we don't want to generate it twice.

Finally, if you want en passant, just set EnPassant = true in your SetGameVariables function.


Robert Mate wrote on 2021-01-24 UTC

I would like to script some small chess variants. I started by looking at the Los Alamos chess, but can't figure out how to enable castling or allow an initial double pawn move.


Aurelian Florea wrote on 2021-01-05 UTC

Thanks!


Greg Strong wrote on 2021-01-05 UTC

You don't need (and can't use) the namespaces in the scripting language.  This should do it:

AddRules
{
    FindRule( Move50Rule ).HalfMoveCounterThreshold = 200;
}

 


Aurelian Florea wrote on 2021-01-05 UTC

I have eventually found it in the chess and a half game!

But it seems I cannot acces : ChessV.Games.Rules


Aurelian Florea wrote on 2021-01-05 UTC

I could not find an example where the 50 moves rule is replaced by an 100 moves rule. How is that done?


H. G. Muller wrote on 2020-11-26 UTC

What about QSearch? I assume it just doesn't consider drops at all?

Indeed. I never managed to get a non-exploding QSearch that searched captures plus drops, even when I limited it to safe check drops. Even an extension for check evasions can be dangerous in QS. At least, if you allow drops as evasions. (I forgot to mention that: when in check at d=1, it is of course pointless to try check drops, and I try drop evasions instead, to prevent seeing false checkmates.) The problem is that the drop evasions can add captured pieces back to the board for the side that is being checked, and if the players alternately check each other this can go on indefinitely. (I never saw that problem in my Shogi engines, but in Crazyhouse it did happen.) So it is probably safest to ignore checks beyond a certain QS depth, or limit the number of checks, or limit checking to one player only. Very powerful pieces can cause problems with search explosion in QS anyway.

That is really painful.  I wonder if it is possible to collect this information incrementally during the search rather than searching deeper to determine?

That is hard because of alpha-beta pruning, which might prevent the relevant moves from being searched. And you wouldn't want to do anything extra on the off chance that the current position might later run into a repetition; repetitions are not all that numerous in the tree.

As to castling: In Joker I had the problem that the castling bonus was so large that it could give rise to "positional horizon effect": it started to sacrifice material just to push the castling over the horizon. Which, predictably, only brought temporary relief for a permanent sacrifice. So in KingSlayer I make the associated King Safety bonus available in small steps. Clearing the path for castling to a location with a good Pawn shield already gives you part of the bonus for that shield. Or, in other words, the value of the castling right is a fraction of the bonus,and the more pieces are still in the way, the smaller the multiplier gets. And the availability of a second castling right gets added for 1/8 to that for the primary one. The Pawn-shield bonuses for all 4 locations are stored in the Pawn hash table, and also depends on the opponent having half-open files aimed at your shield.


Greg Strong wrote on 2020-11-26 UTC

I found the following search scheme to work quite well in games with drops: you distingush check-drops from other drops, and make a special move generator to selectively generate those (by generating retro moves for all piece types, starting from the King). At d=1 the only drops searched are the check drops; at d>=2 LMR reduces non-captures by 1 ply, and (non-check) drops by 2 ply.

Well, that sounds pretty easy.  What about QSearch?  I assume it just doesn't consider drops at all?

In CrazyWa I used a King Safety evaluation that seemed to work quite well generically across many drop variants. It was kind of unusual by being asymmetric. It awardeds a bonus to the side to move which is the product of the hand value and the number of squares attacked next to the enemy King (the possible drop locations). The latter could be cheaply calculated as side effect of the move generation, while the hand value can be kept track of incrementally. The idea was that in games with drops 'initiative' is all important, and the side that has the initiative typically checks the opponent all the time (mostly through drops, and captures with the slider it just dropped when evasion was an interposition). The side that is in check will never evaluate, but extend for the evasion even at d=0. So the leaves typically have the side on move that has the initiative, and this player usually doesn't have to worry much about his own King Safety.

This also makes sense.  I'll make a note of this.

Xiangqi chasing rules indeed are very annoying; especially the fact that they are based on legal attacks and protects means that you have to search 3 ply ahead to judge them: one to play the attacks that are  chase candidates as a capture, then the possible pseudo-legal recaptures, and finally the potential King captures resulting from these. And you have to do that for every position in the repeat loop. Always for both sides, because they could be mutually chasing, and then it is a draw again.

That is really painful.  I wonder if it is possible to collect this information incrementally during the search rather than searching deeper to determine?


Greg Strong wrote on 2020-11-26 UTC

Ok I went back and checked on the castling using only the ChessV engine with default settings with me as white. I've been playing mostly standard, gothic, and omega. Of three quick openings/midgames, Omega alone castled. What seems to happen is that the engine will push pawns away from a potential castle position before it gets the chance to castle into it.

Yes, I did some testing and I see what you mean.  It has no particularly strong desire to castle, so I'm increasing the castling bonus.  I'm also increasing the length of the opening phase.  The development evaluation bonuses/penalties "fade out" as the game progresses.  (By the endgame, it doesn't matter if you've castled or not.)  So some games it just doesn't get around to castling before the bonus is no longer applied.  And maybe this is right - maybe sometimes there are more urgent things going on.

On a different note, I tried to get P2P.exe (http://hgm.nubati.net/p2p.html) to work with this to play over the internet, but through no fault of either programmer, it won't work. This is because when you bring up the engine settings there should be a specialized window, but in ChessV there is always the same variation, weakening, etc. I only bring this up bcs there might be an easy fix ;)

Interesting.  I'm not surprised this doesn't work, although I don't know of any specific reason why it shouldn't.  The ChessV GUI doesn't support everything in the xboard protocol and there could be bugs with that which is implemented.  I may dig into this at some point, but there are other things needing attention more urgently.  At some point, ChessV should just have the ability to play matches across the internet on its own.


Robert Mate wrote on 2020-11-26 UTC

Ok I went back and checked on the castling using only the ChessV engine with default settings with me as white. I've been playing mostly standard, gothic, and omega. Of three quick openings/midgames, Omega alone castled. What seems to happen is that the engine will push pawns away from a potential castle position before it gets the chance to castle into it.

On a different note, I tried to get P2P.exe (http://hgm.nubati.net/p2p.html) to work with this to play over the internet, but through no fault of either programmer, it won't work. This is because when you bring up the engine settings there should be a specialized window, but in ChessV there is always the same variation, weakening, etc. I only bring this up bcs there might be an easy fix ;)


H. G. Muller wrote on 2020-11-26 UTC

I found the following search scheme to work quite well in games with drops: you distingush check-drops from other drops, and make a special move generator to selectively generate those (by generating retro moves for all piece types, starting from the King). At d=1 the only drops searched are the check drops; at d>=2 LMR reduces non-captures by 1 ply, and (non-check) drops by 2 ply.

In CrazyWa I used a King Safety evaluation that seemed to work quite well generically across many drop variants. It was kind of unusual by being asymmetric. It awardeds a bonus to the side to move which is the product of the hand value and the number of squares attacked next to the enemy King (the possible drop locations). The latter could be cheaply calculated as side effect of the move generation, while the hand value can be kept track of incrementally. The idea was that in games with drops 'initiative' is all important, and the side that has the initiative typically checks the opponent all the time (mostly through drops, and captures with the slider it just dropped when evasion was an interposition). The side that is in check will never evaluate, but extend for the evasion even at d=0. So the leaves typically have the side on move that has the initiative, and this player usually doesn't have to worry much about his own King Safety.

Xiangqi chasing rules indeed are very annoying; especially the fact that they are based on legal attacks and protects means that you have to search 3 ply ahead to judge them: one to play the attacks that are  chase candidates as a capture, then the possible pseudo-legal recaptures, and finally the potential King captures resulting from these. And you have to do that for every position in the repeat loop. Always for both sides, because they could be mutually chasing, and then it is a draw again.

It can be acceptable to only detect chases for repeats that have a certain minimum search depth left (say 4 ply).


Greg Strong wrote on 2020-11-26 UTC

Hi Elco. Thank you for your interest in ChessV. I'm glad you like it!

Regarding not castling - was with the ChessV engine? And if so, what variants? Almost all variants in ChessV should be using a function to evaluate development, which would reward castling and penalize losing the ability to castle.

Regarding Asian variants - I hope to support these as time goes on. Makruk is currently supported but without the endgame counting rules. This still needs to be done. Xiangqi would not be hard to do, except for the complicated chasing rules. Chu Shogi also isn't too far away. But games with drops are a much bigger challenge.


H. G. Muller wrote on 2020-11-20 UTC

There is no reason why an AI should never castle without book. I am pretty sure that the included Fairy-Max and KingSlayer engines would castle very quickly. I don't know about ChessV's intrinsic AI, but if it never castles it means the evaluation can easily be improved. In KingSlayer the castling is driven by a bonus for having a King near a corner behind a Pawn shield.

I guess that conventional chess AIs (i.e. not the alpha-zero type neural networks) are always mostly tactical.


elco2 wrote on 2020-11-20 UTC

Having used a lot of Zillions, I really like this interface, and the fact that a few extra engines come pre-installed. Zillions is all tactics, but I don't think these engines are.

AI never castles, but it probably wouldn't without an opening book, and making 100 opening books seems a bit much :o

Everything I would want in western chess variants, but I hope someday someone will add Asian variants. That someone might be me if I can find enough time.


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 

25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.