Why computing K that minimizes the sigmoid func. value?...

[cdani]

So I published the new version of Andscacs with this self tuning done.

The first 4th-6th iterations with the tuning where the best in improvements; I was testing after each iteration. The next after the last good was really bad, so I decided to generate a new bunch of games.

This time I obtained improvements, little ones, until the 9th iteration.

Here I tuned the piece values alone, not present in previous tunings, until the tuning finished. Was a little win. I have yet to try with partial tuning.

Then I added parameters related to passed pawns and I tuned all things related to passed pawns alone, obtaining a little win but only in the 4th first iterations.

Then I tuned some new parameters related with knights that converged quickly and was a little win.

A new general tuning try was bad from the first attempt, so I decided to stop here.

For some of the parameters I use, instead of an static value, a proportional value that is increased/reduced in powers of two and derived values. To tune them I used this function:

Code: Select all

int incrementa_redueix_proporcionalment(int v, int increment) {
	int r, j;
	if (increment == 0)
		return v;
	//64
	j = abs(increment);
	if (j == 1)
		r = FerPun(PunI(v) >> 5, PunF(v) >> 5); //2
	else if (j == 2)
		r = FerPun(PunI(v) >> 4, PunF(v) >> 4); //4
	else if (j == 3)
		r = FerPun(PunI(v) >> 3, PunF(v) >> 3); //8
	else if (j == 4)
		r = FerPun(PunI(v) >> 3, PunF(v) >> 3) + FerPun(PunI(v) >> 4, PunF(v) >> 4); //12
	else if (j == 5)
		r = FerPun(PunI(v) >> 2, PunF(v) >> 2); //16
	else if (j == 6)
		r = FerPun(PunI(v) >> 2, PunF(v) >> 2) + FerPun(PunI(v) >> 4, PunF(v) >> 4); //20
	else if (j == 7)
		r = FerPun(PunI(v) >> 2, PunF(v) >> 2) + FerPun(PunI(v) >> 3, PunF(v) >> 3); //24
	else if (j == 8)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1); //32
	else if (j == 9)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1) + FerPun(PunI(v) >> 3, PunF(v) >> 3); //40
	else if (j == 10)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1) + FerPun(PunI(v) >> 2, PunF(v) >> 2); //48
	else if (j == 11)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1) + FerPun(PunI(v) >> 2, PunF(v) >> 2) + FerPun(PunI(v) >> 3, PunF(v) >> 3); //56
	else if (j == 12)
		r = v; //64
	return increment > 0 ? v + r : v - r;
}

PunI means mg value, and PunF eg value.

I don't know if someone is using something similar. I have not seen something like this in other engines.

[Laskos]

So I published the new version of Andscacs with this self tuning done.

Good tuning method for fooling the Similarity detector. 0.84 versus 0.83 has 50% similarity hit, much below 65%-75% of the successive versions of engines, and below 60% which starts to show positive as derivative.

[cdani]

So I published the new version of Andscacs with this self tuning done.

Good tuning method for fooling the Similarity detector. 0.84 versus 0.83 has 50% similarity hit, much below 65%-75% of the successive versions of engines, and below 60% which starts to show positive as derivative.

Curious. I never used this tool. But I think your result is very logical, as hand tuning is, well, very manual

[Evert]

So I published the new version of Andscacs with this self tuning done.

The first 4th-6th iterations with the tuning where the best in improvements; I was testing after each iteration. The next after the last good was really bad, so I decided to generate a new bunch of games.

Beware that finding a drop in strength after an iteration doesn't necessarily mean that it'll keep getting worse: the next iteration might be better again. The landscape unlikely to be some nice smooth surface with a well-defined minimum that you can find easily, sometimes you have to "climb a hill" to find the (locally optimal) minimum.
Did you check whether the residual of the evaluation was still getting better? If you see that a new set of evaluation parameters doesn't improve the residual it may be worth it to reduce the amount by which the parameters are adjusted.

For some of the parameters I use, instead of an static value, a proportional value that is increased/reduced in powers of two and derived values. To tune them I used this function:

Code: Select all

int incrementa_redueix_proporcionalment(int v, int increment) {
	int r, j;
	if (increment == 0)
		return v;
	//64
	j = abs(increment);
	if (j == 1)
		r = FerPun(PunI(v) >> 5, PunF(v) >> 5); //2
	else if (j == 2)
		r = FerPun(PunI(v) >> 4, PunF(v) >> 4); //4
	else if (j == 3)
		r = FerPun(PunI(v) >> 3, PunF(v) >> 3); //8
	else if (j == 4)
		r = FerPun(PunI(v) >> 3, PunF(v) >> 3) + FerPun(PunI(v) >> 4, PunF(v) >> 4); //12
	else if (j == 5)
		r = FerPun(PunI(v) >> 2, PunF(v) >> 2); //16
	else if (j == 6)
		r = FerPun(PunI(v) >> 2, PunF(v) >> 2) + FerPun(PunI(v) >> 4, PunF(v) >> 4); //20
	else if (j == 7)
		r = FerPun(PunI(v) >> 2, PunF(v) >> 2) + FerPun(PunI(v) >> 3, PunF(v) >> 3); //24
	else if (j == 8)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1); //32
	else if (j == 9)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1) + FerPun(PunI(v) >> 3, PunF(v) >> 3); //40
	else if (j == 10)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1) + FerPun(PunI(v) >> 2, PunF(v) >> 2); //48
	else if (j == 11)
		r = FerPun(PunI(v) >> 1, PunF(v) >> 1) + FerPun(PunI(v) >> 2, PunF(v) >> 2) + FerPun(PunI(v) >> 3, PunF(v) >> 3); //56
	else if (j == 12)
		r = v; //64
	return increment > 0 ? v + r : v - r;
}

