Sting SF 1.0 is out

[perejaslav]

More to the point is that the analysis shows that Sting doesn't understand that it's a draw (eval -11.87!), whereas Houdini does and shows a 0.00 score.

Robert

Nope. See my post above

[Matthias Gemuh]

Houdini needs to use a dirty option "If infinite search"
Let Houdini play and solve in the same way.
Sting SF JA does it without any tricks on a very slow computer.

Code: Select all

  42	27:51	 439.244.155	262.716	-11,87	Be1b4 Ra5a8 Kd3c2 Ra8b8 Kc2d3 Rh7h8 Kd3c2 Ke7d7 Kc2c3 Kd7c8 Kc3d3 Rh8g8 Kd3c3 Kc8d7 Kc3d3 Rb8c8 Kd3c2 Rc8a8 Kc2d3 Kd7e7 Kd3e3 Rg8h8 Ke3d2 Ra8b8 Kd2e3 Rh8h7 Ke3d2 Rb8h8 Kd2c2 Rh8b8

More to the point is that the analysis shows that Sting doesn't understand that it's a draw (eval -11.87!), whereas Houdini does and shows a 0.00 score.

Robert

Maybe you (and many others) don't understant that the high evaluation means nothing if there is no gain in next depths.
Many of parameters are dangerous in use. Users don't understand it.
regards
Marek

-11.87 means an inevitable loss.

If a GUI adjudicates the game as a loss, blame the engine, not the GUI.

Matthias.

[lech]

Strange indeed:

Code: Select all

 [-4.26]  d=40  1.Bxa5 b4 2.axb4 Kd7 3.Kc3 Rh8 4.Bb6 Ra8 5.Ba5 Bg8 6.Kb2 Ke7 7.Ka3 Rf8 8.Kxa4 Rb8 9.Ka3 Ra8 10.Kb3 Bf7 11.Kc3 Kd7 12.Kb2 Bg8 13.Kc3 Rc8 14.Kd3 (0:02:30) 1344021kN
 [-4.26]  d=39  1.Bxa5 b4 2.axb4 Kd7 3.Kc3 Rh8 4.Bb6 Ra8 5.Ba5 Bg8 6.Kb2 Ke7 7.Ka3 Rf8 8.Kxa4 Rb8 9.Ka3 Ke8 10.Kb3 Kd7 11.Kc2 Kc8 12.Kc3 Ra8 13.Kb3 Kd7 14.Kc3 (0:01:43) 920517kN
 [-4.26]  d=38  1.Bxa5 b4 2.axb4 Kd7 3.Kc3 Rh8 4.Bb6 Ra8 5.Ba5 Bg8 6.Kb2 Ke7 7.Ka3 Rf8 8.Kxa4 Rb8 9.Ka3 Ke8 10.Kb3 Kd7 11.Kc2 Ra8 12.Kd3 Bf7 13.Kc3 Bg8 14.Kd3 (0:01:11) 629918kN
 [-4.26]  d=37  1.Bxa5 b4 2.axb4 Kd7 3.Kc3 Rh8 4.Bb6 Ra8 5.Ba5 Bg8 6.Kb2 Ke7 7.Ka3 Rf8 8.Kxa4 Rb8 9.Ka3 Kd7 10.Kb3 Kc8 11.Ka3 Ra8 12.Kb3 Kd7 13.Kc3 Kc8 14.Kb3 (0:00:48) 424940kN
...
 [-4.85]  d=23  1.Bxa5 (0:00:02) 19410kN

FiftyMoveDistance set to 10 too

It seems to be possible if Houdini counts null moves too.

[Houdini]

More to the point is that the analysis shows that Sting doesn't understand that it's a draw (eval -11.87!), whereas Houdini does and shows a 0.00 score.

Robert

Nope. See my post above

You probably didn't run long enough, SMP analysis is highly variable.
Here's another run using 3 threads, 2048 MB of hash, with FiftyMoveDistance set to 10:

