TalkChess.com

syzygy wrote: ↑Sun Oct 04, 2020 6:04 pm

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...

Seems to have something to with piece drops, some translations from Japanese comments:
https://github.com/yaneurao/YaneuraOu/b ... ate.h#L115

A type that expresses P (Piece) when it is called KKP / KPP in Bonanza.
When calculating the Σ KPP, a unique number is required for the square x piece type, such as the step at 39 points.
Invalid piece. If you drop a piece, move an unnecessary piece here.
When you look at BonaPiece from the back (the number of 39 steps on the play is 71 steps on the back)
The pair is called the ExtBonaPiece type.

Seems difficult to explain

I have 2 additional questions about NNUE encoding

1) why square for black is calculated as sq^63 and not as sq^56? it's not a vertical mirro, but is cn be encoed as 63-sq, am i wrong?
2) why piece indices start from 1 and not to 0? this lead to 641 pieces and not 640, but it seems to me that the +1 is a waste. Am I missing something?

Ah, it seems I had misunderstood the bona-piece-zero. I had thought it was a clever way to encode that the previous move had been a capture, thus allowing the NN to see that the position might require a recapture if it currently had a material imbalance. Since that is not the case, I wonder how the NN does manage to learn from these recapture positions: the eval might show equality, but the board position would be uneven. How is this handled?

elcabesa wrote: ↑Sat Oct 17, 2020 3:56 pm I have 2 additional questions about NNUE encoding

1) why square for black is calculated as sq^63 and not as sq^56? it's not a vertical mirro, but is cn be encoed as 63-sq, am i wrong?

Because this is how the current nets were trained.

You are right that is unlikely to be optimal. I think some are now trying to train nets for "sq^56", but I have not seen any results yet.

2) why piece indices start from 1 and not to 0? this lead to 641 pieces and not 640, but it seems to me that the +1 is a waste. Am I missing something?

This is the BONA_PIECE_ZERO mystery. The +1 is a small waste of memory. It doesn't really hurt.

Gerd Isenberg wrote: ↑Sun Oct 04, 2020 9:13 pm Seems to have something to with piece drops, some translations from Japanese comments:
https://github.com/yaneurao/YaneuraOu/b ... ate.h#L115

A type that expresses P (Piece) when it is called KKP / KPP in Bonanza.
When calculating the Σ KPP, a unique number is required for the square x piece type, such as the step at 39 points.
Invalid piece. If you drop a piece, move an unnecessary piece here.
When you look at BonaPiece from the back (the number of 39 steps on the play is 71 steps on the back)
The pair is called the ExtBonaPiece type.

Seems difficult to explain

WIth my perhaps simplistic understanding of "Shogi = like Crazyhouse", I would think one would need a vector for each piece type x king position to deal with piece drops (as if all droppable pieces are sitting on an off-board square, and moving a piece moves it from the off-board square to a square on the board). But that would explain +10, not +1.

My only explanation of +1 and the extra index being equal to 0 is that it was somehow convenient to have 0 be an unused/illegal index.

There really is nothing special about SF's NNUE. If you skip the half portion, it just a trivial NN, where the input layer is built with a sparse vector or matrix.

I'de highly suggest anyone who is interested by it to roll their own implementation. Stockfish's trainer is ungodly to look at, and likely highly sub-optimal. Whether you use a lib like TensorFlow, or Pytorch (a fork with Sparse Matrix Multiples), or roll your own from scratch, you'll learn far more and develop a far more useful skillset.

I'm not sure why groups like TCEC are okay with calling Stockfish's implementation a "library" for "everyone to use". Do your own work, and it will pay dividends down the line. You also skip all the trash thats in Stockfish because its a weak Shogi port that was never cleaned up.

However, if you must look at an engine, look at CFish.

AndrewGrant wrote: ↑Sun Oct 18, 2020 3:38 am I'm not sure why groups like TCEC are okay with calling Stockfish's implementation a "library" for "everyone to use". Do your own work, and it will pay dividends down the line. You also skip all the trash thats in Stockfish because its a weak Shogi port that was never cleaned up.

I guess that they called it a library for anyone to use because that is basically what SF did.
They took some Shogi code and grafted it onto SF.
The BONA_PIECE_ZERO is evidence of the hurried job, since it has nothing to do with the game of chess (drops only happen in shogi).

Cut and paste of someone else's code is supposed to be naughty and unoriginal. But I imagine that they did it with permission.
Probably it was GPL3 code like SF so there is no licence violation.

Dann Corbit wrote: ↑Sun Oct 18, 2020 4:38 am

AndrewGrant wrote: ↑Sun Oct 18, 2020 3:38 am I'm not sure why groups like TCEC are okay with calling Stockfish's implementation a "library" for "everyone to use". Do your own work, and it will pay dividends down the line. You also skip all the trash thats in Stockfish because its a weak Shogi port that was never cleaned up.

I guess that they called it a library for anyone to use because that is basically what SF did.
They took some Shogi code and grafted it onto SF.
The BONA_PIECE_ZERO is evidence of the hurried job, since it has nothing to do with the game of chess (drops only happen in shogi).

Cut and paste of someone else's code is supposed to be naughty and unoriginal. But I imagine that they did it with permission.
Probably it was GPL3 code like SF so there is no licence violation.

So you don't know what happened. That's fine but why the need to comment?

syzygy wrote: ↑Sun Oct 18, 2020 1:08 am This is the BONA_PIECE_ZERO mystery. The +1 is a small waste of memory. It doesn't really hurt.

Also, having a prime index makes it much harder to get into cache associativity issues!

(I doubt this was ever an intended reason, and it probably doesn't matter in this case, but it can sometimes be a good reason not to keep things at power-of-two, or related values such as 640.)