It's Fabien.

[Xann]

Looking forward to the new Rust Engine, Fabian.

Sooner than you think; it's available:
viewtopic.php?t=85782

Sorry, we have two threads now; it can be confusing.

Fabien.

[jorose]

Will it use NN evaluation or hand-tuned eval?

It's not easy for me to give a clear answer to that apparently basic question.

Conceptually, for evaluation, I separate 'features' and 'scoring'. A feature would be a property of the position, such as a white knight on e5, while scoring would be transforming that feature (or a combination) into cp units. Now I can answer better.

The design for this engine follows one I wrote two years ago. Features are fully HCE; old-school engine like the previous Senpai. However the scoring will be more fluid: tables of weights computed by machine learning. I call this 'table-based evaluation', and that's what I use in other games like Othello and draughts. 'Look-up evaluation' would also be a good name. It replaces the numerous multiplications of an NN by array lookups. An eval like Pesto is already in that category.

No NN in my original plan (or the engine from two years ago). That could give this one a unique style, somewhere between HCE and full-NN. From the few experiments I ran on the other engine, that gives Senpai more king-safety awareness. That isn't saying much, however; my engines have always been endgame players, not king attackers.

If the results are too disappointing, I might add a small NN as an afterthought, for an Elo boost. Then it would really be a mix between HCE and full NN, with accordingly a mixed performance. Regardless of what I end up doing, it won't be competitive with optimised NNUE; that much is obvious.

Summary: HCE features, table-based scoring (rare), no NN or a small one later.

Fabien.

I’m not 100% certain I visualize the architecture you are describing yet, but I definitely agree that 'HCE vs NN' is a spectrum rather than a binary choice. I will stick to the features and scoring definitions you mention.

Some prior versions of Winter used a small simple feed forward neural network for scoring custom features into expected outcomes. At TCEC, at some point they said this was a "hybrid" approach. Older Winter versions than that used other ML algorithms for scoring, such as GMMs and K-Means.

I think the issue primarily comes from the complexity of the defined features. In the past, I think most of the heavy lifting was determining effective features and the scoring was essentially trivial. Now the features are mostly trivial, but the scoring does the heavy lifting.

There is nothing constraining us to these options. PeSTO is essentially going for the trivial route in both regards. The aforementioned Winter versions do the "heavy" approach in both regards. How "heavy" features and scoring are also is a spectrum, eg Leela's transformer model is extremely heavy when compared to the large NNUE models found in Stockfish, which in turn is much heavier than most other NNUE engine models.

To make matters worse, I would argue the features / scoring definition you came up with is insufficient. Consider that you could learn features dynamically during search (ie history heuristics for use within the static eval). These are arguably neither something that dynamically combines features for scoring directly, nor static features of the position (you cannot determine them simply by looking at the position).