The --param_index is needlessly limiting in my opinion, moreso considering it's not being used right now. If we want to keep it it would be better to expose in/out scaling as cli parameters directly. I'm fine with the rest.

Ah, wait, I didn't commit the needed cleanup changes..

The idea of the param_index is just to simplify exploration, I don't think we need to expose everything as parameters, but it is quite tedious to pass something down from the cli to the core (ideally even to the C++ data reader).

Maybe there is a more elegant approach to doing so ?

BTW, the previous state of the commit showed, how I have been using it.

That makes sense now. Indeed, I've been usually adding a special parameter for stuff like that (usually varied per run). Looks good to me now.

Do we have any picture(s) to help visualize the idea behind the double sigmoid for the loss function, and the effect of param_index?

param_index is just 'a hack' to be able to twiddle with parameters that we don't want to expose, so can be ignored. The following illustrates the idea:

gnuplot> sigmoid(x)=1/(1+exp(-x))
gnuplot> win_rate(x, b)=sigmoid((x-270) / b)
gnuplot> score(x, b)=0.5 * ( 1.0 + win_rate(x, b) - win_rate(-x, b))
gnuplot> set xlabel "eval"
gnuplot> set ylabel "score"
gnuplot> set xrange[-800:800]
gnuplot> plot score(x, 50), score(x, 300)

To make this more intuitive, we know games are quite won near 135 cp (270 in the above internal units), and quite lost near -135cp. They are also most likely draw in an interval around 0cp. This is reflected in the step like behavior for smaller b. The score formula is just a result of taking the win_rate_model, and computing the probability of loss, draw, win. The 'b' parameter describes how smoothly that transition is. For the high quality games in fishtest it is about 30-50, for the quick training data maybe more close to 300?.

see also the plots in official-stockfish/Stockfish#3981