WinBoard Protocol extensions

[Dann Corbit]

Agreed, we would have to enforce some standardizaton of names, so that all engines will use the same name for a certain format. But I guess formats will not appear so frequently and rapidly that this would be a problem.

I suppose you did not like the 't' in egtb necause you consider bitbases not really tablebases? Let me suggest then we use the term with which Guy Haworth refers to them in general: EGT for end-game tables. So we would use 'feature egt' and 'egtpath'.

What would happen if I develop my own EGTs for my own engine? Do I need the protocol to be updated? How will that work?

Miguel

EGTs should not be very different that an opening book, there are supporting files of a specific engine. I do not see the need to be so specific with the names of EGTs hardwired in the protocol (unless I misunderstood something).

Miguel

For non-bitbase EGT's it would be nice if programmers would use a common source or (at least) only a few different formats.

I have 50 GB of Nalimov tablebase files. It would not be nice if I had to repeat that 40 times for 40 different formats.

Other formats that I have are Edwards format, proprietry format for Booot and FEG. I may have had Scorpio EGTB at one time, but I don't think I have any now.

At any rate, everyone using their own bitbase is not much of a burden. A proliferation of Endgame Tablebase formats will eventually make the disk drive manufacturers a lot of money but just annoy everyone else.

[H.G.Muller]

Agreed, but this is a bit beyond the scope of the protocol design. If authors decide upon using their own tablebase format, they will be able to use it on their own computer at home, on ICS, and in tournaments where you have to bring your own hardware, like WCCC. But it should also be clear to them that they have as much chance as a snowball in hell that they will be able to use those tablebases in tournaments like ChessWar and WBEC, or in CCRL tests. Those who conduct such tournaments and matches will of necessity put a limit to the disk-space a prgram will be allowed to use for its install, and typical EGTB sizes of anything more than 4-men will grossly exceed those quota.

So unless their format has so many advantages over the market leader that many other engines will prefer it as well, it won't be available. If popular demand for the format arises, this might sway the testers of making them available. Perhaps first only in specialized tourneys for engines that require this format, on computers dedicated to the purpose. If different formats become wide-spread, testers might consider to drop all but the most convenient one (in terms of density, availability of 7-men, or licensing). I think it would be fair that during testing of an engine that you deny using its own popular brand of tablebases, because you happened to have only the competing brand installed, that the opponent should also be denied usage of its tablebases. But that is up to the tournament director, of course.

I think this is as it should be. What is important for us, is that WinBoard and the protocol will be able to handle all aspects of this process without further specification changes.

[Dann Corbit]

Agreed, but this is a bit beyond the scope of the protocol design. If authors decide upon using their own tablebase format, they will be able to use it on their own computer at home, on ICS, and in tournaments where you have to bring your own hardware, like WCCC. But it should also be clear to them that they have as much chance as a snowball in hell that they will be able to use those tablebases in tournaments like ChessWar and WBEC, or in CCRL tests. Those who conduct such tournaments and matches will of necessity put a limit to the disk-space a prgram will be allowed to use for its install, and typical EGTB sizes of anything more than 4-men will grossly exceed those quota.

So unless their format has so many advantages over the market leader that many other engines will prefer it as well, it won't be available. If popular demand for the format arises, this might sway the testers of making them available. Perhaps first only in specialized tourneys for engines that require this format, on computers dedicated to the purpose. If different formats become wide-spread, testers might consider to drop all but the most convenient one (in terms of density, availability of 7-men, or licensing). I think it would be fair that during testing of an engine that you deny using its own popular brand of tablebases, because you happened to have only the competing brand installed, that the opponent should also be denied usage of its tablebases. But that is up to the tournament director, of course.

I think this is as it should be. What is important for us, is that WinBoard and the protocol will be able to handle all aspects of this process without further specification changes.

Here are the provisions in my data model:

Code: Select all

CREATE TABLE EgdbAuthor (
        EgdbTypeID           int NOT NULL,
        AuthorID             int NOT NULL
 );
 
 
 CREATE INDEX XIF31EgdbAuthor ON EgdbAuthor
 (
        EgdbTypeID
 );
 
 CREATE INDEX XIF32EgdbAuthor ON EgdbAuthor
 (
        AuthorID
 );
 
 
 ALTER TABLE EgdbAuthor
        ADD PRIMARY KEY (EgdbTypeID, AuthorID);


 
 CREATE TABLE EndGameDataBase (
        EgdbTypeID           int IDENTITY,
        EgdbPath             varchar(255) NULL,
        IsBitbase            bit,
        IsDTM                bit,
        IsDTC                bit,
        IsDTZ                bit,
        IsDTR                bit,
        EgdbDllPath          varchar(255) NULL,
        EgdbDescription      varchar(255) NULL,
        EgdbInterfaceDescription text NULL
 );

ALTER TABLE EndGameDataBase
        ADD PRIMARY KEY (EgdbTypeID);

 CREATE TABLE ProgramVersion (
        ProgramID            int NOT NULL,
        ProgramVersionID     int IDENTITY,
        ProgramVersionOrDate varchar(255) NULL,
        OpeningBookID        int NULL,
        PhysicalLocation     varchar(255) NULL,
        EgdbTypeID           int NULL,
        PhysicalName         varchar(255) NULL,
        LogicalName          varchar(255) NULL
 )


[Miguel A. Ballicora]

Also, keep in mind that there is no xboard.ini. Maybe it would be good to add such functionality...

Indeed, for convenient operation of PSWBTM there must be an xboard.ini. I will see if I can still add one before we release, even if it cannot be saved yet.

Or perhaps, as a temporary kludge, I should provide an adater for invoking xoard by PSWTM, that does nothing else but reading xboard.ini, put whatever is in there as arguments before the arguments with which it was called, and then call xboard (through an exec call, no forking).

How exactly is the

feature option style list stupid patzer mediocre weak
feature option lmr_history_percent int 0 - 100

better then

askuser style Enter style: stupid patzer mediocre weak
askuser lmr_history_percent Give lmr history percentage:

?

From the viewpoint of the engine, it seems quite immaterial if you have to send one or the other.

Zach mentioned many reasons, but I add another. Askuser requires an immediate answer from the user, a hypothetic feature option does not. Ideally, the GUI will handle the feature option building a dialog or a pull down menu where the user can go any time. For instance, if I am playing against my engine Gaviota (Human vs engine) I would love to see a pull down menu (it could be named engine1 or Gaviota, which was provided to winboard wtih feature name) in which the options could be

Code: Select all

File Preferences Etc. Gaviota
                         \
                        hash ---> 256 Mb , 128 Mb, 64 Mb
                        style ---> dumb, dumber, dumbest
                        resign ---> on, off
                        book ---> default, big, browse 
   


So I can change those options whenever I want. If the GUI shows that as a pull down menu, dialog or any other way is not relevant to the protocol.
Maybe it would be ideal if the engine could tell the default option is using in some way.

feature default=style: mediocre
feature option=style: stupid patzer mediocre weak

Miguel