NNUE for pruning and search extensions

Little Goliath Evolution already uses such NNUE. An excerpt from the readme:

"Major improvement is the introduction of neural networks for extension and pruning decisions.

I have also experimented with networks for move ordering. Unfortunately without significant success (too much overhead)."

Dio wrote:

Little Goliath Evolution already uses such NNUE. An excerpt from the readme:

"Major improvement is the introduction of neural networks for extension and pruning decisions.

I have also experimented with networks for move ordering. Unfortunately without significant success (too much overhead)."

Both Rebel and Chess System Tal are using dedicated neural nets in search. Chess System Tal also uses a dedicated net in time control. They don’t give much Elo overall, but they’re quite time expensive so they do at least pay for themselves plus a bit.

Thanks, I was not aware of this, it was a reference to Ed's post at talkchess. "The next big thing is a neural net driven search."

Little Goliath Evolution 3.16 uses a total of four very small NN (3 of them internal, one general external), the internal ones are additionally responsible for search extensions or pruning). I find this an interesting (and in the tests) successful idea.

Dio wrote:

Thanks, I was not aware of this, it was a reference to Ed's post at talkchess. "The next big thing is a neural net driven search."

Little Goliath Evolution 3.16 uses a total of four very small NN (3 of them internal, one general external), the internal ones are additionally responsible for search extensions or pruning). I find this an interesting (and in the tests) successful idea.

I think Ed is being a trifle over-optimistic here!

Hand crafted search is mostly a set of botches piled on top of other botches with a wing and a prayer and a bit of tuning. An integrated system would be nice, something more similar to LCZ, but that takes a big net.

Problem with move ordering is that how does a net represent a move? AZ uses a 64x64 from-to matrix and lights up a 'score' for all the legal moves. Actually it lights up a score for all possible moves, a1 to f4 included, but only needs to look at the, say 40, legal ones to get the highest score (well, that's what they did when I last looked, several years ago). A CPU program will, worst case, need to resolve all 40 nodes sequentially and that's going to be a non-trivial amount of matrix operation. Whereas a GPU resolves them all more or less simultaneously.

I think we just haven't discovered to do things right.