Hi Tamas,tomitank wrote: ↑Sun Jan 03, 2021 5:45 pmI did the same, but this is a gradient descent. Uses the derivative of error for the (weights update) direction. It just assigns a coefficient. eg: when the coefficient is zero the don't change the weight. I don't think that would have a different name. Backpropagation is another thing. There may be some specialized word to this, but not backpropagation. I think it's also called gradient descent.jstanback wrote: ↑Sun Jan 03, 2021 5:05 pmWhen I did gradient-descent, for each position I tweaked every parameter a bit and ran the evaluation to compute the gradient gParam = dEval/dParam. Then I adjusted each parameter by lr*gParam where lr is the learn rate. For 1000 parameters this required doing 1000 evaluations for each training position. I know there are more efficient methods, but that's what I was doing.
The method I'm using now just does one evaluation for each training position but keeps a count for each parameter that gets used when evaluating the position. Since white and black use the same eval terms the count is incremented for white and decremented for black. For example, if a position has 8 white pawns and 6 black pawns then the count for pawn_material would be +2. If the game result was 1.0 (win for white) and the eval was 0 centipawns (which gets converted to 0.5 expected win-fraction) then the error is 0.5-1.0 = -0.5 and I increase pawn_material by 2*lr*0.5. I'm using a learn rate of about 1e-3, so in this case pawn_material would be increased by only 1e-3 centipawns for this single position. But at a rate of 250K positions per second the eval terms converge quite quickly.
John
Apart from that it’s irrelevant, the point is that you understand what you’re doing.
-Tamás
Yes, it may amount to exactly the same thing, but it somehow seems different to me. I adopted this technique after experimenting with a tiny NN and learning to back-propogate. I realized that I could update the weights for an HCE exactly as is done for a single node of a NN except that I could eliminate using the derivative of the activation function since the HCE is just a linear sum of weights. Anyway, compared to my previous approact it sped up the tuning by a factor of 1000 and also made the tuning function much simpler. I have a method for using non-integer "counts" for some eval terms. For example I have a single value for king-safety and calculate a floating point scaling factor during the eval based on number enemy threats. The eval gets updated by scale*king_safety and the "count" for king_safety gets incremented by scale. It might actually be better to have separate terms for every possible number of enemy threats and let the training come up with the weight for each term. I did this initially to derive an appropriate scaling function, but I kind of like having a smoothly scaled feature.
John
