Marcel Duchamp endgame "splits" engines / hash phe

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
KWRegan
Posts: 17
Joined: Wed Aug 19, 2015 7:06 pm
Contact:

Marcel Duchamp endgame "splits" engines / hash phe

Post by KWRegan » Mon Feb 19, 2018 9:04 pm

The final long section of an article on Marcel Duchamp which I wrote for the Gödel's Lost Letter weblog https://rjlipton.wordpress.com/2018/02/ ... f-duchamp/ covers his only known composed endgame problem---different from the "corresponding squares" position which is the only other Duchamp endgame discussion I've found by searching here:

[d]1r6/1PR5/5p2/1P5p/5K2/8/6k1/8 w - - 0 1

This gives widely different results for Houdini, Komodo, and Stockfish versions run on 1 core thread with various power-of-2 hash table sizes. Houdini versions tend to all settle down to a stable eval under +0.40 around depth 26 in under a minute. Komodo versions settle around +3.00 but sometimes go haywire up near +7.00. Stockfish versions gyrate most of all, and often the result changes wildly if you keep the same hash size but change to one of the three mirror FENs:

8/1K6/8/2k5/P5p1/2P5/5rp1/6R1 b - - 0 1
8/6K1/8/5k2/1p5P/5P2/1pr5/1R6 b - - 0 1
6r1/5RP1/2p5/p5P1/2K5/8/1k6/8 w - - 0 1

My post tabulates analysis just for depths 37--40. I could post clips of UCI analysis output here but my real purpose is just to ask for input on the issue of hash table effects. I'm aware of things like the Hyatt-Cozzie results
http://www.craftychess.com/hyatt/collisions.html showing they don't usually degrade play, and this is distinct from the issue of positions that are still tough for engines such as in Dann Corbitt's post on Saturday. The "art" is to find positions where the presence of long forcing lines and opportunities to delay the horizon enhance the propagation of spurious evals in hash.

BeyondCritics
Posts: 343
Joined: Sat May 05, 2012 12:48 pm
Location: Bergheim

Re: Marcel Duchamp endgame "splits" engines / hash

Post by BeyondCritics » Wed Feb 21, 2018 9:05 am

You do not like the analysis output from stockfish in this position
[d]1r6/1PR5/5p2/1P5p/5K2/8/6k1/8 w - - 0 1
I think the root cause of the problem is, that stockfish due to a "evaluation bug" never correctly understands the stalemate defence in the c/f pawn queens ending, although it aims to do so.
I have posted a patch, that should correct the problem, which is currently tested http://tests.stockfishchess.org/tests/v ... 0297cc84d4.
The patched version avoids this ending, but now tries to win a drawn KRKN ending.
I noticed occasional glitches and setbacks in the search with hash tables of 32MB or lower, but not with tables of size 128MB or bigger.
This is maybe so, because stockfish identifies position only with a 32bit key.

With stockfish 9, always remember to set "Contempt=0" in the options, otherwise your analysis is biased, but i don't think this was significant here.

User avatar
Ovyron
Posts: 2325
Joined: Tue Jul 03, 2007 2:30 am

Re: Marcel Duchamp endgame "splits" engines / hash

Post by Ovyron » Thu Feb 22, 2018 12:24 pm

BeyondCritics wrote:With stockfish 9, always remember to set "Contempt=0" in the options, otherwise your analysis is biased
Or you're aware of this, and keep different, asymmetric analysis files/tree/graphs for white and for black, which has proven very powerful. I hope new users adjust to the new paradigm instead of the less useful Contempt=0.
Make someone happy today.

syzygy
Posts: 4447
Joined: Tue Feb 28, 2012 10:56 pm

Re: Marcel Duchamp endgame "splits" engines / hash

Post by syzygy » Thu Feb 22, 2018 12:46 pm

Ovyron wrote:
BeyondCritics wrote:With stockfish 9, always remember to set "Contempt=0" in the options, otherwise your analysis is biased
Or you're aware of this, and keep different, asymmetric analysis files/tree/graphs for white and for black, which has proven very powerful. I hope new users adjust to the new paradigm instead of the less useful Contempt=0.
But SF9's non-zero contempt does not allow that. It mixes up both of your trees in a single tree.

User avatar
Ovyron
Posts: 2325
Joined: Tue Jul 03, 2007 2:30 am

Re: Marcel Duchamp endgame "splits" engines / hash

Post by Ovyron » Thu Feb 22, 2018 1:46 pm

syzygy wrote:It mixes up both of your trees in a single tree.
You use Stockfish in different GUI instances so the hash of black does not contaminate the hash of white, and vice versa.

And now I'll go ahead and admit that I was completely mistaken: Komodo had it right.

Komodo doesn't even allow the user to do this on their GUI on the first place, Komodo forces to have the engine installed twice on their GUI, one installation for the white color, and another for black. Depending on the side you want to analyze, you fire up the suitable engine. You want to analyze both sides? You fire up two GUIs each with the suitable Komodo installation.

So users wanting to analyze with contempt can do it right.

