Polyglot keys for chess variants.

[Michel]

That of course does not have to stop us from already formally defining variant keys for Suicide and Atomic, and other variants that use the same board size and piece set as orthodox Chess.

Yes I agree. In fact I can use your keys. Any list is as good as any other.

I was a bit worried that your variant keys are not random numbers. But I guess it is ok as long as no other non-random ingredients sneak into the computation of the zobrist hash keys.

[hgm]

But I guess it is ok as long as no other non-random ingredients sneak into the computation of the zobrist hash keys.

This was my guess too. I could see no reason why having exactly one key from the set 0-100 would make it easier to find a set of N keys that XOR to 0 if all other keys are random. Within the same variant it does not matter what the variant key is. Between variants it can only be achieved by having N-2 piece-square keys XOR to the XOR of the two variant keys. And that seems just as difficult as having them XOR to any other given non-null key.

I am a bit worried about the crazyhouse holdings, however. The current code treats that very inconsistently, because it does not take account of the fact that the black holdings are displayed with opposite orientation, and does not span the full board height.

In fact there is no need at all to distinguish the holdings squares, as it already distinguises the piece types. So all of the holdings, both white and black, could really be treated as a single off-board square. So I think I will switch to the system where in Crazyhouse all holdings squares map onto square number 64 (and in Shogi to 81).

[Michel]

Anyway if I find a bit of time (I don't have much) I will convert the nilatac suicide opening book to pg format. It is very good and contains all the solved openings (which are very numerous in fact).

However this brings up another problem. The lack of a meta data standard for pg books. Nilatac is GPL and it would be nice to encode the name of the author as well as the licence in the book. I will probably do this by putting a null terminated string in records with keys 0x000...

[hgm]

I wonder if you could write this out formally and post it somewhere?

How about this? (In particular the last chapter.)

[Michel]

How about this? (In particular the last chapter.)

Yes that looks good!

I'll link to it.

[Daniel Shawul]

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

[hgm]

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.

[Michel]

That what I was proposing. Using the keys 0x00000000.... to put in a null terminated string (probably) containing meta data. I would want to leave that free format right know. Once the principle is established one can fix the format of the meta data.

I guess Polyglot and other book making programs then should be thought to leave the metadata keys alone, although the probability that they would be used is very small.

Putting in a magic header is of course also a good idea. Once the magic header is recognized by libmagic, gui's have an official way to recognize polyglot books. This would also be nice to assign icons and such.

Incidentally: in Gnu Chess i use a kludge to recognize a polyglot book. I look at the first 10 key positions and check that the potential keys are in ascending order. This works quite well in the absence of a better system.

[hgm]

That what I was proposing. Using the keys 0x00000000.... to put in a null terminated string (probably) containing meta data.

Oh, that somehow escaped me. To get this clear, what you propose would allow an arbitrary number of null-key entries, and then use their non-key fields for the meta data? Where the meta data is in principle arbitrary text? That seems also a good idea. (There could, for instance, be an author name and copyright message there.) I would like tio reserve the fields in the first block for magic and version number, though, and perhaps some version-number-dependent stuff. We could make sure the magic and version number are printable ascii characters.

I will incorporate this in the format description.

[Michel]

To get this clear, what you propose would allow an arbitrary number of null-key entries, and then use their non-key fields for the meta data?

Yes that is the idea. And I was indeed thinking of printable ascii data since that would be readable if you open the file in a text editor (initially that would be useful as few gui's would know about the meta data).

I will incorporate this in the format description.

Ok thanks.