mmt Vs. Ovyron (G4 D5 BG2)

Discussion of computer chess matches and engine tournaments.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Raphexon
Posts: 218
Joined: Sun Mar 17, 2019 11:00 am
Full name: Henk Drost

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by Raphexon » Tue Mar 03, 2020 2:39 pm

Ovyron wrote:
Tue Mar 03, 2020 4:31 am
Alayan wrote:
Tue Mar 03, 2020 4:06 am
"But I can check the TB" is completely irrelevant.
It's not, because... I can check the TB.

A position needs to be posted where TBs can't be checked at all, because it's now "your side" who assumes there's a middle game position where my methods wouldn't suffice (so I fail to find the win), where presumably faster hardware would suffice, but examples where I can check the TB don't extrapolate because being able to check TBs is part of "magic tagging" (you see promising lines and you avoid those that reach endgames).

The point of the method is being able to take a shortcut to what unassisted engine would show at high depth, and perform better than it for the cases where it likes a plan that doesn't work because of misevaluation while one can have more accurate evaluation by being able to check TBs online.

In other news, I've been unable to backsolve a mate in 32 to move 40 or before in Zenmastur's challenge, because the number of lines is just absurd, so I'm going to give up now.

(still waiting for mmt's move, in case he missed my last move)
Where do you check for TB8 and TB9?

zullil
Posts: 6213
Joined: Mon Jan 08, 2007 11:31 pm
Location: PA USA
Full name: Louis Zulli

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by zullil » Tue Mar 03, 2020 2:51 pm

Ovyron wrote:
Tue Mar 03, 2020 4:31 am
Alayan wrote:
Tue Mar 03, 2020 4:06 am
"But I can check the TB" is completely irrelevant.
It's not, because... I can check the TB.
With all due respect, this is a really stupid response.

jp
Posts: 1345
Joined: Mon Apr 23, 2018 5:54 am

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by jp » Tue Mar 03, 2020 3:17 pm

zullil wrote:
Tue Mar 03, 2020 10:30 am
I've terminated the search after 6332175484277 nodes and 36 hours. Stockfish-dev has failed to demonstrate a solution. The interested reader is welcome to analyze Stockfish's final PV for correctness ...

<snip>
info depth 91 seldepth 102 multipv 1 score cp 359 nodes 6332175484277 nps 47617940 hashfull 300 tbhits 0 time 132978776 pv f8e7 b6c7 a4e8 c7b6 e7f6 b6c7 f6e5 c7b6 e8a4 b7d8 e5c3 d8b7 c3d4 b6c7 a4b5 b7d8 b5e8 d8b7 d5e6 b7d8 e6f6 c7d6 d4e5 d6d5 e5c7 d8b7 f6g6 b7c5 c7b6 c5b7 e8f7 d5d6 b6d4 b7c5 g6h7 c5e6 d4f6 e6f8 h7h6 f8d7 f6h8 d6c6 f7e6 d7c5 e6c4 c5e4 h8e5 e4d2 c4e6 c6c5 e6f5 c5b4 e5f6 b4c5 f5g6 c5b4 g6d3 b4b3 d3f5 d2f3 f6h8 f3d2 h8d4 d2f3 f5e6 b3c2 d4h8 f3e1 h6h7 e1g2 e6d7 g2e3 d7a4 c2d2 a4c6 d2e2 h7h6 e3c2 c6b5 e2d1 b5c4 c2e3 c4e6 d1d2 e6g8 e3f5 h6g5 f5e7 g8a2 d2c2 a2e6 c2d2 h8f6 e7c6 e6d7 c6b4 f6h8 b4a6
info depth 90 seldepth 111 multipv 1 score cp 369 nodes 6332175484277 nps 47617940 hashfull 300 tbhits 0 time 132978776 pv f8b4
bestmove f8b4 ponder b7d8
Thank you. I assume it's this second line that is SFdev's best effort. I have to convert it to intelligible form first, before I take a look. (The pgn code here won't understand [from-square][to-square] notation, so I can't just paste it directly.)

The first thing I'll say is this: I bet the cp 359 depth-91 eval is close to or even exactly the same eval SFdev shows at depth 1 (or even depth 0)!

The second thing I'll say: if I can count (not a certainty with the layout and my eyesight), the PV is 49 moves long. I guess SFdev "knows" the 50-move rule and therefore "refuses" to give a line with 50 moves, because it still "believes" it's +3.59. I guess that's also why it's "only" depth 91, seldepth 102. I assume normally 6.3 trillion nodes would be far greater depth than that (for only 5 pieces), and SFdev just widened its search instead of its normal deepening, for the same reason. Can someone confirm this?

The third thing I'll say follows from the second thing: it'd be interesting to see if SF versions with fortress detection (e.g. Honey, Crystal) will just show 0.00.

jp
Posts: 1345
Joined: Mon Apr 23, 2018 5:54 am

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by jp » Tue Mar 03, 2020 4:23 pm

Ovyron wrote:
Tue Mar 03, 2020 4:31 am
Alayan wrote:
Tue Mar 03, 2020 4:06 am
"But I can check the TB" is completely irrelevant.
It's not, because... I can check the TB.

A position needs to be posted where TBs can't be checked at all, because it's now "your side" who assumes there's a middle game position where my methods wouldn't suffice (so I fail to find the win), where presumably faster hardware would suffice
Let's just be clear. This has nothing to do with the middle game specifically or faster hardware. Questions about faster hardware are totally separate.

Raphexon
Posts: 218
Joined: Sun Mar 17, 2019 11:00 am
Full name: Henk Drost

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by Raphexon » Tue Mar 03, 2020 5:41 pm

SF isn't a losless minimax engine, is it?

There will always be moves it will never consider, regardless of hardware.

jp
Posts: 1345
Joined: Mon Apr 23, 2018 5:54 am

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by jp » Tue Mar 03, 2020 5:55 pm

zullil wrote:
Tue Mar 03, 2020 10:30 am
info depth 91 seldepth 102 multipv 1 score cp 359 nodes 6332175484277 nps 47617940 hashfull 300 tbhits 0 time 132978776 pv f8e7 b6c7 a4e8 c7b6 e7f6 b6c7 f6e5 c7b6 e8a4 b7d8 e5c3 d8b7 c3d4 b6c7 a4b5 b7d8 b5e8 d8b7 d5e6 b7d8 e6f6
If I have not stuffed up, this is 11. Kf6?, leading to



and DTZ jumping from 87 to 106 (added to the 21 plies already played).

But I think I need a more reliable way to play through the moves.

c7d6 d4e5 d6d5 e5c7
13. Bc7 leads to



with DTZ out to 114 (added to what's already played).

d8b7 f6g6 b7c5 c7b6 c5b7 e8f7 d5d6 b6d4 b7c5 g6h7 c5e6 d4f6 e6f8 h7h6
20. Kh6 leads to



with DTZ 108 (added to what's played).

Okay, I need to find a way to convert the output automatically.

Zenmastur
Posts: 851
Joined: Sat May 31, 2014 6:28 am

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by Zenmastur » Tue Mar 03, 2020 7:09 pm



:P
Only 2 defining forces have ever offered to die for you.....Jesus Christ and the American Soldier. One died for your soul, the other for your freedom.

jp
Posts: 1345
Joined: Mon Apr 23, 2018 5:54 am

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by jp » Tue Mar 03, 2020 7:22 pm

Thanks, Zenmastur! (How do you do it?)
(The final position is DTZ 63, which sounds relatively "good", but maybe just means in the last 29 moves of SF's pV, its Black moves were worse than its White moves.)

jp
Posts: 1345
Joined: Mon Apr 23, 2018 5:54 am

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by jp » Tue Mar 03, 2020 7:32 pm

Ovyron wrote:
Tue Mar 03, 2020 8:33 am
4rnk1/4qpp1/2p5/3p3Q/1PnP3P/4PP1N/r1N1RK2/7R w - -
Komodo 13.2, depth 27: -1.93 (Kg3).

Zenmastur
Posts: 851
Joined: Sat May 31, 2014 6:28 am

Re: mmt Vs. Ovyron (G4 D5 BG2)

Post by Zenmastur » Tue Mar 03, 2020 8:36 pm

jp wrote:
Tue Mar 03, 2020 7:22 pm
Thanks, Zenmastur! (How do you do it?)
(The final position is DTZ 63, which sounds relatively "good", but maybe just means in the last 29 moves of SF's pV, its Black moves were worse than its White moves.)
I took a PGN header with a FEN line like this one:

Code: Select all

[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "*"]
[FEN "5B2/1n6/1k6/3K4/B7/8/8/8 w - - 0 1"]
Then I appended the moves "as is" from Zullil's post and saved it as a pgn file. I then loaded it into a chess program. Easy peasy! :D :D :D

If should be noted that it's a COMPLETE waste of time to try to analyze this with ANY engine that enforces the 50-move-rule. Since the mate is longer than 50 moves the program will simply start making what appears to be "random" moves once it reaches the 50-move limit without finding anything of note. The 50-move-rule in effect will make the engine look like a fool. To do a "proper" search and find the best line of play requires that the code that enforces the 50-move-rule be removed or at least turned off.

Unfortunately, none of the major engines allow this, at least that I'm aware of.

The problem is that a mate when it's first found is likely to be very long, MUCH longer than the minimum length mate. Then, with additional searching, the mate gets shortened when the engine finds better lines of play. This can NEVER happen if the 50-move-rule is enforced and the first mate found is over 50 moves long.

So, even if the mate is a mate in 49 AND the engine first finds a mate in 73 (for instance), instead of refining the line of play to achieve a shorter mate the engine will disregard the line of play because its over 50 moves long. If it ever finds the mate in 49, it will be by pure luck.

It would be nice if they would put an option to disable the 50-move rule for analysis. But, I'm not holding my breath! So, in the mean time, it's a waste of time to try to analyze positions like this. It's not that Stockfish can't solve it, it's prevented from solving it because of the 50-move-rule.

I wonder how many people have tried this and never realized you can't get there from here! :evil: :evil: :evil:

I know of at least one! :D :D :D

Regards,

Zenmastur
Only 2 defining forces have ever offered to die for you.....Jesus Christ and the American Soldier. One died for your soul, the other for your freedom.

Post Reply