Superlinear interpolator: a nice novelity ?

[mcostalba]

It seems I was able to give a good boost to Glaurung 2.1 with this new (at least for me) idea.

Currently Glaurung for a given position evaluates middle game and an endgame score.

Then these scores are linearly interpolated based on the phase of the game:

Having mv, ev and ph (mid value, end value and phase) the formula is:

int result = (mv * ph + ev * (128 - ph)) / 128;

Until now nothing fancy, it is a linear iterpolation between the two values.


Instead of this I have introduced superlinear interpolation with the aim of faster transition between the phases but also more inertia before to transit, i.e. if we are _mostly_ in midgame use mid game value, and of course the same for end game.

Superlinear interpolation is:

int sli_ph = ph - (64 - ph) / 4;

sli_ph = Min(128, Max(0, sli_ph)); // ceiling

int result = (mv * sli_ph + ev * (128 - sli_ph)) / 128;

Although not expected, this small change gives a great boost in Glaurung playing style, it is more "wise" during mid game and plays more positional, but at the same time reaches very sharply the big semplification that normally marks the beginning of the end phase.

This is the last of a series of improvments I have done and that for me make Glaurung 2.1 convincebly stronger, but it is difficult for me to state this without an indipendent testing.

If someone is interested I can post the sources just to make people give it a try and for me to understand if progress is real or is just my test environment that is broken.

Regards
Marco

[BubbaTough]

I don't use the same technique as you, but I do use non-linear game phase weighting and also find it helpful.

-Sam

[Eizenhammer]

If someone is interested I can post the sources just to make people give it a try and for me to understand if progress is real or is just my test environment that is broken.
Regards
Marco

Of course people are interested.

Looking forward regards
Peter

[Eelco de Groot]

That is a nice idea Marco! I would also be interested in your changes or your ideas for improvements in Glaurung. Where will you be posting them? The Toga website might be one idea for posting sources, we don't have the possibility for attachments here in CCC. But Glaurung is not Toga. Tord's own site might be an idea for just exchanging some source ideas?

I think I have some idea where your non-linear phase might particulary be of some help with larger ph values in the middle game, it might help sometimes with King safety, because Tord builds off his king safety fairly quickly with diminishing material; if the opposing side does not have at least a full queen, in Glaurung 2.1 attacks on the own King are not counted at all, as you can see in the code below.

