UCI engine authors: Please add support for 'searchmoves'

Discussion of chess software programming and technical issues.

Moderator: Ras

dadij
Posts: 40
Joined: Wed Jul 05, 2006 8:25 pm

UCI engine authors: Please add support for 'searchmoves'

Post by dadij »

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.
jesper_nielsen

Re: UCI engine authors: Please add support for 'searchmoves'

Post by jesper_nielsen »

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.
Surprisingly many Chess GUI's lack proper support for the UCI command "position fen <fenstring>". :D

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. :D

Kind regards,
Jesper
User avatar
smrf
Posts: 484
Joined: Mon Mar 13, 2006 11:08 am
Location: Klein-Gerau, Germany

Re: UCI engine authors: Please add support for 'searchmoves'

Post by smrf »

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.
User avatar
hgm
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'

Post by hgm »

smrf wrote:Merely 8x8 Chess actually is boring.
Not if you play Knightmate! :lol:
dadij
Posts: 40
Joined: Wed Jul 05, 2006 8:25 pm

Re: UCI engine authors: Please add support for 'searchmoves'

Post by dadij »

jesper_nielsen wrote: Surprisingly many Chess GUI's lack proper support for the UCI command "position fen <fenstring>". :D

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. :D
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.

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).
User avatar
hgm
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'

Post by hgm »

dadij wrote:It's not the GUI authors' role to interpret the UCI standard. That's the role of the engine authors.
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
Posts: 40
Joined: Wed Jul 05, 2006 8:25 pm

Re: UCI engine authors: Please add support for 'searchmoves'

Post by dadij »

hgm wrote:Of course it is the GUI athor's task to interpret the UCI standard, and faithfully enforce it.
OK, I agree with you. Both parties must do that.
hgm wrote:There should be no ambiguities in the standard
I agree, but the fact is that some parts of the standard leave the reader wondering.
hgm 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.
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 subject :wink:)
jesper_nielsen

Re: UCI engine authors: Please add support for 'searchmoves'

Post by jesper_nielsen »

dadij wrote:
jesper_nielsen wrote: Surprisingly many Chess GUI's lack proper support for the UCI command "position fen <fenstring>". :D

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. :D
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.

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 see that my reply was taken probably the wrong way! :oops:

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.
User avatar
hgm
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'

Post by hgm »

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...
User avatar
hgm
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'

Post by hgm »

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.
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...