Super settings for Glaurung?

[Eelco de Groot]

I posted in another thread from Jon Dart some testgames with Tord's new Glaurung creation, I think the few results show some promise. I could send all the feedback to Tord only but as Glaurung is an open source engine, I don't think, at least I hope not that Tord minds my posting a bit here, so others can do some experimenting. Those who have the sources for the new Glaurung can make changes in their own copy of the sources, if they so wish. If necessary I could make a compile for a Windows version but it would not be a topspeed compile, so..

Tord has made a Glaurung version that compiles practically right away under Microsoft Visual Studio C++, I had to make just one small change, in ucioption.cpp there was an assert instruction but assert.h was not yet included... No problem even for a Rookie programmer, the beginning of ucioption.cpp is changed to include the C Diagnostics Library with <cassert>

Code: Select all

////
//// Includes
////

#include <cstdarg>
#include <cstdio>
#include <cassert>

#include "misc.h"
#include "thread.h"
#include "ucioption.h"

Still a lot of warnings but most of those have to do with the fact that Tord defines some functions as Boolean I believe which the compiler does not expect. I don't think it matters much in performance. Apart from that one change, everything compiles perfectly under Windows now!

I like to do things a bit differently if there are options, so I am not testing everything with default uci-options. No big changes and there are not that many options yet for tuning passed pawns etc. in the parameters, so that is for the moment not changed, but a few other parameters were changed in order to get more depth if possible, and those changes did not seem to hurt much in the older versions of Glaurung. The .eng file of Shredder is changed to

Code: Select all

[ENGINE]
Name=Glaurung 080419 Mjolnir 002
Author=Tord Romstad
Filename=D:\Shredder 9 UCI\Engines\Glaurung 080419 Mjolnir\Glaurung 080419 Mjolnir.exe
[OPTIONS]
Single Reply Extension (PV nodes)=2
Single Reply Extension (non-PV nodes)=2
Threat Depth=6
Selectivity=8
Razoring Margin=350

I could change some of these defaults in the code also but have not done that, can always be added later if necessary.

Then I did some testing to see if changes in King Safety could have some benefit. This is a difficult subject; if you want to improve the elo-performance, you easily overstep the limit and it becomes counterproductive. Tord has said in the past (about Glaurung 1.2.1) that there is a wide range of possible values that practically all lead to the same strength of the engine but just change the style. I think that is even the case if you change other parameters to harmonize with King Safety, even then it is difficult, if not impossible to get a stronger engine that also likes to attack more.

But as I said there may be a little hope of at least finding some better tuning values because the new King Safety is only just implemented. Besides this I changed the default UCI-parameters so this should give some extra room for finding a new balance. I like to think of this process as "simulated annealing" which is just a technical term. It comes down to the fact that you first have to disturb the existing balance to find a new one with changed parameters, and then gradually you should "cool things down" to let the new equilibrium take hold.

In this case I made only one small change in the code and the thought behind it is that an imperfect King Safety, a compromised king position is not always bad alone, but if you have more weaknesses in your position I think those can be exploited by the opponent because it is hard to defend multiple weaknesses, and they are likely not located in the same place if it involves things not calculated in the King Safety routine. A material deficit plus King safety problems is I think another example. I have not really studied Tord's code very much but I made a simple change from

Code: Select all

      // Finally, extract the king safety score from the 

SafetyTable[] array.
      // Add the score to the evaluation, and also to 
ei.futilityMargin.  The
      // reason for adding the king safety score to the futility 
margin is
      // that the king safety scores can sometimes be very big, 
and that
      // capturing a single attacking piece can therefore result 
in a score
      // change far bigger than the value of the captured piece.
      assert(inc < 100);
      ei.mgValue -= 34/16 * sign * Value(SafetyTable[inc]);
      if(c == p.side_to_move())
        ei.futilityMargin += Value(2 * SafetyTable[inc]);

to

