Surprisingly many UCI engines still lack support for 'searchmoves'. The reason is probably that there was little demand for it in the past. This is changing, however, and now Aquarium relies heavily on this UCI feature in many of its analysis methods, including IDeA. It is also used in infinite analysis for excluding/analyzing moves in the notation, the tree (opening book) etc.
Therefore I would like to ask UCI engine authors, who haven't already done so, to add support for 'searchmoves' to their engine.
It's also important that 'searchmoves' works with multi-variation (MultiPV) mode.
UCI engine authors: Please add support for 'searchmoves'
Moderator: Ras
-
- Posts: 40
- Joined: Wed Jul 05, 2006 8:25 pm
Re: UCI engine authors: Please add support for 'searchmoves'
Surprisingly many Chess GUI's lack proper support for the UCI command "position fen <fenstring>".dadij wrote:Surprisingly many UCI engines still lack support for 'searchmoves'. The reason is probably that there was little demand for it in the past. This is changing, however, and now Aquarium relies heavily on this UCI feature in many of its analysis methods, including IDeA. It is also used in infinite analysis for excluding/analyzing moves in the notation, the tree (opening book) etc.
Therefore I would like to ask UCI engine authors, who haven't already done so, to add support for 'searchmoves' to their engine.
It's also important that 'searchmoves' works with multi-variation (MultiPV) mode.

At least one GUI, that I won't mention, sends an incomplete FEN string.
It is missing the "Reversible Halfmove counter" and the "Fullmove counter" data.
So in order for your engine to be used in un-said interface, be sure it doesn't crash when faced with an malformed FEN string.

Kind regards,
Jesper
-
- Posts: 484
- Joined: Mon Mar 13, 2006 11:08 am
- Location: Klein-Gerau, Germany
Re: UCI engine authors: Please add support for 'searchmoves'
If there would be an appropriate supporting of XFEN including 10x8 Chess variants by GUIs then it would be attractive to rewrite or update some UCI engines. Merely 8x8 Chess actually is boring.
-
- Posts: 28393
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: UCI engine authors: Please add support for 'searchmoves'
Not if you play Knightmate!smrf wrote:Merely 8x8 Chess actually is boring.

-
- Posts: 40
- Joined: Wed Jul 05, 2006 8:25 pm
Re: UCI engine authors: Please add support for 'searchmoves'
Your reply has nothing to do with my question, but I'll answer anyway. I'm sure that if your post actually has something to do with my question you will quickly correct me.jesper_nielsen wrote: Surprisingly many Chess GUI's lack proper support for the UCI command "position fen <fenstring>".![]()
At least one GUI, that I won't mention, sends an incomplete FEN string.
It is missing the "Reversible Halfmove counter" and the "Fullmove counter" data.
So in order for your engine to be used in un-said interface, be sure it doesn't crash when faced with an malformed FEN string.![]()
It's not the GUI authors' role to interpret the UCI standard. That's the role of the engine authors. There are many unclear issues in the UCI standard and in those cases the GUI authors will check if there seems to be a consensus among engine authors how they interpret it. Accepting an EPD string in the "position fen <fenstring>" seems to be a good example where there is a consensus among all major engine authors.
If you read the UCI standard, you will see that it actually mentions EPD. Why would that be? In fact, the only example of a "FEN" string in the standard is actually an EPD string (or equivalent. It's for a FishcerRandom/Chess960 position).
-
- Posts: 28393
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: UCI engine authors: Please add support for 'searchmoves'
I think that a very strange statement. Of course it is the GUI athor's task to interpret the UCI standard, and faithfully enforce it. There should be no ambiguities in the standard, and if there are, all involved parties should err on the safe side. I.e. understand all input that might be legal according to the standard, and give output that will be considered valid in every possible interpretation of the standard.dadij wrote:It's not the GUI authors' role to interpret the UCI standard. That's the role of the engine authors.
-
- Posts: 40
- Joined: Wed Jul 05, 2006 8:25 pm
Re: UCI engine authors: Please add support for 'searchmoves'
OK, I agree with you. Both parties must do that.hgm wrote:Of course it is the GUI athor's task to interpret the UCI standard, and faithfully enforce it.
I agree, but the fact is that some parts of the standard leave the reader wondering.hgm wrote:There should be no ambiguities in the standard
One possible interpretation of the standard is that UCI engines must meet all its requirements, which would include support for 'searchmoves' (just to bring us back to the original subjecthgm wrote:and if there are, all involved parties should err on the safe side. I.e. understand all input that might be legal according to the standard, and give output that will be considered valid in every possible interpretation of the standard.

Re: UCI engine authors: Please add support for 'searchmoves'
I see that my reply was taken probably the wrong way!dadij wrote:Your reply has nothing to do with my question, but I'll answer anyway. I'm sure that if your post actually has something to do with my question you will quickly correct me.jesper_nielsen wrote: Surprisingly many Chess GUI's lack proper support for the UCI command "position fen <fenstring>".![]()
At least one GUI, that I won't mention, sends an incomplete FEN string.
It is missing the "Reversible Halfmove counter" and the "Fullmove counter" data.
So in order for your engine to be used in un-said interface, be sure it doesn't crash when faced with an malformed FEN string.![]()
It's not the GUI authors' role to interpret the UCI standard. That's the role of the engine authors. There are many unclear issues in the UCI standard and in those cases the GUI authors will check if there seems to be a consensus among engine authors how they interpret it. Accepting an EPD string in the "position fen <fenstring>" seems to be a good example where there is a consensus among all major engine authors.
If you read the UCI standard, you will see that it actually mentions EPD. Why would that be? In fact, the only example of a "FEN" string in the standard is actually an EPD string (or equivalent. It's for a FishcerRandom/Chess960 position).

I took the meaning of your mail to be a request for the engine authors to make it possible for GUI's to use them for IDeA (and others like it)analysis.
So the way I read it, the AIM of your mail was to get more engines capable of being used in various analysis interfaces.
With that in mind, the aim of my mail was to make engine authors aware that support for "searchmoves" is not in itself enough. My own engine failed misserably when used in IDeA because of the mentioned "quirk" when receiving fen position data. So to save a few programmers a bit of time I thought I would mention it!
I am not sure if "quirk" is a good word to use, but I don't know what else to call it.
UCI is filled with many, many gray areas, left to the enterpretation of the GUI and the engine.
And in this case I think that IDeA uses one of these gray areas, when leaving out parts of the position data.
My feeble attempt at humour perhaps muddied the picture a bit. Sorry!
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.
Kind regards,
Jesper
Last edited by jesper_nielsen on Mon Sep 14, 2009 1:21 pm, edited 2 times in total.
-
- Posts: 28393
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: UCI engine authors: Please add support for 'searchmoves'
That is a rather unusual interpretation of a protocol. I would say the spirit of UCI is more "ignore at your own risk". This is implicit in most qualifiers to the "go" command: if it says you have 10 sec ("wtime 10000"), and you ignore it and search for 20 sec, you forfeit on time. Similarly, when you ignore the "searchmoves", it would forfeit by playing an illegal move.
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...
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...
-
- Posts: 28393
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: UCI engine authors: Please add support for 'searchmoves'
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.jesper_nielsen wrote: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.
Let them repair it, and don't stoop to degrading standards...