CLOP question

[lucasart]

I would like to CLOP-timize my null reduction formula. Currently, I use:

Code: Select all

R = 3 + depth/4

The (3,4) is only approximately optimal, and in the sense that modifying one param only is worse or no better (within error bar). In theory, CLOP can co-tune, hence do a better job.

What is the best model specification?

Code: Select all

1/ R = a + depth / b
2/ R = (a + depth * b) / 256

Target is to tune (a,b) as integer parameters. Model 2/ makes my discrete problem more continuous. This should be better, no ? On the other hand, would convergence be faster in model 1/ ?

[BB+]

Code: Select all

R = a + depth / b
R = (a + depth * b) / 256

Given that CLOP minimises regret (y-axis), I think the fungibility of the x-axis [speaking in terms of 1 variable] should not play too deep of a role for the convergence rate, unless you are trying to get within epsilon of minimal regret and the necessary delta is too small. Looking at Figure 1 (page 5), if the x-values are highly discrete, then you reach the "all-noise" situation faster for the "bias" is indistinguishable in any case. OTOH, I'm not sure that minimising "convergence rate" is really what you want, you might rather want to be able to approach the minimal regret as closely as possible in a parameter space.

Perhaps what you want is the x-difference to be small enough so that a quadratic fit near the optimum is not too erroneous. Does your engine really work in 256ths of a ply? Else I would just go with a half-ply or whatever the nominal accounting of depth is.

Incidentally, I think game phase should be included in the formula (and that D/4 is too large in general, maybe OK near game end).

EDIT: Oh wait, you had "a+D/b" in one and "(a+D*b)/256" so in one case b in the denominator and in the other it is in the numerator? Let me rethink this then. The "real" answer is likely "try both and see" and maybe you should test also "R=round(a+b*D)" where a and b are floats. You should also probably be prepared for there to be a large "indifference region" in that a largish (a,b) region could lead to indistinguishable results (up to the testing statistical error).

[lucasart]

I have had great success using the model

Code: Select all

R = (a + depth * b) / 32

Despite the fact that DiscoCheck does not use fractional depth, since we use integer arithmetic here (division truncates), the choice of the divisor 32 controls the granularity of the model if you like.

As you say, there is a large indifference zone. This is very common in practice it seems. But it does not really matter: what matters is that the CLOP values perform better (elo-wise) than the initial ones, even if they are not truly optimal (indifference region means values may be far from maximum, but their elo performnace is still close). The CLOP GUI is really cool, and helps better apprehend what is going on.

Bravo Remi Coulom

The only thing I am afraid of is scaling. Because I need lots of games for CLOP, I have to play very fast games: I use 2.4"+0.02". And what is an optimal formula for super fast TC may not be so optimnal at long TC: I don't expect this to be a problem for eval weights for example, but for null move formula R = f(depth), I am a bit worried. Anyway, I will run an SPRT test for validation of the CLOP values at "long TC" (ie. 6"+0.05").

[User923005]

It seems logical to me to run more than one test when you are worried about depth changing outcome.
You can run one superfast run and compute the value.
Double the time and compute it again.
If it does not move, within experimental uncertainty, then it seems that the measure is relatively depth invariant.
If it does move, then double the time again and see if it continues to move.
Obviously, it becomes prohibitively expensive. On the other hand, no real contests ever take place a testing speed.
So even though it hurts, I think it makes sense to do it that way.

I have a theory that everything mitigates with depth.
For instance, if we could see 1000 plies ahead, we would not need to attach any piece values to the chessmen.
By seeing their value in moving towards the goal, preservation of those pieces would fall out of the computation itself.
If we could see 12,000 plies ahead, all we would need is mate, loss, draw and nothing else for any measure.