Polyglot1.4.30b

[Michel]

I can turn on the option on by default but I wanted to provoke you a little since you are generally very much opposed to accommodating bugs in other programs (by other people).

Decapitalizing draw seems like the best idea. I need to recaptilalize it afterwards but that it is not a problem since internally the option is stored in the way it came from the engine.

[Michel]

BTW the option windows looks fine in winboard.exe under wine (as does the whole winboard).

It would be perhaps more natural is the PG options and the engine options appeared under different tabs. In that way
you could also strip the "Polyglot" from the name of the PG options gaining a lot of space in this way.

[H.G.Muller]

Well, my first reaction when I read about the WbWorkAround option was indeed: "please don't do that!"

This mess with "Draw" is in fact a perfect illustration of why I am in general so much against catering to buggy engines (or other software): because somewhere far in the past some engine programmer did not feel like making a compliant 1/2-1/2 draw claim, and WinBoad was adapted to the engine rather than the engine forced to stick to the protocol, a long line of WinBoard versions is now contaminated, and will crash on the extended protocol, while in theory that protocol shuould have been upward comptible. Sooner or later such things come back to haunt you.

But I do see the importance of your Polyglot being able to work both with old and new WinBoard versions.

One way out would be to bump the protocol version to 3, and forbid sending of option features in v2. But I would really hate to complicate the protocol for such a silly reason.

I guess the best solution is to use the de-capitalization only on the first option feature, and stop sending option features if the first one is rejected. In practice this makes it likely that even the de-captitaliztion kludge will be never used. An alternative would be to output the Polyglot options before the engine options; then you would be 100% sure that the first option would never contain the word "Draw". Note, however, that I am working about grouping consecutive options starting with the same word in a separate 'panel' of the dialog, and that this woud only work nicely if all Polyglot options are indeed consecutive.

I want to continue my appeal to you for implementing a 'Polygot Save' option, which would save all option settings on a polyglot.ini file. (And perhaps make the name of this file accessible through a 'Polyglot IniFile' -file option that would have the actually used polyglot.ini as default setting.) I still think this would be the logical way to treat this: no other entity than Polyglot should have to be aware of polyglot.ini files. From the previous discussion I understood that your main objections against this where inspired by the Linux situation, where the polyglot.ini file would typically be in some directory like /usr/share/games/polyglot where an ordinary user would have no write permission. But even if that is the case, I think running XBoard + Polyglot as super-user would be a very logical way to edit that polyglot.ini if you wanted to change it. And if you want to run a customized version of the engine, the user would need to keep a polygot.ini with the settings amongst his personal files, and give this file as an argument to Polyglot when running the engine (-scp "polyglot myfruit.ini"). Again it would be very convenient if he could edit the contents of this file through the XBoard menu and save it on the same file, or alter the IniFile name and save it to a new file (this time without a need for being super-user).

[H.G.Muller]

BTW the option windows looks fine in winboard.exe under wine (as does the whole winboard).

It would be perhaps more natural is the PG options and the engine options appeared under different tabs. In that way
you could also strip the "Polyglot" from the name of the PG options gaining a lot of space in this way.

