How to tune the bonus for having the move.

[Don]

I noticed that some people have suggested that a "having the move bonus" is beneficial to their program. I believe that too and have always used one in my programs. How to set it correctly seems to be a bit of a black art, but I have a suggestion that I would like others to try and report back.

You should start with a large timing test set. I use 100 positions to measure the general effects of performance tuning on my program. This is not a "find the solution" set, it is just a set of random positions from games to measure general search speed, node counts, etc, and I don't care what move is returned.

The basic idea is to TIME your program using various stand pat bonuses. The theory is that the most correct values will produce the fastest searches because there will be less "turbulence" in move choices, odd/even scores, etc. All of these things hurt the search.

It's just a theory I admit, but I tried it and I get reasonable values. Since the values are reasonable and you are just guessing anyway, why not use the values that produce the fastest search?

My program is very new and has a very primitive evaluation function that is not aggressive at all about positional values - so I would thus expect the stand pat bonus needed to be relatively low. That's what I get here, a value of 0.10 works best of the ones I tried. Here are the times for my 100 position timing set at various stand pat bonus values:

Code: Select all

BONUS   AVE TIME      AVE NODES
-----   --------      ---------  
 0.00      5.312      3,443,479
 0.05      4.734      3,119,767
 0.10      4.247      2,780,342
 0.15      4.692      2,938,563
 0.20      4.684      2,901,375
 0.30      5.862      3,310,455

[/color]

As you can see, 0.10 appears to be best for me right now. 0.15 and 0.20 are non-optimal and I put 0.30 to get one that is obviously wrong but not totally ridiculous.

I would be curious about the results others get with such a test.

[Tony]

I don't think the tempo bonus for a chess program is the same as a tempo for humans.

For humans, the lost of a tempo means the other side gets more developed/active pieces. But because this is to complicated for humans we call this tempo.

A chessprogram however scores this with its mobility factor, and has no need for this. If the mobility didn't rise with the extra move, then it wasn't a tempo gain/loss.

It needs this bonus only to make a difference between 2 positions were the pieces are on the same squares, but only stm differs. If you don't have this bonus, the engine will try to hang on the same position for a ply longer. ( Kind of a miniature horizon effect)

Tony

[rjgibert]

In how many of those 100 positions is the side to move in check? How many are endings where zugzwang may be a factor? How many are closed positions? I would expect that any of the above would "depress" the value of the tempo bonus.

BTW, it might be interesting to determine what the optimal tempo bonus should be for each individual position in the test to see if there are any interesting patterns that could be used to make the tempo bonus system smarter.

[Don]

I don't think the tempo bonus for a chess program is the same as a tempo for humans.

For humans, the lost of a tempo means the other side gets more developed/active pieces. But because this is to complicated for humans we call this tempo.

A chessprogram however scores this with its mobility factor, and has no need for this. If the mobility didn't rise with the extra move, then it wasn't a tempo gain/loss.

It needs this bonus only to make a difference between 2 positions were the pieces are on the same squares, but only stm differs. If you don't have this bonus, the engine will try to hang on the same position for a ply longer. ( Kind of a miniature horizon effect)

Tony

I agree with you on this. Programs already measure, to an extent, the actual value of a tempo when one side is on the defensive for instance and in small positional ways that is usually the case. For instance my program knows that white has the advantage if you search the opening position, whether there is a bonus or not. The stand pat bonus only attempts to smooth out the odd/even difference by compensating for the fact that the static evaluation function doesn't know that whoever has the move, is likely to make a move that slightly increases it's score. The bonus should be half of whatever that something is ideally.

[Don]

In how many of those 100 positions is the side to move in check? How many are endings where zugzwang may be a factor? How many are closed positions? I would expect that any of the above would "depress" the value of the tempo bonus.

BTW, it might be interesting to determine what the optimal tempo bonus should be for each individual position in the test to see if there are any interesting patterns that could be used to make the tempo bonus system smarter.