Code: Select all

    // King safety.  This is quite complicated, and is almost certainly far
    // from optimally tuned.  
    Color them = opposite_color(us);
    if(p.queen_count(them) >= 1 && ei.attackCount[them] >= 2
       && p.non_pawn_material(them) >= QueenValueMidgame + RookValueMidgame
       && ei.attacked[them]) {

I thought this cut-off might sometimes be too abrupt, also because Glaurung has sometimes very large values for King Safety. For Ancalogon I rely more on the effect that King Safety is not counted at at all in the endgame scores, so there is no big need to diminish it with decreasing material.

For instance I don't think Fruit does have a cut-off value like this at all. It might be possible to completely do without it.

I have not checked, but I believe Fruit or Toga do it this way. It once more shows the usefullness of Fabien's way of interpolating the evaluation values between the different phases of the game. I really do not understand the programmers who seemingly did not want to take notice of this very powerful technique. I understand the need to develop ideas of your own, but does that mean you can't use anything that you did not invent yourself, no matter if it is a brilliant and simple and also very general idea? I really do not understand that. But I will not mention any names. I have heard that Bob is considering the technique for Crafty, I do hope Crafty will get something like this too.

I had to check what values Ancalagon uses, I see that in Ancalagon at the moment I also did away with the requirement that the opposing side has to have at least a queen, that is one of the first changes I made. The number of attackers in variable attackCount is still counted though, and the value of enemy pieces still has to add up, but only to one queen. AttackCount did not mean quite the same for a while in Ancalagon, but this led to some very buggy behaviour when I had too large values for the variable, so attackCount does at the moment mean the number of attackers again, not the number of attacks.

I have not made any precise or even tentative tests which values are more optimal, it would depend on many other values also, but I think it may partly explain why you'd want the gamephase to decrease a bit less in some early endgames for Glaurung.

Changed code in Ancalagon for this particular segment:

Code: Select all

    // King safety.  This is quite complicated, and is almost certainly far
    // from optimally tuned.  
    Color them = opposite_color(us);
    if(p.queen_count(them) >= 0 && ei.attackCount[them] >= 2
       && p.non_pawn_material(them) >= QueenValueMidgame 
	   && ei.attacked[them]) {

Regards, Eelco

[bob]

That is a nice idea Marco! I would also be interested in your changes or your ideas for improvements in Glaurung. Where will you be posting them? The Toga website might be one idea for posting sources, we don't have the possibility for attachments here in CCC. But Glaurung is not Toga. Tord's own site might be an idea for just exchanging some source ideas?

I think I have some idea where your non-linear phase might particulary be of some help with larger ph values in the middle game, it might help sometimes with King safety, because Tord builds off his king safety fairly quickly with diminishing material; if the opposing side does not have at least a full queen, in Glaurung 2.1 attacks on the own King are not counted at all, as you can see in the code below.

Code: Select all

    // King safety.  This is quite complicated, and is almost certainly far
    // from optimally tuned.  
    Color them = opposite_color(us);
    if(p.queen_count(them) >= 1 && ei.attackCount[them] >= 2
       && p.non_pawn_material(them) >= QueenValueMidgame + RookValueMidgame
       && ei.attacked[them]) {

I thought this cut-off might sometimes be too abrupt, also because Glaurung has sometimes very large values for King Safety. For Ancalogon I rely more on the effect that King Safety is not counted at at all in the endgame scores, so there is no big need to diminish it with decreasing material.

For instance I don't think Fruit does have a cut-off value like this at all. It might be possible to completely do without it.

I have not checked, but I believe Fruit or Toga do it this way. It once more shows the usefullness of Fabien's way of interpolating the evaluation values between the different phases of the game. I really do not understand the programmers who seemingly did not want to take notice of this very powerful technique. I understand the need to develop ideas of your own, but does that mean you can't use anything that you did not invent yourself, no matter if it is a brilliant and simple and also very general idea? I really do not understand that. But I will not mention any names. I have heard that Bob is considering the technique for Crafty, I do hope Crafty will get something like this too.

I had to check what values Ancalagon uses, I see that in Ancalagon at the moment I also did away with the requirement that the opposing side has to have at least a queen, that is one of the first changes I made. The number of attackers in variable attackCount is still counted though, and the value of enemy pieces still has to add up, but only to one queen. AttackCount did not mean quite the same for a while in Ancalagon, but this led to some very buggy behaviour when I had too large values for the variable, so attackCount does at the moment mean the number of attackers again, not the number of attacks.

I have not made any precise or even tentative tests which values are more optimal, it would depend on many other values also, but I think it may partly explain why you'd want the gamephase to decrease a bit less in some early endgames for Glaurung.

Changed code in Ancalagon for this particular segment:

Code: Select all

    // King safety.  This is quite complicated, and is almost certainly far
    // from optimally tuned.  
    Color them = opposite_color(us);
    if(p.queen_count(them) >= 0 && ei.attackCount[them] >= 2
       && p.non_pawn_material(them) >= QueenValueMidgame 
	   && ei.attacked[them]) {

Regards, Eelco

We are looking at this quite carefully. But I am not sure it is "a powerful idea". It is a "simple idea". But there is nothing that says all endgame scores should phase in at the same rate, nor that all middlegame scores should phase out at the same rate. The only significant advantage is that it eliminates the "discontinuity effect" that Berliner described years ago. Abruptly turning something on or off can cause issues right around that threshold point. I have a ways to go yet to do the full interpolation implementation, but so far, it has actually weakened crafty a bit based on cluster testing. It may begin to help as all the endgame stuff is added (so far we are working on pieces only as we phase the changes in). There are lots of ways to phase things in our out without computing two separate scores and interpolating between them based on material. The approach in past crafty versions accomplishes exactly the same thing without the duplicated effort of adding up two scores everywhere...

[Onno Garms]

Hi Marco!

Sounds interesting. But could you post more concrete results? How many games against which opponents gave which result?

Onno

[mcostalba]

I have upload a snapshot here:

http://digilander.libero.it/mcostalba/g ... 210908.zip

Yes, it is a direct link to a zip file, this time no fancy html front page, sorry

I will not give ELO differences because I am mostly interested in testing my test environment more then Glaurung modifications itselfs. If the testing environment is not sound the modifications are just blind shots. Because I am new to this chess programming I need this prerquisite.

Anyhow testing is always done against the official Glaurung 2.1, at this stage I am not interested in comparing with other engines.

I am also not an expert of chess software compiling, I have used MSVC under Windows and gcc on Linux, settings are the standard for full optimization, but probably skiled people can squeeze out more from the compiler.

Of course, in case you are interested in testing, please use the same compiler settings for this version and the opponent.

Glaurung shows its best at 64bit, but because I have a 32bit I have tweaked a little the critical path functions for the 32 bit case in particular bit scanning is now slightly faster on 32bits under MSVC.

Please report back any result you have with this Glaurung clone, as I said I am most interested in validate my testing environment so feedback from an indipendent tester is invaluable.

Thanks
Marco

[bob]

I have upload a snapshot here:

http://digilander.libero.it/mcostalba/g ... 210908.zip

Yes, it is a direct link to a zip file, this time no fancy html front page, sorry

I will not give ELO differences because I am mostly interested in testing my test environment more then Glaurung modifications itselfs. If the testing environment is not sound the modifications are just blind shots. Because I am new to this chess programming I need this prerquisite.

Anyhow testing is always done against the official Glaurung 2.1, at this stage I am not interested in comparing with other engines.

I am also not an expert of chess software compiling, I have used MSVC under Windows and gcc on Linux, settings are the standard for full optimization, but probably skiled people can squeeze out more from the compiler.

Of course, in case you are interested in testing, please use the same compiler settings for this version and the opponent.

Glaurung shows its best at 64bit, but because I have a 32bit I have tweaked a little the critical path functions for the 32 bit case in particular bit scanning is now slightly faster on 32bits under MSVC.

Please report back any result you have with this Glaurung clone, as I said I am most interested in validate my testing environment so feedback from an indipendent tester is invaluable.

Thanks
Marco

Does this mean you are only comparing stock G2.1 to your modified version? That won't tell you anything useful at all...

[Dirt]

This still looks linear to me, just with a slightly steeper slope. Where does ph come from? Just incrementing it by one each ply would be simplest, but I don't think that could be right.

[Eelco de Groot]

This still looks linear to me, just with a slightly steeper slope. Where does ph come from? Just incrementing it by one each ply would be simplest, but I don't think that could be right.

Normally the character of the game changes whenever there is an exchange (it can't be undone). So a simple method is to keep track of the material balance, if heavier pieces go, subtract more points from the variable that keeps track of this. It also makes a difference of course what kind of pieces go but that is more something for the evaluation function.

I think that when pieces are taken off, this inevitably creates discontinuities in the eval function, so these are natural points to make different assesments possible also for other characteristics of the position even if the character of the battle does not change much by the exchange. This to limit the number of discontinuities. Another question is I think how much you should do an interpolation also of impending or recent piece exchanges, how much the discontinuities are also necessary for correct evaluations.

As far as I remember the ph game-phase in Glaurung starts with 128 after leaving the opening and gradually goes to zero when only the Kings are left. I have not checked the precise details but Tord has sources that are well commented. Search for the codepart where pos.gamephase is constructed. In evaluate.cpp then the variable phase is used that is linked to that,

Code: Select all

phase = pos.game_phase();

phase becomes ph in the scaling function that interpolates between endgame value and middlegame value.


Some values I get when I compute Marco's sli_ph from ph, 128 is the starting value, 0 the endvalue, values >128 and <0 are truncated to these start and endvalues, but I left the truncation out:

Code: Select all

ph   sli_ph
128  144
120  134
110  121.5
100  109
90   96.5
80   84
70   71.5
60   59
50   46.5
40   34
30   21.5
20   9
10  -3.5

Regards, Eelco