And just with Stockfish, analyzing without contempt no longer makes sense. I haven't analyzed with default Komodo for months, and I've been up to Contempt=100, because the scores of the moves don't matter, just the difference with other moves' scores.

And users are missing out all this analysis revolution by lazily setting the Contempt to 0.

Looks like whoever decided on Komodo's implementation thought it much more thoroughly than I thought, and that my criticism was unwarranted. Contempt seems to be for people willing to investigate how to make use, and take advantage of a correctly used feature, the rest of people will just use Contempt=0 and miss out.

But don't go around telling people that Contempt=0 for analysis is optimal, I've used Komodo's Contempt for analysis for years (back then I started with Contempt=10, but more and more just got better and better), and in practice, Contempt=0 is a thing of the past. If high Contempt makes the engine play nonsensical moves those will be caught by the user's analysis method, which hopefully is good enough to not be a slave of the engine.
Make someone happy today.

syzygy
Posts: 4447
Joined: Tue Feb 28, 2012 10:56 pm

Re: Marcel Duchamp endgame "splits" engines / hash

Post by syzygy » Thu Feb 22, 2018 8:01 pm

Ovyron wrote:
syzygy wrote:It mixes up both of your trees in a single tree.
You use Stockfish in different GUI instances so the hash of black does not contaminate the hash of white, and vice versa.
But if the user is analysing a position with white to move he can't just make a white move and let the engine continue to run on the resulting position with black to move. He will have to stop the engine, make a move for white, make a move for black, and restart the engine. Or he stops the engine, makes a move for white, inverts the sign of the contempt setting, and restart the engine. Perhaps that is all fine for you, but for a normal user it certainly is not.

KWRegan
Posts: 17
Joined: Wed Aug 19, 2015 7:06 pm
Contact:

Re: Marcel Duchamp endgame "splits" engines / hash

Post by KWRegan » Fri Feb 23, 2018 12:39 pm

Indeed I had contempt=0; I forgot to mention that as a departure from the defaults.

User avatar
Ovyron
Posts: 2325
Joined: Tue Jul 03, 2007 2:30 am

Re: Marcel Duchamp endgame "splits" engines / hash

Post by Ovyron » Sat Feb 24, 2018 5:25 pm

syzygy wrote:Perhaps that is all fine for you, but for a normal user it certainly is not.
I actually use Play Mode to analyze like that:

You make the engine play a move as white, it is made on the board by the GUI.

The engine stops automatically.

You make a move by black on the board.

The engine thinks and makes a move as white, it is made on the board by the GUI.

This takes a lot less effort, mouse movement, and clicking, than whatever method the user can do with Infinite Analysis, unless the GUI automates even more with methods like DPA or iDEA.

Basically, I've been perfecting the art since 2007 and have manually analyzed several dozens of houndreds of thousands of positions (My main Bookup tree reports 3+ millions nodes), and the whole point of interactive analysis is to find the best move as fast as possible while analyzing as few positions as possible.

A high Contempt helps greatly with it (while before, I needed to do a lot of exclusion of the engines' main moves to get rid of the trash that wasn't doing anything, high Contempt focuses on lines that matter automatically, and other methods refute those that don't work quite fast), people sticking with Contempt=0 are missing out.

All I'm doing is begging people to experiment with higher Contempt for their analyses, and the new paradigm of only minimaxing white scores to white moves, and black scores to black moves, and see which one gives better results faster, and for other people to stop claiming that Contempt=0 is best, which is false (for what I've seen they haven't even tried it, they just do it poorly, have their hashes contaminated by opposite sites, and desist.)

The real question is why am I posting all this if it'd just benefit my potential opponents? I should just be snickering at home and thinking "yes! yes! use contempt=0! That way my analysis with higher contempt will be superior, mwahahaha!", I think I'll stop now with this subject, but users sticking with Contempt=0 will not be fools, they'll know there's something better, and will decide for themselves to stick with C=0 for whatever reason of their choice, instead of sticking with C=0 because they didn't know better. At least I told them.
Make someone happy today.

whereagles
Posts: 560
Joined: Thu Nov 13, 2014 11:03 am

Re: Marcel Duchamp endgame "splits" engines / hash

Post by whereagles » Tue Feb 27, 2018 4:03 pm

what's the call on the position?

I put it on SF9 and it can't get out of a draw.. did Marcel get it right?

Jouni
Posts: 1956
Joined: Wed Mar 08, 2006 7:15 pm

Re: Marcel Duchamp endgame "splits" engines / hash

Post by Jouni » Tue Feb 27, 2018 4:08 pm

Analysis by Stockfish 9 64 BMI2:

1.Ke3 h4 2.Rg7+ Kf1 3.Kf3 h3 4.Rh7 Ke1 5.b6 f5 6.Kg3 h2 7.Kg2 h1Q+ 8.Rxh1+ Ke2 9.Rh7 f4 10.Re7+ Kd3 11.Kg1 Kc4 12.Kf2 Kc5 13.Rh7 Kxb6
= (0.00) Depth: 39/27 00:00:29 13703kN, tb=265328
Jouni

Post Reply