Question: Polyglot books and Chess960

[hgm]

I understand that Polyglot suppots Chess960. But how does it handle the opening book? The hash key for accessing normal Polyglot books has ony 4 castling-right Zobrist keys (KQkq). This is not sufficient for fully specifying the castling rights in Chess960, as it does not indicate to which Rook the castling rights refer. Or is Qq always used for the left-most Rook, and Kk for the right-most? What if the side to castle has 3 Rooks on the back rank??? (OK, unlikely in the opening, I admit...)

What would be needed is 8 castling keys per side, representing the AHah castling specifiers of Shredder and XFEN. Does Polyglot define a value for the Zobrist randoms for these keys?

[Spock]

I think that ChessGUI from Matthias Gemuh supports both of the chess960 standards and enables both winboard and Shredder UCI chess960 engines to play each other using a Shredder-FEN opening pgn, but I have never tried it. I may do so at some point

http://biglion.110mb.com/

[pedrox]

I understand that Polyglot suppots Chess960. But how does it handle the opening book? The hash key for accessing normal Polyglot books has ony 4 castling-right Zobrist keys (KQkq). This is not sufficient for fully specifying the castling rights in Chess960, as it does not indicate to which Rook the castling rights refer. Or is Qq always used for the left-most Rook, and Kk for the right-most? What if the side to castle has 3 Rooks on the back rank??? (OK, unlikely in the opening, I admit...)

What would be needed is 8 castling keys per side, representing the AHah castling specifiers of Shredder and XFEN. Does Polyglot define a value for the Zobrist randoms for these keys?

I think that polyglot supports Chess960 but it does not support opening books for Chess960.

On one occasion I've tried to create a normal openning book with polyglot, I had several files PGN, polyglot chesks PGN and showed me several errors, I realized that these errors were by games of Chess960, the passer of polyglot does not understand PGN of Chess960.

Pedro

[Michel]

If I understand correctly the PG hash key does not keep track of which rook is allowed to castle if there is more than one on the same side of the king.

HOWEVER: a castling move is represented as FROMTO with FROM being equal to the kings square and TO being equal to the rook square. Hence by checking if the castling is legal or not PG can distinguish between the different rooks (PG is aware of the precise castling rights of course because it knows the history of the game).

Now I understand why the test move_is_legal() is present in book_move().

I agree this is somewhat hacky.

Michel

EDIT: Actually now I don't see why PG records the rooks position in a move. It seems
to me that if castling is legal in a certain direction, it is unambiguous which rook
should do the castling. But of course the move_is_legal() test is still necessary since
the hash key is not aware of the full castling rights.

[hgm]

I am not sure I understand what you are saying. Two positions have the same hash key, and if they both occur in the book their moves will be merged (as the book is sorted by hash key). So if in one of the two castling is possible and in the book, the retrieval will always think castling is possible in both. (The problem is further aggrevated in that both castlings cn currently be impossible, but the recommended move might depend on which of the Rooks can castle.)

Is it that Polyglot has an objective criterion to keep one of the two collidog positions out of the book? (e.g. the one where the inner Rook has the rights, that would need the A-H castling specifyer in XFEN?)

[Michel]

Two positions have the same hash key

It that case castling is possible in both or in neither (the GUI knows which).
The rooks that can castle maybe different, so a test for move_is_legal is necessary.

The problem is further aggrevated in that both castlings cn currently be impossible, but the recommended move might depend on which of the Rooks can castle.

That's true. This case is not handled properly.

Anyway you have your answer how PG handles Chess960. I think Chess960 was added as an afterthought to PG.

It would be easy use a hash key based on Shredder or X-Fen. This should be done of course in a backwards compatible way.

[hgm]

Indeed. XFEN offers backward compatibility with normal FEN, Shredder-FEN does not. So I propose to use the same strategy to acheive this backward compatibility as XFEN does:

When th castling rights pertain to th oter-most rook on the given side, the same hash key is used for this castling right as is used in normal Chess (just like XFEN uses the same letters, KQkq, in this case). If it is another Rook that has castling rights, it will have to use another hash key, based on the file that Rook is in.

So we will need 16 new hash keys. As long as they are not agreed upon, a perfectly workable temporary solution is to require that positions where a castling right does not belong to the outer-most Rook is forbidden to occur in the book.

I will try to adapt the book code of WinBoard accoringly, or perhaps switch off use of the book in FRC altogether. Using a book in Ches 960 is a bit contrary to the purpose of it anyway...

[Michel]

So we will need 16 new hash keys. As long as they are not agreed upon, a perfectly workable temporary solution is to require that positions where a castling right does not belong to the outer-most Rook is forbidden to occur in the book.

Is it 16 or 32? I would think 32. Eight for each of the possible castlings.

I don't think there are any 960 PG books around. So you can fix those random numbers. I will include them in the specification here

http://alpha.uhasselt.be/Research/Algeb ... ormat.html

To make the PG book making utilities compatible with them I guess it is just a question of adapting the current PG hash function.

Michel

[hgm]

I think it is just 16: representatons for A-H and a-h, and use them when A-H and a-h would be used in XFEN.

Come to think of it, A and H are never used in XFEN: if there is a Rook on the A or H file, it will always be the outer-most Rook, and use K or Q. So in fact the key for A and Q could be equal, as could the keys for H and K. In fact it would not matter if you would view this as a Zobrist version of XFEN or Shredder FEN.

So you only need 12 extra keys, to make 16 castling keys in total. In the FEN to key sample code you gave you woud simply have to add translations of A-H and a-h, and it would wrk for both Shredder and XFEN.

[Michel]

I would not try to look for clever schemes to minimize the number of extra random numbers required. This is not worth the effort. The most important thing is that the hash key should be as simple as possible to compute.

The main feature of PG books is and should be that they are trivial to implement.

I wouldn't mind 32 extra keys (treating all castlings independently) but 16 is ok for me.

Michel