PunI means mg value, and PunF eg value.

I don't know if someone is using something similar. I have not seen something like this in other engines.

I can't really tell what that code does (the function names are meaningless to me), perhaps if you can explain more clearly what it's supposed to do...?

[cdani]

Beware that finding a drop in strength after an iteration doesn't necessarily mean that it'll keep getting worse: the next iteration might be better again.

I thought a little about it but I decided to go for the easier path. Probably I will try again with a new group of games. The problem is that a single iteration of the +1000 parameters is like 7-8 hours, even in a powerful 6 core cpu.

Did you check whether the residual of the evaluation was still getting better?

If you mean the "e" value, yes, it was getting better.

If you see that a new set of evaluation parameters doesn't improve the residual it may be worth it to reduce the amount by which the parameters are adjusted.

I was using the minimum amount of increase/reduction for every parameter, 1 or -1.

I can't really tell what that code does (the function names are meaningless to me), perhaps if you can explain more clearly what it's supposed to do...?

Sorry, I went to fast.

Some parameters of the evaluation function are relative to others. For example I diminish the base piece square table value of the knight depending if it's outposted or semioutposted. Or for passed pawns I have 5 different ways to increase/reduce their base value depending on various conditions. I have other similar parameters anywhere also.

Those parameters are not fixed values but they modify the base value by increasing/reducing it proportionally to his current value. So with this function I tuned which proportion was the best one to increase/reduce the value.

An example. Suppose the PST value of a knight is (20 mg, 15 eg), but a pawn can sooner or later menace it. The tuned parameter for this case has the value -7, so following the function, the final value will be:
(20 mg, 15 eg) - ((20 >> 2, 15 >> 2) + (20 >> 3, 15 >> 3)) = (13 mg, 11 eg)

If the PST value of the knight was initially negative, this reduction will not take part.

The tuning process can iterate from -12 to 12 ("increment" is the name of this variable) each parameter of this type. The comments like //12, //40 are examples of which value will be added/subtracted if the entered value (v) was 64.

I have yet to try to increase/reduce proportionally separately the mg/eg part.

[cdani]

I'm tuning by hand some of the parameters again, as Texel tuning method, even if I tried to control most changes, has tuned some of them for fast time control.

Was evident when I started to see bad played games in long time controls of the new version. If in general the result is better, but Andscacs has clearly lost a lot of balance.

The good part is because I have worked by hand most of the time I have reference values of the parameters that tend to be very sensitive to time control, so I can go direct to try probably working changes, so for the moment I can regain some strength and equilibrium without much work.

[cdani]

Also when you see CCRL 40/40 and CCRL 40/4 is clear something has gone bad, as 0.84 has more rating (in one CPU for the moment) in 40/4, when the objective is the other way, and not by a little margin but at least 30 elo.

[tpetzke]

Also when you see CCRL 40/40 and CCRL 40/4 is clear something has gone bad, as 0.84 has more rating (in one CPU for the moment) in 40/4, when the objective is the other way, and not by a little margin but at least 30 elo.

But another interpretation could be that your eval is superior to the one of your opponents and so in short TC matches (where eval gets more pressure) your engine is very strong. In long TC matches your opponents can compensate a bit their worse eval by searching longer (eval gets a bit less pressure).

As I don't have the resources to test at long TC anyway I don't care. I tune at short TC and at long TC it is as it is.

[cdani]

Also when you see CCRL 40/40 and CCRL 40/4 is clear something has gone bad, as 0.84 has more rating (in one CPU for the moment) in 40/4, when the objective is the other way, and not by a little margin but at least 30 elo.

But another interpretation could be that your eval is superior to the one of your opponents and so in short TC matches (where eval gets more pressure) your engine is very strong. In long TC matches your opponents can compensate a bit their worse eval by searching longer (eval gets a bit less pressure).

As I don't have the resources to test at long TC anyway I don't care. I tune at short TC and at long TC it is as it is.

When you accept the patches that win more at ltc, you end with an engine that is stronger at ltc.

I was no cautious enough at least for king safety and passed pawn ones, and as a result Andscacs 0.84 showed clear bad tuning and loses quite easy some games, thing that I think that happened less with previous version.

So the verification of this is that now as I retune by hand those parameters, at least with some ones I'm wining some strength back just returning to old values or near those old values, so those parameters where bad automatically tuned.

Of course I cannot be absolutely sure of this, because I cannot try really at longest time controls, but I expose what I have achieved working like this with previous versions.

Many times you see the effect with really fast time control games. So for example you can test at 5 seconds +0.03 and then at 11 + 0.03 and you already see that at 11 the change is less bad that at 5, or if you have luck, that is already good. Sometimes this does not scales further, so if is less bad at 11, better try at 20 or more if you are able to, or if not, better discard the patch.

[tpetzke]

Many times you see the effect with really fast time control games. So for example you can test at 5 seconds +0.03 and then at 11 + 0.03 and you already see that at 11 the change is less bad that at 5, ...

If the patch is bad a 5+0.03 I already throw it away. If it is a simplification and performs equal it is kept. Otherwise patches that are equal but add code are also thrown away.

Only patches related directly to TC are tested with different TCs.

But as I said, I don't do it because I think this method is superior (it probably is not) I do it because of my limited resources.

I find endgame related terms (like passed pawn) harder to tune than the others as many games end or are decided before the term is activated however the tuner thinks it can use the result of the game to adjust the weight of that term.

There is no easy fix for that in my framework, except for using only games that start from balanced endgame positions (which are also not easy to find).