BONA_PIECE_ZERO

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

elcabesa
Posts: 855
Joined: Sun May 23, 2010 1:32 pm

BONA_PIECE_ZERO

Post by elcabesa »

I read and read, tried to find info, looked at some implementation, but failed to find useful information

can someone explain it simply or point me to a simple article?
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: BONA_PIECE_ZERO

Post by syzygy »

elcabesa wrote: Sun Oct 04, 2020 3:45 pm I read and read, tried to find info, looked at some implementation, but failed to find useful information

can someone explain it simply or point me to a simple article?
In the NNUE playing code, it does exactly nothing. Those weights are simply not used. Just like the weights corresponding to a piece on the same square as the friendly king.
elcabesa
Posts: 855
Joined: Sun May 23, 2010 1:32 pm

Re: BONA_PIECE_ZERO

Post by elcabesa »

ok understood.

just another question, even if it is not related to this topic.

does the "standard" stockfish NNUE feature encoding also encode the capture square, if a capture is performed?
elcabesa
Posts: 855
Joined: Sun May 23, 2010 1:32 pm

Re: BONA_PIECE_ZERO

Post by elcabesa »

syzygy wrote: Sun Oct 04, 2020 4:01 pm In the NNUE playing code, it does exactly nothing. Those weights are simply not used. Just like the weights corresponding to a piece on the same square as the friendly king.
so those unused features can be used to encode some other information e.g. castling rights. Obviously those added feature need to be fast calculated for complete and incremental eval
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: BONA_PIECE_ZERO

Post by syzygy »

elcabesa wrote: Sun Oct 04, 2020 4:17 pm ok understood.

just another question, even if it is not related to this topic.

does the "standard" stockfish NNUE feature encoding also encode the capture square, if a capture is performed?
No.
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: BONA_PIECE_ZERO

Post by syzygy »

elcabesa wrote: Sun Oct 04, 2020 4:24 pm
syzygy wrote: Sun Oct 04, 2020 4:01 pm In the NNUE playing code, it does exactly nothing. Those weights are simply not used. Just like the weights corresponding to a piece on the same square as the friendly king.
so those unused features can be used to encode some other information e.g. castling rights. Obviously those added feature need to be fast calculated for complete and incremental eval
Yes. Or just rearrange the features to what you need.

Since a king move anyway results in a "refresh" of that king's half of the accumulator, it seems to me that positions with castling rights can be encoded as positions with the king on one of three imaginary squares (corresponding to 0-0 + 0-0-0, only 0-0, only 0-0-0). Losing a castling right then moves the king. A bit of work to encode that correctly in the DirtyPiece struct but in principle quite trivial.

You would have 67*640 instead of 64*640 features. So not a big increase. This would not fully take care of Chess960, but I guess it is just fine to ignore castling in Chess960 (just like SF's current NNUE eval completely ignores castling rights as well and is doing pretty well anyway).

Another possibility is encoding castling rights as three separate features, or perhaps 15 (to take care of all possibilities for white and black minus the default no castling rights). I don't know how well that would work with the relatively simple NNUE network architecture.
elcabesa
Posts: 855
Joined: Sun May 23, 2010 1:32 pm

Re: BONA_PIECE_ZERO

Post by elcabesa »

syzygy wrote: Sun Oct 04, 2020 5:28 pm
elcabesa wrote: Sun Oct 04, 2020 4:17 pm ok understood.

just another question, even if it is not related to this topic.

does the "standard" stockfish NNUE feature encoding also encode the capture square, if a capture is performed?
No.
so what does this mean?
41,024 = 64 * 641. 64 comes from the number of the cells where king may exist. 641 = 64 * 5 * 2 + 1. 64 here comes from the number of the cells where a piece other than king may exist. 5 is the number of piece types other than king. 2 is the number of the colors, white and black. 1 is a captured piece.
"+ 1" is BONA_PIECE_ZERO.
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: BONA_PIECE_ZERO

Post by syzygy »

elcabesa wrote: Sun Oct 04, 2020 5:43 pm so what does this mean?
41,024 = 64 * 641. 64 comes from the number of the cells where king may exist. 641 = 64 * 5 * 2 + 1. 64 here comes from the number of the cells where a piece other than king may exist. 5 is the number of piece types other than king. 2 is the number of the colors, white and black. 1 is a captured piece.
"+ 1" is BONA_PIECE_ZERO.
I have read that too, but the last part is just nonsense or related to some old version.

I guess they just wanted to have 0 be an invalid index ("PS_NONE"), but I don't think that was ever necessary (at least not since NNUE was integrated into SF master).

Anyway, you can just look at refresh. All it does is loop through the non-king pieces on the board and add a weight vector to the accumulator for that (piece,square) x white-king-square and the same for black-king-square after rotating the board (which should be mirroring if you add castling rights). This is all the interaction there is between the chess position and the NNUE eval.
Last edited by syzygy on Sun Oct 04, 2020 6:01 pm, edited 1 time in total.
elcabesa
Posts: 855
Joined: Sun May 23, 2010 1:32 pm

Re: BONA_PIECE_ZERO

Post by elcabesa »

thank you,
you are always very clear and polite
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: BONA_PIECE_ZERO

Post by syzygy »

elcabesa wrote: Sun Oct 04, 2020 6:01 pm thank you,
you are always very clear and polite
You're welcome.

It might be interesting to try to look at the NNUE implementation for Shogi. Perhaps the "BONA_PIECE_ZERO" concept was implemented there...