Twisted Logic bug

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

Moderator: Ras

Edsel Apostol
Posts: 803
Joined: Mon Jul 17, 2006 5:53 am
Full name: Edsel Apostol

Re: Twisted Logic bug

Post by Edsel Apostol »

zamar wrote:
Edsel Apostol wrote: The pruning method in the latest TL is more conservative compared to previous versions but if compared with other engines it is still very aggressive. Note that I don't have depth limits with pruning in TL so it can prune a very big subtree for faster search but in expense of accuracy. This may be one of those positions that it is inaccurate.
Interesting decision! My intuition says that in high depths it could be better to do huge reductions (fx. 6 plies) instead of completely pruning subtree. This way one could guarantee minimum accurary at very low cost. Have you thought about this?
I have tried that before but I couldn't notice much difference based on my initial tests. I didn't pursue it further. It results to a lot of quiescence nodes being searched and if one's qsearch is slow, it would slow down the engine.
Edsel Apostol
Posts: 803
Joined: Mon Jul 17, 2006 5:53 am
Full name: Edsel Apostol

Re: Twisted Logic bug

Post by Edsel Apostol »

hgm wrote:The question that puzzled me, is: what exactly did you prune, and whyever did you do that? Not seeing that Kd4 is losing seems to require you to prune the only obvious move in various positions, such as Kf4 (securing the promotion of your passer) or Qd1+ (starting checking when the opponent still has an undefended Queen on the board directly after promotion).
I reviewed my code and I think it is not the prunings that's the cause of the problem but the very aggressive reductions. It reduces almost any non tactical moves and it is iterative. When it sees in the tree that the opponent promotes to queen, the drawing chances of queening also is being pushed further in the horizon by check extensions.

Latest experimental version sees the best move in less than a second at depth 12.