Code: Select all

 37/61	 0:36 	-4.22 	1.Bxa5 b4 2.axb4 Rg7 3.Kc2 Kd7 4.Kb2 Kc8 5.Ka3 Be8 6.Bb6 Kb7 7.Kxa4 Ka6 8.Bd8 Bf7 9.Ba5 Bg8 10.Bb6 Re7 11.Ba5 Re8 12.Bb6 Rb8 13.Ba5 (290.622.815) 7939
 38/61	 0:44 	-4.40--	1.Bxa5 b4 (356.759.692) 7941
 38/65	 1:44 	-4.02++	1.Bb4 (826.809.380) 7895
 38/65	 2:05 	-3.63++	1.Bb4 (986.297.750) 7887
 38/77	 4:11 	-2.59++	1.Bb4 (1.931.969.886) 7674
 38/78	 6:18 	-0.08++	1.Bb4 (2.861.266.468) 7555
 38/78	 7:01 	 0.00 	1.Bb4 Ra8 2.Kc2 Kf8 3.Kb2 Ke8 4.Kc3 Rh8 5.Kd3 Rg8 6.Kc3 Ra5 7.Kb2 Ra6 8.Ka2 Kf8 9.Kb1 Ra8 10.Kc1 Rh8 11.Kb2 (3.162.951.974) 7512
 39/78	 7:22 	 0.00 	1.Bb4 Ra8 2.Kc2 Kf8 3.Kb2 Ke8 4.Kc3 Rh8 5.Kd3 Rg8 6.Kc3 Ra5 7.Kb2 Ra6 8.Ka2 Kf8 9.Kb1 Ra8 10.Kc1 Rh8 11.Kb2 (3.316.386.253) 7488

[lech]

The basic principle, well, how you hope this process works that is not so hard to explain I think. Marek is using Internal Iterative Deepening with a few twists. In IID, the main thing is that in nodes where this might be useful, a shorter search precedes the normal search, for instance to refresh the TT move (CUT node) or in the case of Stockfish that no longer stores a move in VALUE_TYPE_UPPER (ALL) nodes, IID has become something of a Monte Carlo for ALL nodes too, in my opinion, because it still calls IID whenever there is no TT move available, always that is. That is a bit missing from the Stockfish IID documentation, although I'm sure this was not completely missed by the programmers !

As I see it, because you splice off a shorter search each time you go one level deeper (higher) in the tree, you get a sort of binary search, or a fractal pattern of incrementally shallower searches, covering the tree within every iteration. If the move ordering is not too bad, it is likely that the interesting nodes for instance the chains of TT moves in a nullwindow search or the PV in a PV search, are visited several times in every iteration and, if you are lucky, also with each time a bigger search depth. This allows Marek to adjust some bounds in nodes following a capture for the final nominal searchdepth. I have/had a similar idea for the PV search, it is not in the present Rainbow Serpent right now but was is also using these IID searches in only the PV nodes to sharpen the alpha bound. Well, that was the idea anyway... Most elegant would probably to integrate this in the Internal Iterative Deepening block, to avoid too many extra calls to search. You will always get overhead this way of course and I had problems with too deep null window searches that were not helping the PV search anymore. It seemed to become totally useless for PV nodes too far from the frontier. Also storing lower bounds in nodes that are still ALL nodes can wreck your search, if you depend on finding only VALUE_TYPE_UPPER entries there, to classify the node as an ALL node in the first place for example. Those are some of the possible issues to watch.

Also Marek is using the SearchStack to facilitate this proces; because every child node can now easily see what has been changed to the bounds in the parent node instead of just relying on the transposition table to feed this information to the child nodes. This is a very powerful idea from Marek, I had not gotten that far in my version Maybe this is also what Yuri Osipov meant when he talked about a search where nodes are able to change the evaluation of their child nodes, in what I assume he may have learned from decompiling Houdini. The possibilities are very powerful I think, so I would not be surprised this is in more programs. I wrote about my PV search without giving any code before for instance but it is well possible I had read about something similar long before that, I do not know, maybe Cray Blitz already had this in its pipelines

Regards, Eelco

Thanks Eelco for your detailed explain of my part of Sting SF JA.
I don't know what is worth my idea in play. I tested only a few games.
If Sting works quickly, it means that Jim Ablett is able to make wonders.

BTW. Why I always write that it is my idea.
Because, as a rule, there is only one head which is able to do SOMETHING and much more which can carry out a copy ONLY.