Discussion of anything and everything relating to chess playing software and machines.
Moderators: hgm , Rebel , chrisw
Joerg Oster
Posts: 937Joined: Fri Mar 10, 2006 4:29 pmLocation: Germany
Post by Joerg Oster Wed Jun 01, 2016 9:40 pm
hgm wrote: It also only searches one ply deep. Which probably explains it, because Stockifish usually doesn't search any moves before the depth is 8, and if you have no moves mate is a natural conclusion. But of course that it only searches 1 ply is odd in itself.
Both moves are 'only' moves. The only moves which preserve the draw.
So when all other moves are filtered out, we only have one root move, we immediately break from the iterative deepening loop which might indeed explain this odd behaviour.
@Marco: Maybe we should add another condition, to search at least to a certain depth or a minimum thinking time.
Jörg Oster
bob
Posts: 20943Joined: Mon Feb 27, 2006 7:30 pmLocation: Birmingham, AL
Post by bob Wed Jun 01, 2016 11:56 pm
jhellis3 wrote: When you post a solution on page 1 and 7 pages later... /feelsbadman
There _is_ no solution for this problem...
jhellis3
Posts: 546Joined: Sat Aug 17, 2013 12:36 am
Post by jhellis3 Thu Jun 02, 2016 12:59 am
Obviously there is
.
P.S. You don't matter.
Michel
Posts: 2272Joined: Mon Sep 29, 2008 1:50 am
Post by Michel Thu Jun 02, 2016 1:51 am
jhellis3 wrote: Obviously there is
.
P.S. You don't matter.
Please no need for insults.
Does your patch really solve the case of a position which cannot yet be converted by search into a known win but which can be converted by a sacrifice into a (probably difficult) tablebase win?
In that case the "natural" behaviour is to postpone the sacrifice _if this does not throw away the proven win_, in the hope that this will bring a solution by search nearer.
However this appears to require more complicated code that your simple patch. But maybe I am misreading it?
Ideas=science. Simplification=engineering.
bob
Posts: 20943Joined: Mon Feb 27, 2006 7:30 pmLocation: Birmingham, AL
Post by bob Thu Jun 02, 2016 2:09 am
jhellis3 wrote: Obviously there is
.
P.S. You don't matter.
Obviously there isn't. EGTBs, whether DTM, DTZ or WDL have been around for 20+ years. The algorithm to build them is 50 years old. And the problems have always been there. And they will remain because trying to fix any shortcoming hurts more than it helps...
bob
Posts: 20943Joined: Mon Feb 27, 2006 7:30 pmLocation: Birmingham, AL
Post by bob Thu Jun 02, 2016 2:15 am
Michel wrote: jhellis3 wrote: Obviously there is
.
P.S. You don't matter.
Please no need for insults.
Does your patch really solve the case of a position which cannot yet be converted by search into a known win but which can be converted by a sacrifice into a (probably difficult) tablebase win?
In that case the "natural" behaviour is to postpone the sacrifice _if this does not throw away the proven win_, in the hope that this will bring a solution by search nearer.
However this appears to require more complicated code that your simple patch. But maybe I am misreading it?
Some provide answers without fully understanding the question/problem. Ken Thompson talked about these problems in the 70's. Berliner talked about them in the 80's. We are STILL talking about them today. Just because someone _believes_ they have solved a problem does not make it so. Particularly when knowing how bright the people are/were that worked on this from the beginning, not to mention Stiller and such. Steven Edwards had these things (DTM anyway) in 1995, where I incorporated them into Crafty. And I've seen this bizarre behavior ever since. Some things you can partially solve. Such as the "swindle mode" in Crafty that uses the search without endgame tables, but excludes any losing moves (according to egtb) before starting the search (in a drawn position). This at least stops one type of bizarre behavior where you are in a difficult to draw KQP vs KQ, and the endgame tables will cheerfully toss the pawn away since that is STILL a draw. But that is only a tiny part of the class of problems we see.
jhellis3
Posts: 546Joined: Sat Aug 17, 2013 12:36 am
Post by jhellis3 Thu Jun 02, 2016 2:22 am
But maybe I am misreading it?
Yes, the win/loss values are evaluation biased.
It will still prefer TB wins over engine "known" wins (not mate), but this only makes sense as there is no guarantee that the engine heuristics are infallible.
Of course, you don't have to take my word (or anyone else's
) for it. Trivial to compile and see for yourself....
Laskos
Posts: 10948Joined: Wed Jul 26, 2006 10:21 pmFull name: Kai Laskos
Post by Laskos Thu Jun 02, 2016 4:56 am
8 games Natural TB misses wins against Syzygy, passed 1s/move and 5s/move tests. All of them 2 minors against a N.
Modern Times
Posts: 3546Joined: Thu Jun 07, 2012 11:02 pm
Post by Modern Times Thu Jun 02, 2016 7:39 am
bob wrote:
Some provide answers without fully understanding the question/problem. Ken Thompson talked about these problems in the 70's. Berliner talked about them in the 80's. We are STILL talking about them today. Just because someone _believes_ they have solved a problem does not make it so. Particularly when knowing how bright the people are/were that worked on this from the beginning, not to mention Stiller and such.
Valid points for sure, but it does not mean that there isn't a solution and that someone else won't find it in future. That is how scientific breakthroughs tend to happen.
mcostalba
Posts: 2684Joined: Sat Jun 14, 2008 9:17 pm
Post by mcostalba Thu Jun 02, 2016 8:08 am
Joerg Oster wrote: Today I played some games between natural and syzygy, 2 min + 1 sec.
Thanks for reporting and finding the issue. I have fixed it now!
.