| View previous topic :: View next topic |
| Author |
Message |
Eelco de Groot

Joined: 12 Mar 2006 Posts: 2591 Location: Groningen
|
Post subject: Re: king safety eval - interesting position Posted: Wed Apr 04, 2012 6:01 pm |
|
|
I think it is worth noting that the actual position, in spite of all the stacked pieces still looks like a draw if you do a deep search on this position or for example a shoot out, and that probably has to do with the blocked pawn position, however strange that may seem. So particularly for the static eval, if an advanced pawn eval considers this position as drawish just by the pawn structure, in this particular instance I think your static eval would be right. Bear in mind I am a very weak chessplayer though.
| CRoberson wrote: |
In this position, I coded Telepath to give bonus points for the rooks being on a semi-open file, a few more bonus points for being on a
semi-open file near the opposing king where it is the opponents pawns that are the reason it being semi-open (IOW, the rooks are attacking).
As a human chess player, I consider the bishops as mobile and temporarily blocking the rooks, so the rooks must get a bonus (small one). This helps the program position the rooks there instead of another semi-open file elsewhere. Given the bonus is relatively small, points are gained by moving the bishops and getting direct attacks.
The OLD chess axiom that applies here is "... don't move the pawns on the side where you are being attacked ...". Telepath plays ...Nf6 after 21 ply. |
I take it you meant with that that h6 is maybe not the best move Charles? The output below has not so much to do with the position but I just like to relate that I was trying to get my version of the Stockfish search to work (using Jon's example more for stresstesting) and it just kept crashing with unclear error messages 0xc00000fd or 0xc0000005 or even without error messages and maybe it is something very simple, but I haven't figured it out yet. The same code did work in older versions of Stockfish but a lot has changed since then. So I was very glad when finally at least one of my attempts did not seem to crash anymore and I let it run for a long time on this position. It stayed with h6 for very long which maybe isn't the best move, my crashing versions all went for Nf6 before expiring but this is the output of the non crashing version at the end. There is a big Fail High it tries to resolve at depth 46 Going from a nullwindow search to a full PV search from scratch at depth 46 is probably too difficult, it is a common complaint on the Rybka forum too that such cases, using Rybka, simpy are not being resolved and users have a hard time understanding why this is so.
5rnk/r2q2pp/3p2B1/2p1pPB1/p1PnP2Q/Pp1P2RP/1P4R1/6K1 b - -
Engine: Rainbow Serpent 2.2.4 Build 002 (one thread on the old Athlon, Stockfish base code is that of the master at 29-03-2012 but most of the RS changes are in here, except some crashing search mods. Hashtables 256 MB)
by Tord Romstad, Marco Costalba and Joona Kiiski
44/77 42:11 -2.98 1...h6 2.Rf2 Rf6 3.Kh1 Qc7 4.Rgg2 Nc6
5.Rg1 Qe7 6.Qh5 Qc7 7.Rfg2 Nd4 8.Rf1 Ra6
9.Rgg1 Qb7 10.Rf2 Ra7 11.Rgf1 Qe7
12.Kh2 Ra8 13.Rg1 Qb7 14.Qh4 Ra7 (944.780.695) 373
45/77 47:51 -2.98 1...h6 2.Rf2 Rf6 3.Kh1 Qc7 4.Rgg2 Qe7
5.Kg1 Ra8 6.Qh5 Qc7 7.Kh1 Ra6 8.Qh4 Ra7
9.Kh2 Qb7 10.Kg1 Ra6 11.Kh1 Qe7
12.Rg4 (1.071.438.204) 373
46/77 56:46 -2.90++ 1...Nf6 2.Bd2 Qb7 3.Bg5 Nc2 4.Rf2 Kg8
5.Bxf6 (1.280.063.952) 375
46/81 59:39 -2.82++ 1...Nf6 2.Kh1 Qb7 3.Kg1 Nc2 4.Rf3 Qb8
5.Rfg3 Qc8 6.Rf2 Nd4 7.Bc1 Qb7
8.Rfg2 Nc2 9.Bd2 Nxa3 10.bxa3 b2
11.Be3 b1Q+ (1.349.238.280) 376
46/81 60:03 -2.70++ 1...Nf6 2.Kh1 Qb7 3.Kh2 Ra5 4.Qxh7+ Nxh7
5.Bxh7 Kxh7 (1.358.508.190) 377
46/81 61:32 -2.52++ 1...Nf6 2.Kh1 Qb7 3.Qxh7+ Nxh7
4.Bxh7 Kxh7 (1.394.107.747) 377
46/103 74:51 -2.25++ 1...Nf6 2.Qh6 gxh6 3.Bxf6+ Rxf6
4.Bxh7 Qxh7 5.Rg6 Rxg6 6.fxg6 Qxg6 (1.839.732.780) 409
46/103 76:09 -1.84++ 1...Nf6 2.Qh6 gxh6 3.Bxf6+ Rxf6
4.Bxh7 Qxh7 (1.871.865.740) 409
best move: Ng8-f6 time: 1551:14.125 min n/s: 409.604 nodes: 1.871.865.740
After more than 24 hours there was no sign that the FH for Nf6 would be resolved, I stopped the run then but as a stress-test it was a success that the engine still seemed to be doing calculations and I don't think it was in a search explosion but that is not certain. Unfortunately version 003 of the search is still crashing
Regards, Eelco _________________ Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan |
|
| Back to top |
|
 |
|
| Subject |
Author |
Date/Time |
king safety eval - interesting position |
Jon Dart |
Tue Mar 27, 2012 10:59 pm |
Re: king safety eval - interesting position |
Gary |
Wed Mar 28, 2012 12:26 am |
Re: king safety eval - interesting position |
Jon Dart |
Wed Mar 28, 2012 3:18 am |
Re: king safety eval - interesting position |
Vincent Diepeveen |
Wed Mar 28, 2012 8:48 am |
Re: king safety eval - interesting position |
Vincent Diepeveen |
Wed Mar 28, 2012 8:52 am |
Re: king safety eval - interesting position |
Marco Costalba |
Wed Apr 04, 2012 6:17 pm |
Re: king safety eval - interesting position |
Alain Distel |
Wed Mar 28, 2012 7:22 am |
Re: king safety eval - interesting position |
Alain Distel |
Wed Mar 28, 2012 7:35 am |
Re: king safety eval - interesting position |
E Diaz |
Wed Mar 28, 2012 7:45 am |
Re: king safety eval - interesting position |
Vincent Diepeveen |
Wed Mar 28, 2012 8:21 am |
Re: king safety eval - interesting position |
Charles Roberson |
Wed Apr 04, 2012 3:30 pm |
Re: king safety eval - interesting position |
Eelco de Groot |
Wed Apr 04, 2012 6:01 pm |
Re: king safety eval - interesting position |
Jon Dart |
Thu Apr 05, 2012 1:30 am |
Re: king safety eval - interesting position |
Lucas Braesch |
Thu Apr 05, 2012 11:08 am |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|