OK, I was planning on putting them in a separate pane ("group box"), and indeed strip the common word Polyglot for every option in that panel. The idea of tabs did not occur to me yet. (Also because I haven't the slightest idea how I could make them.) I was considering displaying them side by side (4 columns in stead of 2) if there get to many options, or equiping the dialog window with a vertical scroll bar. (The latter is trivial as it can be requested as part of the window style, but it has the disadvantage that you would shift the OK and cancel buttons out of view.)

I decided to release the thing for beta-testing before I was finished with such cosmetic refinements, however. In the end I will be able to pull this off, and from looking at the dialog it will be obvious if I failed or not. I am much more worried about options of all types being transmitted in the proper way to the engine. There are enormous opportunities for error there.

[Michel]

I want to continue my appeal to you for implementing a 'Polygot Save' option, which would save all option settings on a polyglot.ini file. (And perhaps make the name of this file accessible through a 'Polyglot IniFile' -file option that would have the actually used polyglot.ini as default setting.)

As said I am currently reworking the handling of options inside PG (it is currently not as nice as it could be). Once that it is done PG will be able to use multiple ini files, save ini files,
use command line options etc...

But I am rather busy so this has to wait a couple of weeks.

[H.G.Muller]

OK, no great hurry there. Basicaly the Engine Settings menu is only scheduled for the 4.4.1 WinBoard release, and we haven't even released 4.4.0 yet. But it might be useful to already anticipate the UCI3 stuff in the protocol specs we release with 4.4.0, so WB engine authors can already anticipate. So next to the option types we already had (-spin, -check, -string, -combo, -button and -save), I want to introduce new types -file, -path and -slider. (For some silly reason, the file-selector dialog you get when pushing a browse button that the dialog creates next to the type-in needs to be a different one for selecting a file and seecting a folder, so the GUI would have indeed to make a distinction between -file and -path.)

So feel free to use -file and -path options; I will make sure that at worst they will be considered synonyms for -string, and -slider as a synonym for -spin as long as the menus do not support these control types, in 4.4.0.

Note that if you equip Polyglot with an option to save th current settings somewhere, you would have to use the -save and not the -button type, to make sure that the GUI flushes any settings altered in the dialog (but not yet OK'ed) before sending the button press to Polyglot.

[F.Huber]

Hi Michel,

look at the following Polyglot log - I'm sure you know what I mean.

Code: Select all

7451.908 Engine->Adapter: info string No Mate in 4 found !  (00:00)
7451.908 Engine->Adapter: bestmove
parse_bestmove(): missing argument
7451.908 POLYGLOT *** QUIT ***
7451.908 Adapter->Engine: quit
7451.908 POLYGLOT Closing engine
7451.908 Adapter->Engine: EOF
7451.958 Engine->Adapter: EOF
7451.960 POLYGLOT Calling exit


I'm trying to run ChestUCI under HGM´s new Winboard 4.4.1, and there's a special problem with matesolvers: they don't always find a mate (either it takes too long or there is just no mate for the given position).
So what should the engine send back to the GUI in this case?

For ChestUCI I've solved this problem by simply returning an empty move (i.e. "bestmove "), and this works fine in all usual GUIs (Arena 1.1, Shredder, Fritz, ...), but Polyglot doesn't accept 'bestmove' without any argument.
Of course I could send back "bestmove a1a1" in this case, but this would probably give some error message about an invalid move, or I could return any arbitrary (valid) move, but that won't make much sense too.

Exactly the same problem happens, when the user aborts the matesearch before ChestUCI has found any mate - also in this case a simple "bestmove " is sent back (because no valid move has been found yet).

So my question now:
Would it be possible to modify Polyglot a bit, so that it accepts such an 'empty' move (ie. "bestmove ") without any error, i.e. it should not quit the engine but just return to its previous state (before the last search was initiated)?
Or maybe you have another idea how this problem (for matesolvers) could be solved in Polyglot (?) ...

Regards,
Franz.

[Michel]

Well sending an empty bestmove appears to be not legal UCI syntax.

But it is possible to ask for a mate in x moves. So there must be some solution.

It is apparently legal to send a "null move" to the gui (bestmove 0000). PG currently does not accept this
though (it is not clear to me if "null move" has its standard meaning here).

How do other engines deal with this? I tried rybka but it ignores the "go mate 2" command.

What should PG report to the GUI in case of an empty bestmove?

[F.Huber]

Well sending an empty bestmove appears to be not legal UCI syntax.

I Know - all protocols (UCI and WB) seem just to have overlooked that a matesolver can't always provide a solution!

It is apparently legal to send a "null move" to the gui (bestmove 0000). PG currently does not accept this
though (it is not clear to me if "null move" has its standard meaning here).

Well, I've already tried several different methods for bestmove (----, 0000, a1a1, ...), but all GUIs just report an "invalid move".
Only Arena (1.1) accepts an empty "bestmove " without any problems (it just returns back to the state before having pressed the 'move' button), e.g. the ShredderGUI also reports an "invalid move", but then it continues normally too.

How do other engines deal with this? I tried rybka but it ignores the "go mate 2" command.

I guess most engines don't have such a mate-searching mode at all.

What should PG report to the GUI in case of an empty bestmove?

Well, that depends on the GUI's reaction. Of course it must be a command that the GUI /in this case Winboard) would accept (i.e. simply go back to the situation before the last 'move' command was executed).
But since I'm not familar with the WB protocol, I can't say how this could be done best in the Polyglot/Winboard combination.

[F. Bluemers]

I Know - all protocols (UCI and WB) seem just to have overlooked that a matesolver can't always provide a solution!

Correct,an engine can only play moves under UCI.
It can't even resign.
normally that would have been a solution for your problem
Best
Fonzy

[F.Huber]

Correct,an engine can only play moves under UCI.
It can't even resign.
normally that would have been a solution for your problem

Well, ChestUCI would never resign - at most it would offer a draw!

Regards,
Franz.

[Michel]

But since I'm not familar with the WB protocol, I can't say how this could be done best in the Polyglot/Winboard combination.

As far as I can tell the WB protocol does not have a provision for mate problems. So in principle the problem cannot even appear...

[F. Bluemers]

Correct,an engine can only play moves under UCI.
It can't even resign.
normally that would have been a solution for your problem

Well, ChestUCI would never resign - at most it would offer a draw!

Regards,
Franz.

also not possible under uci

[F.Huber]

As far as I can tell the WB protocol does not have a provision for mate problems. So in principle the problem cannot even appear...

Maybe Fonzy's idea won't be that bad at all!?
Polyglot could send a "draw offer" to Winboard, if it gets an empty "bestmove " from ChestUCI ...
(this would certainly be no problem with any other engine, because no other engine would ever return a "bestmove " alone)

[F.Huber]

Well, ChestUCI would never resign - at most it would offer a draw!

also not possible under uci

Well, but Michel and you could make it possible under Polyglot (e.g. when getting
"bestmove " from the engine) ...

[Michel]

Actually why not returning an arbitrary valid move with a score of 0.00? That's a clear indication that there is no mate.

However as far as I can tell it is impossible in the WB protocol to tell the engine that it has to analyze a position
as a mate problem. So the problem cannot arise without an extension of the WB protocol.

[F. Bluemers]

Well, ChestUCI would never resign - at most it would offer a draw!

also not possible under uci

Well, but Michel and you could make it possible under Polyglot (e.g. when getting
"bestmove " from the engine) ...

I wonder how it should handle it?
what if a problemsolver should find a draw but fails?
shouldn't it resign anyway?

[F.Huber]

Actually why not returning an arbitrary valid move with a score of 0.00? That's a clear indication that there is no mate.

Well, this arbitrary move would then of course be executed by the GUI, and that's not really comfortable - you would have to take it back again before trying something else (changing any options, etc...)

However as far as I can tell it is impossible in the WB protocol to tell the engine that it has to analyze a position
as a mate problem. So the problem cannot arise without an extension of the WB protocol.

It's not necessary at all to tell a matesolver (e.g. ChestUCI) that it should analyze a position a mate problem - that's quite clear for a matesolver!
In fact ChestUCI doesn't care at all which 'go' command the GUI is sending ('go', 'go infinite', or any other things like 'time' or 'depth') - any 'go ...' is enough and ChestUCI starts thinking.
All other things it must know for solving (like e.g. the mate depth) it gets from its own UCI options.
So there's definitely no need for any WB protocol changes/extensions for matesolving (except this problem of not having found a solution move).

[F.Huber]

I wonder how it should handle it?
what if a problemsolver should find a draw but fails?
shouldn't it resign anyway?

Finding a draw is not really a special problemtype - the only thing I could imagine is finding a stalemate.
But for a problemsolver that's no difference in principle - it's enough to get the needed infos (problemtype, searchdepth) from its own UCI options, and it starts searching after getting a "go" from the GUI, that's all.

And even for a stalemate it should NOT report to the GUI anything like "score 0.0, that's a draw", but simply something like "yep, I've found a solution move ..., and the problem is solved in ... moves" -
or "there's no solution", and in this case a "draw offer" would be just the same as a "resign" (which doesn't look so well IMO ).

[F. Bluemers]

As far as I can tell the WB protocol does not have a provision for mate problems. So in principle the problem cannot even appear...

Maybe Fonzy's idea won't be that bad at all!?
Polyglot could send a "draw offer" to Winboard, if it gets an empty "bestmove " from ChestUCI ...
(this would certainly be no problem with any other engine, because no other engine would ever return a "bestmove " alone)

well,you could use my "extension" to offer a draw.
Learning Lemming uses it for ics play

access to winboard draw/drawoffer and resign,at engine level:

1:to activate draw offers the engine has
to define the "UCI_DrawOffers" parameter with the 'option" command at startup.
2:to offer a draw or accept a draw offer:just send "info string DrawOffer" to polyglot.
3:if winboard sends "draw" polyglot sends "setoption DrawOffer draw" to the engine.
4.to resign: send "info string Resign" to polyglot.
please check the winboard documentation for the draw/drawoffer and resign commands.

but that would only work in my version