Engines playing Musketeer Chess, good price

[hgm]

Well, it sounds like you would have to change and recompile the engine for that to create a new version. Surely you do not expect WinBoard to compile your source code and make changes to it?

[Ferdy]

Well, it sounds like you would have to change and recompile the engine for that to create a new version. Surely you do not expect WinBoard to compile your source code and make changes to it?

Engine parameter optimizations are mostly done by playing an engine match (Texel tuning uses position tests). The optimizer will change the parameter values, run the match using winboard or other means, get the result then suggest new values for the next engine match. With so many variants that it can support, it would be interesting if winboard will be equipped with a parameter optimizer.

I have forked a python-spsa by snicolet at https://github.com/fsmosca/spsa/commits/master and the engine match is handled by cutechess-cli. This alone needs more tests if it can really give optimal values from same engine optimizing mainly the material piece values especially for those variants with unusual moves.

I will attempt to support winboard as it has command line options too. In here I have to enable the debug because I will read the result of the engine match and send it to the optimizer.

[hgm]

I understand the match part, but what else would you expect WinBoard to do, concerning the parameters? How would it change these parameters in the first place? Are they engine options? If so, how would it know which options represent parameters that should be tweeked? And how could it know what are reasonable values for such parameters to try?

It sounds like a very inefficient process, if you have to tune many parameters one by one.

For determining piece values playing matches with different value settings is a disastrously poor method.

[Ferdy]

I understand the match part, but what else would you expect WinBoard to do, concerning the parameters? How would it change these parameters in the first place? Are they engine options?

Yes the parameters can be an engine option for example,
feature option="queenvalue -spin 950 800 1200"

I don't know how winboard would handle it, but what I have plan is to use the following.

Code: Select all

/firstOptions string
/secondOptions string

to change the engine parameter values in the command line.

If so, how would it know which options represent parameters that should be tweeked?

That can be designed as engine and winboard can communicate.

And how could it know what are reasonable values for such parameters to try?

Will use the SPSA for example.
This ref is good.
https://www.jhuapl.edu/spsa/PDF-SPSA/Sp ... aneous.PDF

There is also this.
https://www.jhuapl.edu/SPSA/

And the matlab code.
https://www.jhuapl.edu/SPSA/PDF-SPSA/Ma ... SA_Alg.pdf

matlab pseudo code.

Code: Select all

for k=0:n-1
  ak=a/(k+1+A)^alpha;
  ck=c/(k+1)^gamma;
  delta=2*round(rand(p,1))-1;
  thetaplus=theta+ck*delta;
  thetaminus=theta-ck*delta;
  yplus=loss(thetaplus);
  yminus=loss(thetaminus);
  ghat=(yplus-yminus)./(2*ck*delta);
  theta=theta-ak*ghat;
end
theta

theta = init theta, can be {queen: 950, rook: 450, name: value ...}
n is max iteration
k is the iteration number
a, A, alpha, c, gamma are constants.
p in delta() is the number of parameters to tune.
delta is an array of random +/-1 can be [-1, 1] if parameters to tune is 2.
theta is a vector of parameter and value pair, {queen: 950, rook: 450}
thetaplus is just a new value of theta using positive ck*delta
given:
c=0.1
k=5 or iteration
gama=0.12
ck = 0.1/(5+1)^0.12 = 0.08

delta for first param is -1
ck*delta = -0.08

delta of second param is +1
ck*delta = +0.08

thetaplus is then {queen: 950 + (-0.08), rook: 450 + (-0.08)}

thetaminus can be calculated the same way.

we may call ck*delta as perturbation values.

Then the interesting part.
yplus=loss(thetaplus);
yminus=loss(thetaminus);

loss can be a result of an engine match.
engine1 the engine that handles variable parameters vs engine2 the engine with fix parameter that we are trying to improve.
The thetaplus here is {queen: 950 + (-0.08), rook: 450 + (-0.08)}
the thetaplus values here are small but lets see what will happen to it at higher iterations. If it is still small a factor can be introduced.

The result in loss can be a score, say a match 4 games engine1 scored 1, the loss will return 1/4 or 0.25. But we maximize the score and spsa tries to minimize so we return -score and yplus=-0.25

Do the same for yminus using thetaminus or theta perturbed by -ck*delta.

The ghat looks like a gradient from the two loss functions and ak controls its value.

Calculate ghat and update theta, then do it again.

SPSA in perl is at https://github.com/zamar/spsa, it uses a different system of loss, but still create matches for engines.

The one I forked is at https://github.com/snicolet/spsa, also different but still involve engine matches.

[Ferdy]

I understand the match part, but what else would you expect WinBoard to do, concerning the parameters? How would it change these parameters in the first place? Are they engine options?

Yes the parameters can be an engine option for example,
feature option="queenvalue -spin 950 800 1200"

I don't know how winboard would handle it, but what I have plan is to use the following.

Code: Select all

/firstOptions string
/secondOptions string

to change the engine parameter values in the command line.

If so, how would it know which options represent parameters that should be tweeked?

