Superlinear interpolator: a nice novelity ?

[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

[mcostalba]

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

That's interesting. You seem very sure about this. Could you please explain me why ?

Answering to other comments in this thread, I would think the truncation is an integral part of the algorithm, that's what makes it non linear.

But it is true I have not tested by simply increasing the maximum value from 128 to say 160 and see what happens...I'll do.

Marco

[Eelco de Groot]

Thanks very much for your Glaurung version Marco! I only had a short look yet at the sources but it looks very interesting and there also seems to be a substantial amount of changes that are more programming-technical in nature, changes I think Tord, or other programmers, here will be interested in, even if it is just to compare different possibilities for doing things?

I have asked if Jim Ablett maybe could make a compile for us, I hope that is possible! That way there would also be a standardized version to compare any testresults. But I don't know if Jim has the time.

Regards, Eelco

[mcostalba]

Thanks very much for your Glaurung version Marco! I only had a short look yet at the sources but it looks very interesting and there also seems to be a substantial amount of changes that are more programming-technical in nature, changes I think Tord, or other programmers, here will be interested in, even if it is just to compare different possibilities for doing things?

I have asked if Jim Ablett maybe could make a compile for us, I hope that is possible! That way there would also be a standardized version to compare any testresults. But I don't know if Jim has the time.

Regards, Eelco

Tord has access to my git repository so he knows every bit of change and also the rationale behind it.

By now most changes are code style and cleanup related because I know more C++ then chess programming

I hope that improving my chess programming knowledge will bring also more substantial changes...

Anyhow the (few) real changes are:

- Superlinear interpolation

- Hashing in qsearch

- Opponent time info

The last one was originated from my way to play chess: when I am in a trouble position I take a bit more time to analize. And if I am in great time advantage against my opponent I take also more time.

I have coded this empirical rule and the results were positive. Indeed I was surprised to NOT find any consideration regarding opponent remaining time in any of the chess engine I have checked, not only in Glaurung...perhaps I'm missing something...


To have properly compiled versions for 32 and 6f bits would be great !

Thanks
Marco

[BubbaTough]

- Opponent time info

The last one was originated from my way to play chess: when I am in a trouble position I take a bit more time to analize. And if I am in great time advantage against my opponent I take also more time.

I have coded this empirical rule and the results were positive. Indeed I was surprised to NOT find any consideration regarding opponent remaining time in any of the chess engine I have checked, not only in Glaurung...perhaps I'm missing something...

I have had this in my program for a while, and took it out recently. My version also included spending less time if your opponent had more time than you. I have mixed feelings on it. My last thought was that if your opponent is better at allocating time than you are the heuristic is useful (since it acts to make your time usage per move similar to your opponents over the course of the game) and if your opponent is worse at time allocation than is harmful. It is not really something I do as a human (I strive to make my time usage independent of opponent) and I don't really have a good feel for whether the idea has merit or not. One idea I considered but have not tried is when opponent is super low on time, use extensions to calculate a series of moves and than blitz them out (something humans sometimes do). This seems like it might be fairly effective, particularly against humans...but also against computers as it robs their usage of ponder. Anyway, I think time usage is an interesting area to explore, and am interested in hearing your findings in that area as you encounter them.

-Sam