Polyglot keys for chess variants.

[Michel]

This is apparently the mailing list to submit magic header definitions

http://mx.gw.com/pipermail/file/2012/thread.html

First of course we need a few books with such headers....

[Michel]

Engines do not have to support this right? Polyglot plays the book moves on their behalf so no need to know about it.

Yes that is the point.

[ZirconiumX]

What I am sorely missing in Polyglot format is a file header, which could be used to recognize it as a Polyglot book, and contain a versi could, for instanceon number to indicate extension of the format.

Can we kludge in such a header in a backward compatible way? We could, for instance, start with an entry that has hash key 0, and some magic 16-bit code in the move field, identifying it as a Polyglot book. That would leave the weight and learn fields to contain a version number or other info.

PG is 0101000001000111.
CH is 0100001101001000.
Both 16 bit.

I propose 0xC4E5 which sort of looks like chess (image the 4 upside down on a seven segment display). I hope it is unambiguous enough to be accepted.

Matthew:out

[Daniel Shawul]

I don't understand the need to have a hashkey for variants type at all. Just reserving some header bytes (512 bytes f.i), should be enough to include whatever information may be required in the future including variants type.
So I would just save 's','u','i','c','i','d','e' there. Why xor the key with magic hashkey at all ?
My bitbase files have a header offset so now I can go back and write whatever I want there and still be fine. Don't tell me polyglot books don't have that ?

[hgm]

Because ten you cannot make a book that contains multiple variants. For a multi-variant engine like Fairy-Max or Nebiyu, suc a combined book would be very handy when you play it on-line, because you don't know in advance which variant the opponent will pick.

[Daniel Shawul]

Because ten you cannot make a book that contains multiple variants. For a multi-variant engine like Fairy-Max or Nebiyu, suc a combined book would be very handy when you play it on-line, because you don't know in advance which variant the opponent will pick.

I think it is a bad design. If the problem is to load them all the same time, we can either open all the separate books or have them in one file where a variant 'suicide' followed by its start & end location. Also if the books don't have a single position for a specific variant, we still have to make binary lookups every time which could have been completely avoided if we had a separate book for a variant.

Say you want to remove part of the book for suicide variant, but you can't because the key doesn't tell you for which variant it belongs. Again you can do this with separate books. Also if we use an archiever, the user can add/remove book using external tools.

Probably not a serious problem for books, but the likelihood of hash collisions will also increase.

Merging of books is equally easy if we use one or multiple books so I don't see any advantage but problems.

[Michel]

@Daniel: The Polyglot format is meant to be a simple format that is trivial to parse. Polyglot books are not really meant to be processed much further (although Polyglot implements a form of merging, and you can edit move scores in scid).

[hgm]

and you can edit move scores in scid).

Or of course in XBoard / WinBoard, which would in fact be pretty much your only option for variants.

And you cannot only edit move scores there, but also add moves to the book or delete them. So that it is even possible to create your own book from scratch. The WinBoard install includes an empty book for this purpose, which you could copy, rename and load as GUI book in WinBoard, and then start adding moves (using Edit Book) from the start position of the selected variant.

This way you can quickly improvise a book of a few ply deep to give some diversity.

Perhaps I should make a button 'Add all moves' in the Edit Book dialog, to make this even easier. It could then append all moves with weight 1 to the dialog, so that you could delete those you don't want, and alter the weight of the others.

[Michel]

Or of course in XBoard / WinBoard, which would in fact be pretty much your only option for variants.

Ok I was not aware of that.

I must confess I never use a gui book in xboard since I cannot remember the command line options needed for it.

I would expect _as a first approximation_ something like -book "..." to work. This would be similar to -lgf and -lpf (which serve a somewhat similar purpose).

[hgm]

An important feature of the design of XBoard is that there is little need to remember such things. To specify a GUI book you can simply open XBoard, and use the Common Engine Options dialog to browse to the book file. And tick Use Book. As these are persistent options, you can then exit XBoard, and every time you start it afterwards, it will have that book loaded without the need to specify any command-line options.

Wheteher an engine will actually use it or not, is a volatile option, though. (Like all options that pertain to only one engine.) Engines won't use book by default. To make them use it, you need -firstXBook and/or -secondXBook on the XBoard command line. (These are sort forms of the options -first/secondHasOwnBookUCI true|false.)