Page 3 of 4

Re: syzygy request for info

Posted: Sun Jun 10, 2018 8:32 am
by Sesse
syzygy wrote:
Sat Jun 09, 2018 3:24 pm
But to make use of that one would need to come up with a completely new compression scheme.
Yes, certainly. If you have already gone multisymbol to reduce the impact of the Huffman rounding (as I understand it), the final entropy coder isn't where you can hope to gain anything, naturally.

I don't honestly have an intuitive feel for what this data looks like, so it's hard to come up with something. :-) These things typically take a fair bit of imagination and experimenting.

Re: syzygy request for info

Posted: Tue Jun 12, 2018 1:33 pm
by elcabesa
Ronald, syzygy generaror is implemented as forward or backward?

Thank you

Re: syzygy request for info

Posted: Tue Jun 12, 2018 6:23 pm
by syzygy
elcabesa wrote:
Tue Jun 12, 2018 1:33 pm
Ronald, syzygy generaror is implemented as forward or backward?

Thank you
Backward.

Re: syzygy request for info

Posted: Sat Dec 01, 2018 7:01 pm
by elcabesa
I have another question for Ronald.

in syzygy files pieces are encoded using the Stockfish encoding?

Code: Select all

enum Piece {
  NO_PIECE,
  W_PAWN = 1, W_KNIGHT, W_BISHOP, W_ROOK, W_QUEEN, W_KING,
  B_PAWN = 9, B_KNIGHT, B_BISHOP, B_ROOK, B_QUEEN, B_KING,
  PIECE_NB = 16
};
I'm trying to integrate the Stockfish code in Vajolet because I like it more than fathom one but it seems a non trivial task since Vajolet has another encoding for pieces with piece order inverted.

Re: syzygy request for info

Posted: Sun Dec 02, 2018 10:42 am
by syzygy
elcabesa wrote:
Sat Dec 01, 2018 7:01 pm
I have another question for Ronald.

in syzygy files pieces are encoded using the Stockfish encoding?

Code: Select all

enum Piece {
  NO_PIECE,
  W_PAWN = 1, W_KNIGHT, W_BISHOP, W_ROOK, W_QUEEN, W_KING,
  B_PAWN = 9, B_KNIGHT, B_BISHOP, B_ROOK, B_QUEEN, B_KING,
  PIECE_NB = 16
};
I'm trying to integrate the Stockfish code in Vajolet because I like it more than fathom one but it seems a non trivial task since Vajolet has another encoding for pieces with piece order inverted.
Yes, the piece encodings coincide with those of Stockfish. This shouldn't be too much of a problem if you invert the values at the right place in the code.

Things will be a bit more complicated if you have separate encodings for dark/light bishops.

Re: syzygy request for info

Posted: Sun Dec 02, 2018 2:07 pm
by elcabesa
I have to find the right points. ☺

Re: syzygy request for info

Posted: Sun Dec 02, 2018 6:04 pm
by syzygy
elcabesa wrote:
Sun Dec 02, 2018 2:07 pm
I have to find the right points. ☺
Try this line:
https://github.com/official-stockfish/S ... .cpp#L1067

Re: syzygy request for info

Posted: Sun Dec 02, 2018 6:14 pm
by elcabesa
syzygy wrote:
Sun Dec 02, 2018 6:04 pm
elcabesa wrote:
Sun Dec 02, 2018 2:07 pm
I have to find the right points. ☺
Try this line:
https://github.com/official-stockfish/S ... .cpp#L1067
This line maps pieces in files to piece in ram? every other piece of code will access the ram rapresentation? I'll give it a try

Re: syzygy request for info

Posted: Sun Dec 02, 2018 6:18 pm
by syzygy
elcabesa wrote:
Sun Dec 02, 2018 6:14 pm
syzygy wrote:
Sun Dec 02, 2018 6:04 pm
elcabesa wrote:
Sun Dec 02, 2018 2:07 pm
I have to find the right points. ☺
Try this line:
https://github.com/official-stockfish/S ... .cpp#L1067
This line maps pieces in files to piece in ram? every other piece of code will access the ram rapresentation? I'll give it a try
The only bytes in a TB file that use the "Stockfish encoding" are the bytes that are read in that line. So if you convert it there, then that should be it. Unless some other part of the TB probing code silently depends on the SF encoding. (Line 70 is an obvious example: the PieceToChar string.)

Re: syzygy request for info

Posted: Sun Dec 02, 2018 6:36 pm
by elcabesa
syzygy wrote:
Sun Dec 02, 2018 6:18 pm
The only bytes in a TB file that use the "Stockfish encoding" are the bytes that are read in that line. So if you convert it there, then that should be it. Unless some other part of the TB probing code silently depends on the SF encoding. (Line 70 is an obvious example: the PieceToChar string.)
this is my code to convert from:

Code: Select all

enum Piece {
  NO_PIECE,
  W_PAWN = 1, W_KNIGHT, W_BISHOP, W_ROOK, W_QUEEN, W_KING,
  B_PAWN = 9, B_KNIGHT, B_BISHOP, B_ROOK, B_QUEEN, B_KING,
  PIECE_NB = 16
};
to:

Code: Select all

occupiedSquares=0,				//0	00000000
	whiteKing=1,					//1	00000001
	whiteQueens=2,					//2	00000010
	whiteRooks=3,					//3	00000011
	whiteBishops=4,					//4	00000100
	whiteKnights=5,					//5	00000101
	whitePawns=6,					//6	00000110
	whitePieces=7,					//7	00000111

	separationBitmap=8,
	blackKing=9,					//9	00001001
	blackQueens=10,				//10	00001010
	blackRooks=11,					//11	00001011
	blackBishops=12,				//12	00001100
	blackKnights=13,				//13	00001101
	blackPawns=14,					//14	00001110
	blackPieces=15,					//15	00001111

Code: Select all

for (int k = 0; k < e.pieceCount; ++k, ++data)
 for (int i = 0; i < sides; i++)
 {
  uint8_t convertedData = i ? *data >>  4 : *data & 0xF;
  bool color = isBlackPiece((bitboardIndex)convertedData);
  uint8_t piece = getPieceType((bitboardIndex)convertedData);
  piece = 7 - piece;
  convertedData = color | piece;
  e.get(i, f)->pieces[k] = (bitboardIndex)convertedData;
 }
from what I have understood e.get(i, f)->pieces[k] will store the 4 bit ( with color information ) info about the piece. so I have to mantain the color, but invert the order of pieces.

I'll try it asap