Tuning again

[Rebel]

Eval tuning I strictly do at fixed depth. I don't want external factors like time control or permanent brain to interfere. Enough volume will flatten all the horizon effects eventually, both sides.

IMHO the main drawbacks are: impossible to test depth sensible stuff like king safety and artificial same depth for midgame and endgame. But I agree for some evaluation parameters could be good, actually I will give it a try.

For self-play-ply-depth testing I am planning the following:

1. introduce a special parameter for internal testing;
2. when the flag is on increase the depth with 1 when queens are exchanged;
3. depth+2 entering the endgame
4. depth+5 entering the simple endgame

Or something like that.

[Desperado]

Eval tuning I strictly do at fixed depth. I don't want external factors like time control or permanent brain to interfere. Enough volume will flatten all the horizon effects eventually, both sides.

IMHO the main drawbacks are: impossible to test depth sensible stuff like king safety and artificial same depth for midgame and endgame. But I agree for some evaluation parameters could be good, actually I will give it a try.

For self-play-ply-depth testing I am planning the following:

1. introduce a special parameter for internal testing;
2. when the flag is on increase the depth with 1 when queens are exchanged;
3. depth+2 entering the endgame
4. depth+5 entering the simple endgame

Or something like that.

Reading this, i ask myself why not making the depth sensitive to the
material phase values in general, when using fix-depth matches ?

Having an array useFixDepth[phaseValue] = depth ...
For late endgames the depth can easily be 2x or even 3x bigger than
for middlegame positions, and would be continious getting bigger.
(similar behaviour like in time-based games, or similar like
time/move then ?!)

eg: fullboard -> depth 8 or 9 and pawnEnding ending maybe 16.

just an idea...

Michael

[lkaufman]

Eval tuning I strictly do at fixed depth. I don't want external factors like time control or permanent brain to interfere. Enough volume will flatten all the horizon effects eventually, both sides.

IMHO the main drawbacks are: impossible to test depth sensible stuff like king safety and artificial same depth for midgame and endgame. But I agree for some evaluation parameters could be good, actually I will give it a try.

For self-play-ply-depth testing I am planning the following:

1. introduce a special parameter for internal testing;
2. when the flag is on increase the depth with 1 when queens are exchanged;
3. depth+2 entering the endgame
4. depth+5 entering the simple endgame

Or something like that.

That is pretty much a description of the way I did all the eval testing for Rybka 3!

[michiguel]

Eval tuning I strictly do at fixed depth. I don't want external factors like time control or permanent brain to interfere. Enough volume will flatten all the horizon effects eventually, both sides.

IMHO the main drawbacks are: impossible to test depth sensible stuff like king safety and artificial same depth for midgame and endgame. But I agree for some evaluation parameters could be good, actually I will give it a try.

For self-play-ply-depth testing I am planning the following:

1. introduce a special parameter for internal testing;
2. when the flag is on increase the depth with 1 when queens are exchanged;
3. depth+2 entering the endgame
4. depth+5 entering the simple endgame

Or something like that.

I limit my search by nodes and I have been happy thereafter. I enthusiastically recommend it.

Miguel

[lkaufman]

[quote="michiguel
I limit my search by nodes and I have been happy thereafter. I enthusiastically recommend it.

Miguel[/quote]

Do you quit after N nodes, or make some effort to finish the iteration? The first way is more "fair", while the second way plays better chess.

[BubbaTough]

Do you quit after N nodes, or make some effort to finish the iteration? The first way is more "fair", while the second way plays better chess.

I think when tuning, being fair is more important . I also do some tuning limiting via nodes, heavily influenced by Miguel. It has a benefit over time limitations of allowing easily comparable results gathered on different machines, with things running in the background, etc.).

-Sam

[hgm]

1. introduce a special parameter for internal testing;
2. when the flag is on increase the depth with 1 when queens are exchanged;
3. depth+2 entering the endgame
4. depth+5 entering the simple endgame

That was how Usurpator II did it in the eighties! I had not learned the blessings of iterative deepening yet, in those days.

[hgm]

Do you quit after N nodes, or make some effort to finish the iteration? The first way is more "fair", while the second way plays better chess.

WinBoard supports a mode where you can play any type of TC on a node-count basis. Not just fixed max time per move. So you can have the best of both worlds: fair and yet efficient.

[Rein Halbersma]

Code: Select all

{  
   { 
       { 
           {
           }
       }
   }
}

Things like that drives me crazy

Mee too The problem here is the excessive indentation level more than the brackets in itself.

From http://kerneltrap.org/files/Jeremy/CodingStyle.txt:

"Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

[Rebel]

I limit my search by nodes and I have been happy thereafter. I enthusiastically recommend it.

Excellent to test search issues, eval IMO by fixed depth. Knowledge vs Knowledge not influenced by search randomness.