lichess.org
Donate

Adapting nnue-pytorch's binary position format for Lichess

I think the image representing an example position and corresponding binary is wrong for the black king.

If i look at the implementation, https://github.com/lichess-org/scalachess/blob/31cdcb1b309e6c368c78ebf7f5832e2df9ff83eb/core/src/main/scala/format/BinaryFen.scala#L201 we can get all nibbles:

en-passant pawn => 12 => 1100 => 0011

black pawn => 1 => 0001 => 1000
black knight => 3 => 0011 => 1100
black bishop => 5 => 0101 => 1010
can’t castle black rook => 7 => 0111 => 1110
can castle black rook => 14 => 1110 => 0111
black queen => 9 => 1001 => 1001
black turn black king => 15 => 1111 => 1111

white pawn => 0 => 0000 => 0000
white knight => 2 => 0010 => 0100
white bishop => 4 => 0100 => 0010
can’t castle white rook => 6 => 0110 => 0110
can castle white rook => 13 => 1101 => 1011
white queen => 8 => 1000 => 0001
white king => 10 => 1010 => 0101
white turn black king => 11 => 1011 => 1101

we can see that 1011 is indeed the correct number for white turn black king, but in reverse endianness. The image should show 1101 for white turn black king to be consistent with the endianness used everywhere else in the image.

I think the image representing an example position and corresponding binary is wrong for the black king. If i look at the implementation, https://github.com/lichess-org/scalachess/blob/31cdcb1b309e6c368c78ebf7f5832e2df9ff83eb/core/src/main/scala/format/BinaryFen.scala#L201 we can get all nibbles: en-passant pawn => 12 => 1100 => 0011 black pawn => 1 => 0001 => 1000 black knight => 3 => 0011 => 1100 black bishop => 5 => 0101 => 1010 can’t castle black rook => 7 => 0111 => 1110 can castle black rook => 14 => 1110 => 0111 black queen => 9 => 1001 => 1001 black turn black king => 15 => 1111 => 1111 white pawn => 0 => 0000 => 0000 white knight => 2 => 0010 => 0100 white bishop => 4 => 0100 => 0010 can’t castle white rook => 6 => 0110 => 0110 can castle white rook => 13 => 1101 => 1011 white queen => 8 => 1000 => 0001 white king => 10 => 1010 => 0101 white turn black king => 11 => 1011 => 1101 we can see that 1011 is indeed the correct number for white turn black king, but in reverse endianness. The image should show 1101 for white turn black king to be consistent with the endianness used everywhere else in the image.

@mathyxxx said in #10:

sorry for having daft question here. What programming language is using "*" symbol for writing up comments? Thank you :)

Stata. It's a statistical programming language for causal modeling/data cleaning.

@mathyxxx said in #10: > sorry for having daft question here. What programming language is using "*" symbol for writing up comments? Thank you :) Stata. It's a statistical programming language for causal modeling/data cleaning.

@anakojm said in #12:

I think the image representing an example position and corresponding binary is wrong for the black king.

Something interesting I noticed about the picture is that (barring I read it wrong) the occupancy bitboard starts from a8 and go from rank 8 to 1 like FEN, but the piece nibbles go from rank 1 to 8. Either is fine, but having both is weird.

@anakojm said in #12: > I think the image representing an example position and corresponding binary is wrong for the black king. Something interesting I noticed about the picture is that (barring I read it wrong) the occupancy bitboard starts from a8 and go from rank 8 to 1 like FEN, but the piece nibbles go from rank 1 to 8. Either is fine, but having both is weird.

Great article and fascinating to read! Compression is always fun. It's like tetris for programmers.

Maybe Microsoft should read this blog post and start apply the principles therein to Windows :D

Great article and fascinating to read! Compression is always fun. It's like tetris for programmers. Maybe Microsoft should read this blog post and start apply the principles therein to Windows :D

I might be missing something, but I think you can save another nearly 9% easily just by mapping ordered triplets of pieces to an 11-bit number (saving 1 bit): https://gist.github.com/jacksonthall22/835199a4fa80a111f628efd55329e598

I might be missing something, but I think you can save another nearly 9% easily just by mapping ordered triplets of pieces to an 11-bit number (saving 1 bit): https://gist.github.com/jacksonthall22/835199a4fa80a111f628efd55329e598

Just a question here, perhaps a chance to enhance encoding a tiny bit once again.
During Alan Turing's discovery of solving the Enigma machine, he noticed that every message always ended in "Heil Hitler" (Not fully historically correct, but the story makes sense for this solution).

Every chess board "must" (except for anti-chess) contain a white and a black king (the HH).
What if your "Occupancy" format always starts with the white king + black king? Wouldn't this save two nibbles in the "Pieces" section?

Just a question here, perhaps a chance to enhance encoding a tiny bit once again. During Alan Turing's discovery of solving the Enigma machine, he noticed that every message always ended in "Heil Hitler" (Not fully historically correct, but the story makes sense for this solution). Every chess board "must" (except for anti-chess) contain a white and a black king (the HH). What if your "Occupancy" format always starts with the white king + black king? Wouldn't this save two nibbles in the "Pieces" section?

@Calanthe said in #19:

Just a question here, perhaps a chance to enhance encoding a tiny bit once again.
During Alan Turing's discovery of solving the Enigma machine, he noticed that every message always ended in "Heil Hitler" (Not fully historically correct, but the story makes sense for this solution).

Every chess board "must" (except for anti-chess) contain a white and a black king (the HH).
What if your "Occupancy" format always starts with the white king + black king? Wouldn't this save two nibbles in the "Pieces" section?

The occupancy bitboard is only 1 bit per square, so it's read in row-major order. How would you know where the kings are just from the piece section?

@Calanthe said in #19: > Just a question here, perhaps a chance to enhance encoding a tiny bit once again. > During Alan Turing's discovery of solving the Enigma machine, he noticed that every message always ended in "Heil Hitler" (Not fully historically correct, but the story makes sense for this solution). > > Every chess board "must" (except for anti-chess) contain a white and a black king (the HH). > What if your "Occupancy" format always starts with the white king + black king? Wouldn't this save two nibbles in the "Pieces" section? The occupancy bitboard is only 1 bit per square, so it's read in row-major order. How would you know where the kings are just from the piece section?