Code: Select all

      // Finally, extract the king safety score from the SafetyTable[] array.
      // Add the score to the evaluation, and also to ei.futilityMargin.  The
      // reason for adding the king safety score to the futility margin is
      // that the king safety scores can sometimes be very big, and that
      // capturing a single attacking piece can therefore result in a score
      // change far bigger than the value of the captured piece.
      assert(inc < 100);
      ei.mgValue -= ((1000 - ei.mgValue) * sign * Value(SafetyTable[inc])/256);
      if(c == p.side_to_move())
        ei.futilityMargin += Value(2 * SafetyTable[inc]);
    }
  }

The number 1000 is just a guess, 512 would be the normal value if mgValue was not added or if that was small. I made no changes to the calculation of the futilityMargin, I think it may not be necessary when ei.mgValue is a substantial number and besides the Futility Margin is already widened from 300 to 350. But of course it is not highly tuned, that is not really very useful I think when other changes in the code are still pending, one should not optimize prematurely, this is one of the golden rules of chess programming. But basically there just wasn't time

I hope this enough explanation for the moment for Tord and interested parties about the changes in Glaurung 080419 Mjolnir 002, Build 4, if people can't reproduce results please do not hesitate to post here!

Regards, Eelco

[Tord Romstad]

Hi Eelco!

I posted in another thread from Jon Dart some testgames with Tord's new Glaurung creation, I think the few results show some promise.

My first results show some promise, too.

I could send all the feedback to Tord only but as Glaurung is an open source engine, I don't think, at least I hope not that Tord minds my posting a bit here, so others can do some experimenting.

Of course not. Glaurung, including any development version I send to people, is free software. Basically, this means that you are free to do exactly what you want with it, as long as you don't limit the freedom of others to do the same.

In this case I made only one small change in the code and the thought behind it is that an imperfect King Safety, a compromised king position is not always bad alone, but if you have more weaknesses in your position I think those can be exploited by the opponent because it is hard to defend multiple weaknesses, and they are likely not located in the same place if it involves things not calculated in the King Safety routine. A material deficit plus King safety problems is I think another example. I have not really studied Tord's code very much but I made a simple change from

Code: Select all

      // Finally, extract the king safety score from the 

SafetyTable[] array.
      // Add the score to the evaluation, and also to 
ei.futilityMargin.  The
      // reason for adding the king safety score to the futility 
margin is
      // that the king safety scores can sometimes be very big, 
and that
      // capturing a single attacking piece can therefore result 
in a score
      // change far bigger than the value of the captured piece.
      assert(inc < 100);
      ei.mgValue -= 34/16 * sign * Value(SafetyTable[inc]);
      if(c == p.side_to_move())
        ei.futilityMargin += Value(2 * SafetyTable[inc]);

to

Code: Select all

      // Finally, extract the king safety score from the SafetyTable[] array.
      // Add the score to the evaluation, and also to ei.futilityMargin.  The
      // reason for adding the king safety score to the futility margin is
      // that the king safety scores can sometimes be very big, and that
      // capturing a single attacking piece can therefore result in a score
      // change far bigger than the value of the captured piece.
      assert(inc < 100);
      ei.mgValue -= ((1000 - ei.mgValue) * sign * Value(SafetyTable[inc])/256);
      if(c == p.side_to_move())
        ei.futilityMargin += Value(2 * SafetyTable[inc]);
    }
  }

There are two bugs in your modified code above:

ei.mgValue is the score from white's point of view. Your code will make the king safety scores for both sides bigger when white has the advantage. This is almost certainly not what you meant. If I understand correctly what you are trying to do, you should probably multiply ei.mgValue by 'sign' (which is 1 for white and -1 for black).

The other bug is that you use ei.mgValue at an unfortunate time: This piece of code is executed twice, once for white's king and once for black's king. The first time, ei.mgValue will not contain king safety scores for either side (simply because king safety hasn't been evaluated yet). The second time, white's king safety will have been evaluated, but not black's.

The right thing to do would be to not add the king safety scores to the evaluation before the king safety for both sides have been computed. Just save the king safety values for both sides to some local variable, and add both values to ei.mgValue at the end of the function.

Tord