UCI engine authors: Please add support for 'searchmoves'

[dadij]

I don't see much benefit in having a command like searchmoves anyway. If you want a certain move searched, you should simply force the move into the engine, and search the position after it...

Now it's my turn to say "I think that's a very strange statement". It seems that you have a very limited view about how engines can be used for analysis with searchmoves. Or perhaps you didn't know that you can send a list of moves with searchmoves. Here are two simple examples (there are many other possible scenarios) where searchmoves makes a huge difference:

1) I have been building my opening repertoire. In a certain position I have deeply analyzed 4 moves which I consider important. Now I want to know if there might be something interesting that I'm overlooking in the remaining moves. Should I use your method of feeding each of the 25 remaining moves manually to the engine, one by one and watch it analyze the resulting position? Or would it perhaps be more efficient to use something like Aquarium's "Analyze, but exclude already analyzed moves" and get the results in approximately the same time as it would take to feed 1 of the 25 moves to the engine?

2) IDeA has generated 4 alternatives in a position and needs the fifth one. You method would simply kill IDeA as a valuable analysis tool. Searchmoves solves the problem efficiently.

[hgm]

Doesn't it know in advance that it will need 5 moves, then? It would be highly preferable to find the bet 5 moves in a multi-PV search. Finding 4 moves first, and then searching from scratch to find the 5th by excluding the first four is very inefficient: the first thing the search will try to do is transpose back into the sub-tree from those first 4 moves, so that you would have to re-generate large part of it. In a multiPV search these would all be hash hits.

Feeding 25 moves by hand is just as cumbersome as typing a list of 25 moves by hand. The idea is of course that the GUI would do this for you (create the list or step through the moves).

[dadij]

Doesn't it know in advance that it will need 5 moves, then?

No, and neither do I when I'm building my repertoire. This is a common scenario and is not solved by your workaround. That's why searchmoves is needed.

[jesper_nielsen]

I just though that it was a bit funny that you would kinda semi ask authors to "obey the protocol!", when IDeA itself kinda semi does not, or at least it sails in some gray waters.

So to sum up: I saw my mail as a continuation of your mail, trying to make engine writers aware of what is required of the engine, in order for it to be used in IDeA.

My take on this is that one should never try to correct errors of one program in another program. If Aquarium sends invalid FENs, it is clearly non-compliant with UCI, which requires valid FENs. No gray area there at all.

Let them repair it, and don't stoop to degrading standards...

While I agree with you in principel, in reality the aim of my engine is not necessarily to comply 100% with the UCI protocol. The aim is to be able to be uses in as many GUI's as possible.

Other authors are of course free to do as they want

And in this specific situation, it is possible to add support for "incomplete" fen strings without breaking the compliance with UCI. Meaning, a GUI that sends a complete fen string always will still work.

Another reason for me to accept incomplete fen strings is purely egoistic:
I am the only person ever in the entire universe who would want to use Pupsi in IDeA for analysis. And I have an oppertunity to do just that, with very little work.

Also just an observation:

From a GUI point of view, it makes sense to omit the move counters when doing this type of analysis. It wants a search result of a position node to be independant of path data. The path dependence is added when maintaining the tree.

Just my two ears!
Kind regards,
Jesper

[Gian-Carlo Pascutto]

Doesn't it know in advance that it will need 5 moves, then?

No, the tree is constructed one move at a time. The second move might never be needed depending on the result of the first. (If it gives a cutoff, sortof)

I don't think you can get this effect via multipv, but you are of course right that searchmoves can be emulated by going into each move and doing a search there. However, in this case you lose bound information, so it's less efficient than searchmoves.

The last problem would have been solvable in a more generic manner if uci had support "go window [x,y]" of something like that. In fact, you could do many more interesting things if UCI had supported that :-/

[hgm]

Indeed, your thought are going in the same direction as mine. I was thinking of command "go alpha VALUE".

But never mind UCI, of course. We can always add it to WinBoard protocol. Allow go [ALPHA [BETA]] when the engine has sent feature window=1.

[dadij]

but you are of course right that searchmoves can be emulated by going into each move and doing a search there. However, in this case you lose bound information, so it's less efficient than searchmoves.

I misunderstood above that this was actually a suggestion for a GUI modification. Maybe because I don't have any control over that (except by writing a 'Please' post like I did here).

The last problem would have been solvable in a more generic manner if uci had support "go window [x,y]" of something like that. In fact, you could do many more interesting things if UCI had supported that :-/

I'm sure that Victor would be interested in hearing suggestions which would make IDeA (and other such analysis) more flexible and/or efficient, even with extensions to the UCI standard. In fact, I think that Rybka's MultiPV_cp was his idea.

[Desperado]

...
It's not the GUI authors' role to interpret the UCI standard. That's the role of the engine authors.
...

That is simply not true!.
As example i want to mention a GUI that i love as chessplayer,but
dont like very much as engine-author.

The all known Chessbase-GUI is a perfect example.

- doesnt support _option buttons_ in options dialog (definitely)
- deosnt support ucinewgame (definitely)
- workaround ponder (sending fen + movelist)
...

In other words Chessbase doesnt handle the _standard UCI_ as standard.

And now ??? If the GUI authors doesnt support the standard, should i have to write workaround code for _every_ Gui ???
That is definitely not the sense of a standard protocol. or am i wrong ?

_BOTH_ sides should support the standard, engine-authors and gui-authors.

With my little experience i think most of the engine authors keep the standard, independent if the commands make sense or not, while
GUIs more often have some non-standard interpretation of the protocol.

So i agree with: if the uci standard has a "searchmoves" command it should be supported by the engine-authors _and_ by the GUIs of course.

(i think it should never depend on personal taste,needs, if a standard command is implemented. Btw, for me a searchmoves command
can be useful, while for others may be not.Anyway, it is standard-uci
so implentation has to be done in my opinion)

Michael

[hgm]

I misunderstood above that this was actually a suggestion for a GUI modification. Maybe because I don't have any control over that (except by writing a 'Please' post like I did here).

Well, that was one of the points I would like to make. You don't have any control over the GUIs, but neither do you have any control over the engines. It might be much easier to solve something in the GUI (especially if it is a GUI bug, like sending non-compliant FENs) than to adapt a hundred engines. A please post directed at the GUI author would make much more sense in that case than one directed at engine authors.

[Gian-Carlo Pascutto]

- deosnt support ucinewgame (definitely)

ucinewgame was added to the UCI protocol a long time after the specification was published. It's perfectly OK for a GUI to not use it and still claim UCI support. You cannot write a GUI to support things which aren't even specified yet! Likewise it's never needed to support optional frills to claim protocol compliance.

An engine which needs this command to work correctly is simply broken, because you cannot depend on it being sent. A new GUI may send it for your convenience but there certainly isn't any requirement to do so.

If after reading this you think there's no point in having the command in the first place: you're right!