Ovyron wrote: ↑Fri Feb 21, 2020 4:11 am
Yes, nothing is special about Stockfish regarding mate announcements.
But that code you quoted was from SF, right? We wouldn't know (even assuming this code is clear, rather than just its comments) whether other engines have similarly intended code. What's special about SF, if nothing else, is that it is open source.
So you are making a claim (no unproven mate announcements) without any way for us to know if it's true (except by asking all the authors).
I assume and hope Leela, for example, does not make mate announcements, because it would not be possible for it to attempt to verify before announcing, unless it completely switched to another mode of computation.
Zenmastur wrote: ↑Thu Feb 20, 2020 1:27 am
Carefully "guiding" and engine during a mate search isn't going to gain you much. There is no way "guiding" an engine can change the length of mate the position contains.
Well, that's not true, the worst case was that position where Stockfish at Depth 70 was still showing a mate in 19 as fastest, and it took it 20 minutes to reach it, and would take it another 20 minutes to reach Depth 71, and not improve the mate as much because it was missing white's optimal attack.
Well, it IS true! The primary reason you are seeing these types of problems is because of a lack of memory. If you had more memory the TT entries needed to find the moves you are having to enter by hand wouldn't be overwritten before they can be used.
I don't know how this simple mate finding problem has taken on a life of its own, but it has! I certainly never intended it to be what it has become. It was simply to demonstrate the limitations of your hardware. Which, by the way, it's done very nicely. The very FACT that you spent more than one evening on it is proof enough. The fact that you stopped game play so you could have more resources for solving this mate is a very strong indication that you need better hardware. You're just too damn stubborn to admit your wrong!
So I don't need to wait that long. Of course, I had needed to find this faster mate in advance by myself, forcing my own white moves instead of those from any engine, but even a trained monkey could do that.
Even a trained monkey can see the value in more powerful machines.
Honestly, the only person I've met that's more stubborn than you is my wife!
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.
Zenmastur wrote: ↑Fri Feb 21, 2020 6:15 am
You're just too damn stubborn to admit your wrong!
So my hardware is lacking and way too slow to solve a fastest mate in reasonable time. Your analysis methods are lacking and way too primitive to draw 1.g4 against me despite my hardware?! I guess we'll see, because solving a fastest mate has nothing to do with drawing or winning chess positions.
jp wrote: ↑Fri Feb 21, 2020 5:45 am
So you are making a claim (no unproven mate announcements) without any way for us to know if it's true (except by asking all the authors).
Yes, because nobody has ever seen a mate in N reported when the defending side could delay it longer, or a mate for a position that wasn't a mate, unless there was a bug.
koedem wrote: ↑Tue Jan 28, 2020 6:03 am
My fork with this change should still work though it is somewhat outdated https://github.com/koedem/lc0
(kudos to MelleKoning for implementing it)
It is not quite as clear cut with 8 million nodes, though around that time "strange" things can start to happen. I don't recall the details but the eval update should be roughly like newEval = oldEval * (oldNodes / (oldNodes + 1)) + Q_of_evaluated_node) / (oldNodes + 1). (so that the eval stays the average of all visited nodes' Qs)
As oldNodes gets in the range of a floats mantissa size the left summand will eventually just be oldEval whereas the right summand will eventually be small enough that adding it doesn't change the eval. (as said, I don't recall how the details were, may be somewhat different formula, but something like that is happening)
Changing Q to be a double is only a 2% or so increase of a nodes size and for long analyses it is kinda necessary but their point I guess is that it doesn't affect match play very much since you rarely hit those node counts there... (I disagree with that sentiment, the main usage of an engine is analysis not match play though considering I wrote 0 lines of code for Leela I am not really in a position to put up demands )
I now have a version of LC0 with double instead of float running! I've changed from float to double mostly in places where your patch would do it. Looking forward to seeing what difference it makes. It slowed it down by something like 5%. But it seems that if LC0 just used more threads for CPU than for GPU calculations, it could be prevented.
I see that the development version of LC0 has a new setting: --cpuct-root-offset which allows it to give more attention to additional root moves. This will allow it to finally do better in a couple of positions in which I was complaining about LC0 focusing too much on one move that looks good early and missing other better moves. I'll run some tests.
Zenmastur wrote: ↑Fri Feb 21, 2020 6:15 am
You're just too damn stubborn to admit your wrong!
So my hardware is lacking and way too slow to solve a fastest mate in reasonable time. Your analysis methods are lacking and way too primitive to draw 1.g4 against me despite my hardware?! I guess we'll see, because solving a fastest mate has nothing to do with drawing or winning chess positions.
1.g4 is lost! Your so stubborn...
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.
[d]1rb3k1/p2nrpp1/2p1N1n1/q2p3p/1P1P3P/3QPP2/P1N2KB1/R6R b - - 0 3
I apologize for all the circus that has been mounted in our game. But these have been the most interesting discussions I've had in a while! I'm picking up the pace and playing much faster now:
)
