any tips for glaurung

[kaustubh]

I have glaurung source , can anyone give me any tips for making changes in the source.

[ernest]

I have the Kama Soutra, can anyone give me any tips for practice?

[YL84]

well, we are not a lot being able to improve glaurung! And what do you want to do with it?

[Ryan Benitez]

I have glaurung source , can anyone give me any tips for making changes in the source.

I would focus on the evaluation function. Tuning evaluation factors can take a lot of cpu time and I think this is why most programs are lacking in this area. If you come up with some good improvements please share them with Tord as I am sure he would be happy to see improvements to his evaluation function.

[Tord Romstad]

I have glaurung source , can anyone give me any tips for making changes in the source.

That's a very general question, and it is impossible to give a good answer unless you are much more specific. What are you trying to achieve? If your goal is to improve the playing strength as much as possible, the evaluation function is without a doubt the biggest weakness in the program right now. However, improving the evaluation function is not an easy task, for reasons explained in another currently active thread.

Tord

[Vempele]

1) As the others said, eval.

2) Tord will probably have better results fixing the major weaknesses (which is the right way to go, obviously), but chances are that if you work on code he's unlikely to touch, your improvements can also be used in later versions.

3) A concrete example:

Code: Select all

	  value = sort->value; // history score
      if (!in_check && depth < SearchCurrent->max_extensions /* root depth */ / 2 && node_type != NodePV 
		  && new_depth < depth && value < HistoryValue / depth&#41; // HistoryValue is 70 %
		  continue;

These lines are the sole reason Toga II 1.3.1 is about 50 points stronger than 1.2.1a (the search is otherwise unchanged; there's also a slight king safety change that only applies to uncastled kings that have castling rights). Glaurung already uses a variation of this, but with a 20% threshold (close to Toga 1.2.1a), a lower depth limit and with a minimum of 7 moves searched. I just started a test to see whether Toga's way works better. If it doesn't, there's a chance Glaurung's way works better in Toga too.

[Uri Blass]

1) As the others said, eval.

2) Tord will probably have better results fixing the major weaknesses (which is the right way to go, obviously), but chances are that if you work on code he's unlikely to touch, your improvements can also be used in later versions.

3) A concrete example:

Code: Select all

	  value = sort->value; // history score
      if (!in_check && depth < SearchCurrent->max_extensions /* root depth */ / 2 && node_type != NodePV 
		  && new_depth < depth && value < HistoryValue / depth&#41; // HistoryValue is 70 %
		  continue;

These lines are the sole reason Toga II 1.3.1 is about 50 points stronger than 1.2.1a (the search is otherwise unchanged; there's also a slight king safety change that only applies to uncastled kings that have castling rights). Glaurung already uses a variation of this, but with a 20% threshold (close to Toga 1.2.1a), a lower depth limit and with a minimum of 7 moves searched. I just started a test to see whether Toga's way works better. If it doesn't, there's a chance Glaurung's way works better in Toga too.

Can you explain what does this code mean?

I think that some explanation in english what was changed in toga can be productive because I do not like to work hours in trying to understand the code of toga only to understand what the code means and I do not like guessing when my guess may be wrong.


I also think that you should explain that you mean 50 elo not in blitz because in blitz 40/4 no version of toga is 50 elo better than toga1.2.1a
based on the ccrl list.

Uri

[Vempele]

Can you explain what does this code mean?

I think that some explanation in english what was changed in toga can be productive because I do not like to work hours in trying to understand the code of toga only to understand what the code means and I do not like guessing when my guess may be wrong.

Toga uses 3 history arrays indexed by [piece+from][to] (yes, it's a bug and not my typo). One is used for move ordering; the score of every non-tactical best move is incremented by depth*depth. The other two, HistHit and HistTot, are used for reduction and pruning decisions. Both values start out at 1, HistTot[move] is incremented every time a non-tactical move fails high and the move under consideration is non-tactical. HistHit is incremented for any non-tactical move that fails high. If HistTot reaches 16384, both values are divided by 2.

sort->value = 16384 for hash move, killers, check evasions and captures. Otherwise, sort->value = HistHit * 16384 / HistTot.

As history pruning isn't used at PV nodes (in which passed pawn pushes would be extended), new_depth < depth essentially means the move is not a check.

1.2.1a: depth <= 4 && value < (depth <= 3 ? HistoryValue / 3 : HistoryValue / 4).
1.3.1: depth <= rootdepth / 2 && value < HistoryValue / depth

The other conditions weren't changed. HistoryValue is equivaluent to 70% in both versions.

I also think that you should explain that you mean 50 elo not in blitz because in blitz 40/4 no version of toga is 50 elo better than toga1.2.1a
based on the ccrl list.

Uri

Thanks, I forgot to mention that. I wonder how it'll score in CEGT 40/120.

Incidentally, the results of the Glaurung experiment were bad.

[Uri Blass]

I do not understand what is the difference between HistTot and HistHit
if both are increcemented for every non tactical move that fail high.

I guess that HistTot is the bigger number of the 2 so probably HistHit may be increased also when the move does not fail high.

I guess that the idea is to prune moves that have small
sort->value

If I understand your explanation correctly then 1.3.1 does some pruning when the remaining
is high(more than 4)
when 1.2.1 does more pruning when the remaining depth is 2 or 1.

Uri

[Vempele]

I do not understand what is the difference between HistTot and HistHit

Sorry for not being clear.

HistTot = the number of times the move has been tried and been non-tactical and a non-tactical move failed high.
HistHit = the number of times the move has failed high and been non-tactical.

Therefore, you can think of sort->value as the fail high percentage of the move.

I guess that the idea is to prune moves that have small
sort->value

Correct.

If I understand your explanation correctly then 1.3.1 does some pruning when the remaining
is high(more than 4)
when 1.2.1 does more pruning when the remaining depth is 2 or 1.

1.3.1 prunes more at any remaining depth with the exception depths 3 and 4 and early iterations. In 1.2.1, the threshold is 23.33% at depths 1-3 and 17.5% at depth 4. In 1.3.1, the thresholds are 70%, 35%, 23.33%, 17.5%, 14% etc.