My testing set is not very complete, I just use 100 of the opening positions that I use for auto-testing. These positions are all exactly 10 ply deep into the game, so it's probably not perfect for this and certainly doesn't have huge variety. At some point I will generate a more comprehensive set with positions from all stages of the middlegame.

I forgot to mention that right now I cut the stand pat bonus in half for the endgame - and this value is arbitrary. It could be "calibrated" using the same method I suggest here of course, assuming this is sound.

I like your idea of testing various types of positions individually and looking for common patterns to improve on this.

I have another idea of making this adaptive. As the game progresses just monitor the odd/even differnences in the highest 2 plys completed and use this value for the next search. There are some problems with this however. First of all, the odd/even differences are influenced by the values you are already using, but you could figure that into the calculation. The other problem is that this could have a negative effect on the hash tables, assuming you do not clear them between searches (which I don't) and I think most people don't. You would also have to deal with tactical shots that would skew the results and so on. Probably simple is to force the delta of change to move very slowly.

Usually stuff like this isn't worth obsessing over, I'm just throwing out some ideas!

[Harald Johnsen]

I had the impression that the stm bonus is there so that the engine stop doing waiting moves. Then a value of 1 cp should be enought (or the value of your grain).

If you use *big* values then you will surely have to face problems or at least have some side effect when doing null moves (because the score is changing a lot ie 2*tempo).

I have not (yet) a stm bonus in my engine because I don't know how to verify the effect on play. I think that counting node of time is irrelevant here, what is important is the progress made in the position.

HJ.

[chrisw]

I noticed that some people have suggested that a "having the move bonus" is beneficial to their program. I believe that too and have always used one in my programs. How to set it correctly seems to be a bit of a black art, but I have a suggestion that I would like others to try and report back.

You should start with a large timing test set. I use 100 positions to measure the general effects of performance tuning on my program. This is not a "find the solution" set, it is just a set of random positions from games to measure general search speed, node counts, etc, and I don't care what move is returned.

The basic idea is to TIME your program using various stand pat bonuses. The theory is that the most correct values will produce the fastest searches because there will be less "turbulence" in move choices, odd/even scores, etc. All of these things hurt the search.

It's just a theory I admit, but I tried it and I get reasonable values. Since the values are reasonable and you are just guessing anyway, why not use the values that produce the fastest search?

My program is very new and has a very primitive evaluation function that is not aggressive at all about positional values - so I would thus expect the stand pat bonus needed to be relatively low. That's what I get here, a value of 0.10 works best of the ones I tried. Here are the times for my 100 position timing set at various stand pat bonus values:

Code: Select all

BONUS   AVE TIME      AVE NODES
-----   --------      ---------  
 0.00      5.312      3,443,479
 0.05      4.734      3,119,767
 0.10      4.247      2,780,342
 0.15      4.692      2,938,563
 0.20      4.684      2,901,375
 0.30      5.862      3,310,455

[/color]

As you can see, 0.10 appears to be best for me right now. 0.15 and 0.20 are non-optimal and I put 0.30 to get one that is obviously wrong but not totally ridiculous.

I would be curious about the results others get with such a test.

with a good quiescence function it ought not to matter too much. With a lousy quiesence function it will matter a lot, but also vary massively depending on position.

There's no reason why tuning on search time reduction is going to optimise for strength, is there? You might try tuning on either a huge test set, or on speed to find actual move chosen by winning side in a set of high-ELO games.

So, assuming you have good quiescence, I would be inclined to suggest also modifying your idea for the sidetomovebonus by pieces left on the board. KQRBN different to KRBN etc

[bob]

I noticed that some people have suggested that a "having the move bonus" is beneficial to their program. I believe that too and have always used one in my programs. How to set it correctly seems to be a bit of a black art, but I have a suggestion that I would like others to try and report back.

You should start with a large timing test set. I use 100 positions to measure the general effects of performance tuning on my program. This is not a "find the solution" set, it is just a set of random positions from games to measure general search speed, node counts, etc, and I don't care what move is returned.

The basic idea is to TIME your program using various stand pat bonuses. The theory is that the most correct values will produce the fastest searches because there will be less "turbulence" in move choices, odd/even scores, etc. All of these things hurt the search.

It's just a theory I admit, but I tried it and I get reasonable values. Since the values are reasonable and you are just guessing anyway, why not use the values that produce the fastest search?

My program is very new and has a very primitive evaluation function that is not aggressive at all about positional values - so I would thus expect the stand pat bonus needed to be relatively low. That's what I get here, a value of 0.10 works best of the ones I tried. Here are the times for my 100 position timing set at various stand pat bonus values:

Code: Select all

BONUS   AVE TIME      AVE NODES
-----   --------      ---------  
 0.00      5.312      3,443,479
 0.05      4.734      3,119,767
 0.10      4.247      2,780,342
 0.15      4.692      2,938,563
 0.20      4.684      2,901,375
 0.30      5.862      3,310,455

[/color]

As you can see, 0.10 appears to be best for me right now. 0.15 and 0.20 are non-optimal and I put 0.30 to get one that is obviously wrong but not totally ridiculous.

I would be curious about the results others get with such a test.

I do not believe that the size of the tree is a dependent variable related to "goodness of evaluation". Just remove passed pawn and king safety bonuses and the tree size will shrink due to less "turbulence"...

I have tested this in a different way, namely by playing some 500,000 games against 5 different opponents, varying the score by significant amounts to find the right area, then varying the score by smaller amounts to fine-tune... We did this last year in Crafty...

[Don]

I noticed that some people have suggested that a "having the move bonus" is beneficial to their program. I believe that too and have always used one in my programs. How to set it correctly seems to be a bit of a black art, but I have a suggestion that I would like others to try and report back.

You should start with a large timing test set. I use 100 positions to measure the general effects of performance tuning on my program. This is not a "find the solution" set, it is just a set of random positions from games to measure general search speed, node counts, etc, and I don't care what move is returned.

The basic idea is to TIME your program using various stand pat bonuses. The theory is that the most correct values will produce the fastest searches because there will be less "turbulence" in move choices, odd/even scores, etc. All of these things hurt the search.

It's just a theory I admit, but I tried it and I get reasonable values. Since the values are reasonable and you are just guessing anyway, why not use the values that produce the fastest search?

My program is very new and has a very primitive evaluation function that is not aggressive at all about positional values - so I would thus expect the stand pat bonus needed to be relatively low. That's what I get here, a value of 0.10 works best of the ones I tried. Here are the times for my 100 position timing set at various stand pat bonus values:

Code: Select all

BONUS   AVE TIME      AVE NODES
-----   --------      ---------  
 0.00      5.312      3,443,479
 0.05      4.734      3,119,767
 0.10      4.247      2,780,342
 0.15      4.692      2,938,563
 0.20      4.684      2,901,375
 0.30      5.862      3,310,455

[/color]

As you can see, 0.10 appears to be best for me right now. 0.15 and 0.20 are non-optimal and I put 0.30 to get one that is obviously wrong but not totally ridiculous.

I would be curious about the results others get with such a test.

with a good quiescence function it ought not to matter too much. With a lousy quiesence function it will matter a lot, but also vary massively depending on position.

There's no reason why tuning on search time reduction is going to optimise for strength, is there? You might try tuning on either a huge test set, or on speed to find actual move chosen by winning side in a set of high-ELO games.

So, assuming you have good quiescence, I would be inclined to suggest also modifying your idea for the sidetomovebonus by pieces left on the board. KQRBN different to KRBN etc

Who uses a good quiescence function now days? The biggest development over the past few years is to make the quies fast and stupid so if you are right, then it does matter. I don't know of any evaluation function that smooths out positional scores.

- Don

[Onno Garms]

I have tested this in a different way, namely by playing some 500,000 games against 5 different opponents, varying the score by significant amounts to find the right area, then varying the score by smaller amounts to fine-tune... We did this last year in Crafty...

Which value did you find to be optimal?