-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3-rep. draw apparently stops analysis of other moves #679
Comments
Can someone please take a look and analyze the problem here and also is this in any way related to why SF drew its game in just 21 moves against Nirvana? Developers please advise. |
@rwst What was the hash size that was used in your 2 games ? I have not looked at the Nirvana game. However the issue raised by @rwst is quite interesting A) In his position Black is currently down a full rook and a pawn, Black can safely go for a perpetual draw with 17...Qe3+, or 17...Bg7. But there is a 3rd move, 17...Rg8 !! which first looks like a looser, than will show some perpetuals score and which finally will appear as a winner against any of White defense in this extremely imbalanced position. @rwst says that in his first 15min/0 game, SF7 (from 5972c4a) was able to find this 17...Rg8 move (with 4 threads, in 134s) Using that same 2016-Jan SF7, my slow 4 core machine can find If I use the 2016-Apr-12 version (the one just before the #631 version) However, with a recent master (Pins or discovered attacks on the opponent's queen), So possibly the problem is again from that #631.
and see if 17...Rg8 is found in reasonable time ? B) In the second 15min/0 game, we see that master SF takes only 18s to decide for 17...Qe3 + Here it seems that we have some areas of improvement. In worst case SF can secure the draw, and in the best case, it would give it an opportunity to find a brilliant win. The same is true when opponent has a perpetual. D) What is sad is that as soon as one manually force the 17...Rg8!! move |
The size of hash for both was set to 1024. The machine also is fast, a On Fri, Jun 3, 2016, 21:18 Rocky640 notifications@github.com wrote:
|
Thanks, @rwst setoption name Threads value 4 and tell us how much time it takes to find Rg8 B) Same question with # 646 setoption name Threads value 4 (Maybe it will not be able to find it...this is what I want to verify !) |
Currently root moves are copied to all teh threads but are DTZ filtered only in main thread at the beginning of teh search. This patch moves the TB filtering before the copy of root moves fixing issue #679 official-stockfish/Stockfish#679 No bench change.
For fun tried a version of switching into multipv mode when draw is detected. For simplicity did not extract type of draw for which to switch. Also did not bother much thinking what will happen for smp. For one 1 core, which must be repeatable:
For many cores I guess it will depend on luck.
Try for 6:
|
What is interesting with 1) is that Rg8 is considered early and lot of time put into it, but then for some time moved to a much lower position. At depth 42 most of the time goes into Rg8 at position 3. But with 2) it's worse---while higher depths are reached faster the Rg8 is positioned lower consistently so that moves like f8g7 or c8d7 get the time first. On another note I think Stockfish should report the commit it was built from because it can be unclear just from the date given. |
Can you do a similar test with (This is SF 7 restore dev). Does it still like h8g8 (with a positive cp) after a few minutes ? |
Is there a reason why you couldn't do these yourself? |
I was in a middle of a SPSA tuning session which could not be stopped and was taking all my resources. |
Something similar happens in analysis of Wei Yi RF7 game against Bruzon.
On my slow system latest master sees Rf7 instantly but with 2 move perpetual but keeps giving higher and higher depth while giving only this 2 move perpetual. Only when i forward to 24 Kxd5 then it sees the win. |
@rohitrajiit How did you run it? Which fen? For now it does not wotk in analysis mode, only with time management |
@rohitrajiit: Ok, I see. This is quite similar to previous game after 23. Qh7+ Ke6. Here i suppose you checked that master want to go for repetition with 24. Qh3+ -- I did not check what master does. I had only one core to spare now:
Takes long time to find 545sec (I guess I have lower nps because cpus are busy) .
setoption name Hash value 1024
|
Checked also master. It does not have problem finding 24. exd5+ with 1 core
|
Closed. |
Currently root moves are copied to all teh threads but are DTZ filtered only in main thread at the beginning of teh search. This patch moves the TB filtering before the copy of root moves fixing issue #679 official-stockfish/Stockfish#679 No bench change.
In this 15min/0 game SF commit 5972c4a wins against github master,
while master with Black can't see the win, even when backtracked
to before 17.Kd2. Does a 3-move rep. draw completely stop the engine
from fully analyzing the position?
versus
Position after 17.Kd2:
N1bk1b1r/pp3p1p/3p4/2q5/1n2Pp1P/3P4/PPPK2P1/R1BQ1B1R b - - 8 17
The text was updated successfully, but these errors were encountered: