Thanks for the hint, i checked the pov situation more than, i cannot count it... lolFerdy wrote: ↑Thu Jan 14, 2021 12:11 pmJust checking, given this training position,Desperado wrote: ↑Wed Jan 13, 2021 1:04 pm Hello everybody,
to understand what is going on, i thought i can use a databse that i did not generate myself.
So i used ccrl-40-15-elo-3200.epd from https://rebel13.nl/misc/epd.html.
Setup:
1. material only evaluator
2. cpw algorithm
3. scalingfactor K=1.0
4. pawn values are anchor for mg and eg [100,100]
5. starting values [300,300][300,300],[500,500][1000,1000]
6. loss function uses squared error
7. 50K sample size
8. phase value computation
Code: Select all
int phase = 1 * Bit::popcnt(Pos::minors(pos)); phase += 2 * Bit::popcnt(Pos::rooks(pos)); phase += 4 * Bit::popcnt(Pos::queens(pos)); phase = min(phase, 24); int s = (score.mg * phase + score.eg * (24 - phase)) / 24; return pos->stm == WHITE ? s : -s;
Your material eval would return a score of -300 cp, point of view is side or spov.Code: Select all
1r6/1p1r4/2p1p3/2PBP1Bk/R2P2bP/5p2/1R1K4/8 b - -,1-0
Notice the side to move and result.
Check your score and formula if your sigmoid is the same as mine.
if side is black set score to -score, then apply sigmoid.
Code: Select all
K=1.0 sigmoid = 1.0/(1.0 + 10.0**(-K*score/400.0))
Code: Select all
sigmoid: 0.8490204427886767 result = 1.0 error = 1.0 - sigmoid squared_error = error*error
The formular is the same. As i pointed out in my last 2 posts for you, the choice of the positions
might have a big influence. (the draws). The randomization of the N-K batch is intersting but does
not have a big influence on the situation. I already know, that the draws change things a lot but i need to measure now a full run.
My internal interface
Code: Select all
void ISearch::staticEval(pos_t* pos)
{
resultDepth = 0;
resultScore = Eval::full(pos);
resultScore = pos->stm == WHITE ? resultScore : -resultScore;
resultMove = NO_MOVE;
resultNodes = 0;
Line::clear(&resultPv);
}