That can be designed as engine and winboard can communicate.

And how could it know what are reasonable values for such parameters to try?

Will use the SPSA for example.
This ref is good.
https://www.jhuapl.edu/spsa/PDF-SPSA/Sp ... aneous.PDF

There is also this.
https://www.jhuapl.edu/SPSA/

And the matlab code.
https://www.jhuapl.edu/SPSA/PDF-SPSA/Ma ... SA_Alg.pdf

matlab pseudo code.

Code: Select all

for k=0:n-1
  ak=a/(k+1+A)^alpha;
  ck=c/(k+1)^gamma;
  delta=2*round(rand(p,1))-1;
  thetaplus=theta+ck*delta;
  thetaminus=theta-ck*delta;
  yplus=loss(thetaplus);
  yminus=loss(thetaminus);
  ghat=(yplus-yminus)./(2*ck*delta);
  theta=theta-ak*ghat;
end
theta

theta = init theta, can be {queen: 950, rook: 450, name: value ...}
n is max iteration
k is the iteration number
a, A, alpha, c, gamma are constants.
p in delta() is the number of parameters to tune.
delta is an array of random +/-1 can be [-1, 1] if parameters to tune is 2.
theta is a vector of parameter and value pair, {queen: 950, rook: 450}
thetaplus is just a new value of theta using positive ck*delta
given:
c=0.1
k=5 or iteration
gama=0.12
ck = 0.1/(5+1)^0.12 = 0.08

delta for first param is -1
ck*delta = -0.08

delta of second param is +1
ck*delta = +0.08

thetaplus is then {queen: 950 + (-0.08), rook: 450 + (-0.08)}

Correction, it should be.
thetaplus is then {queen: 950 + (-0.08), rook: 450 + (+0.08)}

and also here,

The thetaplus here is {queen: 950 + (-0.08), rook: 450 + (-0.08)}

The thetaplus here is {queen: 950 + (-0.08), rook: 450 + (+0.08)}

[hgm]

OK, I see. When I still was a physicist I used similar stochastic methods to optimize parameters of models for the electrical field inside an atom. My experience was that in this simple form they did not work very well. The problem was that they probe around by an equal amount in all directions in the multi-dimensional parameter space. If your objective function is much more sensitive to one parameter than to the others, the random probes will almost always jump far from the optimum for that one, unless ck gets very small (either by starting with small c, or waiting until k gets large). By that time it will be able to optimize that sensitive parameter, but the changes it tries in the others will be so small that it never reaches an optimum for those. If it is really sensitivity in the individual parameters that differs, you can cure this by scaling the parameters such that the objective funcion is approximately equally sensitive to any of them. (Or, equivalently, by making c a vector.) But often the high sensitivity is not along a coordinate axis, but in an intermediate direction. E.g. you might be very sensitive to queen - 2*rook, while changes in 2*queen + rook also can give a good improvement, but only when they are very large. But you would never discover the latter improvement when the former forces you to make small steps delta. (This is the 'river-valley problem': it is very easy by local probing of height to get to the bottom of the valley. But once you are at the bottom, it is very hard to get to the sea without immediately jumping out of the valley.)

Anyway, if you have a script that determines what parameter settings you want to try, you can use WinBoard to have it play the matches, specifying the settings through -first/secondOptions, as you say. And getting the result from the PGN file.

[Ferdy]

OK, I see. When I still was a physicist I used similar stochastic methods to optimize parameters of models for the electrical field inside an atom. My experience was that in this simple form they did not work very well. The problem was that they probe around by an equal amount in all directions in the multi-dimensional parameter space. If your objective function is much more sensitive to one parameter than to the others, the random probes will almost always jump far from the optimum for that one, unless ck gets very small (either by starting with small c, or waiting until k gets large). By that time it will be able to optimize that sensitive parameter, but the changes it tries in the others will be so small that it never reaches an optimum for those. If it is really sensitivity in the individual parameters that differs, you can cure this by scaling the parameters such that the objective funcion is approximately equally sensitive to any of them. (Or, equivalently, by making c a vector.) But often the high sensitivity is not along a coordinate axis, but in an intermediate direction. E.g. you might be very sensitive to queen - 2*rook, while changes in 2*queen + rook also can give a good improvement, but only when they are very large. But you would never discover the latter improvement when the former forces you to make small steps delta. (This is the 'river-valley problem': it is very easy by local probing of height to get to the bottom of the valley. But once you are at the bottom, it is very hard to get to the sea without immediately jumping out of the valley.)

Anyway, if you have a script that determines what parameter settings you want to try, you can use WinBoard to have it play the matches, specifying the settings through -first/secondOptions, as you say. And getting the result from the PGN file.

Will attempt to make an improvement after some tests of the current implementation.

[Ferdy]

Leopard is missing. Board size is middling.

[hgm]

There is no built-in image for the Leopard. It only works with external piece images.

[Ferdy]

There is no built-in image for the Leopard. It only works with external piece images.

Thanks, it works by setting the image folder to bmaps.
/pieceImageDirectory="bmaps"