How to tune the bonus for having the move.

[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

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

It's not relevent to your original question, the assumption that "nobody uses a good quiesence function nowadays", maybe you do and maybe you don't but the question of the best value of a sidetomove bonus would be answered by me on a philosophical basis and on general terms first, and not by restriction to what is the best sidetomove bonus for a modern beancounting program. If the later, don't know, don't care, there isn't going to be a bestbonus anyway, just a horrible kludge that couldn't possibly cover the situations that arise.

It depends on what can be done by the move advantage.

a) deliver mate - infinite value
b) grab a piece for free - value of piece
c) grab a pawn for free - value of pawn
d) push a freepawn - worth something probably, depending on how much material on board, where the king is
f) make a threat - depends, might be worth something
g) continue developing, worth something, depends on whether true ot not
h) if can't do anything constructive, then likely worth nothing or even negative
i) start undoing a perfect position - negative
j) in zugswang - more negative

even with a quiescence funcgtion that picks some of that stuff up, it may be good to have the move in varying degrees of good, or it may be bad, again in varying degrees.

So, I'ld just like to suggest that averaging out over a bunch of positions without trying to go deeper into the problem first is a bit not terribly useful and suggested instead grading the bonus against material left on the board, just for starters.

Chris

[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

[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

It's not relevent to your original question, the assumption that "nobody uses a good quiesence function nowadays", maybe you do and maybe you don't but the question of the best value of a sidetomove bonus would be answered by me on a philosophical basis and on general terms first, and not by restriction to what is the best sidetomove bonus for a modern beancounting program. If the later, don't know, don't care, there isn't going to be a bestbonus anyway, just a horrible kludge that couldn't possibly cover the situations that arise.

It depends on what can be done by the move advantage.

a) deliver mate - infinite value
b) grab a piece for free - value of piece
c) grab a pawn for free - value of pawn
d) push a freepawn - worth something probably, depending on how much material on board, where the king is
f) make a threat - depends, might be worth something
g) continue developing, worth something, depends on whether true ot not
h) if can't do anything constructive, then likely worth nothing or even negative
i) start undoing a perfect position - negative
j) in zugswang - more negative

even with a quiescence funcgtion that picks some of that stuff up, it may be good to have the move in varying degrees of good, or it may be bad, again in varying degrees.

So, I'ld just like to suggest that averaging out over a bunch of positions without trying to go deeper into the problem first is a bit not terribly useful and suggested instead grading the bonus against material left on the board, just for starters.

Chris

Ok, what good quies function do you suggest when you said, "not if you use a good quies function?" Are you being philosophical or did you have something specifically in mind? What should this good quies function do that will solve this problem?

[Pradu]

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

I don't have side to move bonus in Buzz but I just added it for this test. I have scores that scale from opening to endgame and I added the side to move bonus only to the opening phase score. Here are my results in terms of nodes for a bench function which runs through various positions to a certain depth:

Code: Select all

BONUS    NODES
-----   -------
 0.00   4553545
 0.05   4291223
 0.10   4214400
 0.15   4179914
 0.20   4134929
 0.21   3980747
 0.22   3978110
 0.23   4191948
 0.25   4732318
 0.30   4474580

I quit testing it by time because I'd saw that I'd have to make good number of runs to get a reliable time estimate:

Code: Select all

Times are in milliseconds
Bounus   0.00    0.05    0.10    0.15    0.20
Trial 0 17515   15704   15421   15470   15109
Trial 1 17375   15374   15610   15796   15405
Trial 2 16907   15593   15564   15297   14923
Trial 3 17063   15797   15391   15391   15141
Trial 4 17797   15453   15406   15485   14953
Trial 5 17484   15578   15283   15719   15438
Trial 6 17202   15532   15579   15422   14876
Trial 7 17000   15765   15422   15251   15092
Trial 8 17078   15579   15234   15467   15124
Trial 9 17062   15390   15344   15813   15249
AVG     17248   15576   15425   15511   15131
SD        283     147     126     199     190
SEM        90      46      40      62      60

[bob]

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?

with the current version, 5 centipawns (0.05). This might change after revisions to the evaluation, who knows... but this scored best for us in testing...

[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

It's not relevent to your original question, the assumption that "nobody uses a good quiesence function nowadays", maybe you do and maybe you don't but the question of the best value of a sidetomove bonus would be answered by me on a philosophical basis and on general terms first, and not by restriction to what is the best sidetomove bonus for a modern beancounting program. If the later, don't know, don't care, there isn't going to be a bestbonus anyway, just a horrible kludge that couldn't possibly cover the situations that arise.

It depends on what can be done by the move advantage.

a) deliver mate - infinite value
b) grab a piece for free - value of piece
c) grab a pawn for free - value of pawn
d) push a freepawn - worth something probably, depending on how much material on board, where the king is
f) make a threat - depends, might be worth something
g) continue developing, worth something, depends on whether true ot not
h) if can't do anything constructive, then likely worth nothing or even negative
i) start undoing a perfect position - negative
j) in zugswang - more negative

even with a quiescence funcgtion that picks some of that stuff up, it may be good to have the move in varying degrees of good, or it may be bad, again in varying degrees.

So, I'ld just like to suggest that averaging out over a bunch of positions without trying to go deeper into the problem first is a bit not terribly useful and suggested instead grading the bonus against material left on the board, just for starters.

Chris

Chris,

Breaking this up into middle game and end game with a transition between them (which is all the rage now) is a good idea.

I'm not sure you understand what the bonus is for. Let me explain it to you so that we are talking the same language.

Sometimes having the move can lead to checkmate or the win of material as you say, that is true. But we are relying on the quies search for things like this. Having the move bonus doesn't try to cover that. It also doesn't cover the case where one side is on the attack and the other side is defending - what is often called a "time" advantage. The search detects this pretty much and will play attacking style just to keep the opponent busy so that he cannot improve his position. Chess program are pretty good at this and the stand pat bonus doesn't try to know this.

The stand pat bonus is only a device to compensate programs for that abrupt stopping point. At some point you have to stop the search and it's just plain silly to get a slightly higher score for the color that you happened to stop on. It's not just silly, but it weakens the play slightly and makes the search slower. It makes the search slower because a few hash table moves which work on odd ply searches will not work on even ply searches. This can apply to killers too. Stand Pat Bonus doesn't solve this or prevent it, but it does minimize it.

[michiguel]

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.

Quick and dirty test:
Gaviota, 134 positions (Dann Corbit's "silent but deadly"), depth = 6

Code: Select all

 Bonus    Tree size  
(Pawns)  (relative, %)

 0/32      100.0
 1/32       94.2
 2/32       92.4
 3/32       90.1
 4/32       92.0
 5/32       93.9
 6/32       96.2

3/32 pawns seems to be optimal (my granularity is 1/256 pawns but I did not go to test that). This is similar to your results (0.10 pawns).
This way of testing is really interesting. I wonder what would happen with other terms.

Miguel

[rjgibert]

Quick and dirty test:
Gaviota, 134 positions (Dann Corbit's "silent but deadly"), depth = 6

Code: Select all

 Bonus    Tree size  
(Pawns)  (relative, %)

 0/32      100.0
 1/32       94.2
 2/32       92.4
 3/32       90.1
 4/32       92.0
 5/32       93.9
 6/32       96.2

3/32 pawns seems to be optimal (my granularity is 1/256 pawns but I did not go to test that). This is similar to your results (0.10 pawns).
This way of testing is really interesting. I wonder what would happen with other terms.

Using an online multiple regression app

http://www.shodor.org/chemviz/tools/multireg/index.html

to produce a quadratic approximation polynomial, I determined by extrapolation that 27/256 seems to be the optimal value for your program. FYI FWIW

[Michael Sherwin]

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

Here is RomiChess's 'fast and stupid' quies.

Code: Select all

s32 CaptSearch(s32 alpha, s32 beta) {
  s32 score;
  s32 Ply;
  trees *node;

  qnodes++;
  Ply = ply - base;
  score = Eval();
  if(score - 60 >= beta) return beta;
  if(InCheck(wtm)) score -= 80;
  if(score + 20 >= beta) return beta;
  if(CaptGen()) return MATE - Ply;
  if(t == h->t) return score;
  if(score > alpha) alpha = score;
  for(node = h->t; node < (h+1)->t; node++) {
    Sort(node, (h+1)->t);
    MakeMove((moves *)&node->m);
    node->score = -CaptSearch(-beta, -alpha);
    TakeBack();
    if(node->score > alpha) {
      if(node->score >= beta) return beta;
      alpha = node->score;
    }
  }
  return alpha;
}

So, this is where a variable bonus of up to 20cp is used. Just enough to bring the score up to beta and no more. This is just to save time by allowing the standpat score to cause more 'stupid' quies searches not to be done. Best by test!

[Don]

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

Quick and dirty test:
Gaviota, 134 positions (Dann Corbit's "silent but deadly"), depth = 6

Code: Select all

 Bonus    Tree size  
(Pawns)  (relative, %)

 0/32      100.0
 1/32       94.2
 2/32       92.4
 3/32       90.1
 4/32       92.0
 5/32       93.9
 6/32       96.2

3/32 pawns seems to be optimal (my granularity is 1/256 pawns but I did not go to test that). This is similar to your results (0.10 pawns).
This way of testing is really interesting. I wonder what would happen with other terms.

Miguel

I believe a general principle is that chess evaluation functions are like turbulence behind a fast car. You are not going to increase the performance by lowering the horsepower, but you can increase the performance if you improve the air flow characteristics around the car to minimize wind resistance.

So you can't improve the performance by removing necessary evaluation features (lowering the horsepower) but you want your evaluation terms to cooperate with each other and not "compete." A step in this direction was first formulated by Hans Berliner many years ago when he said evaluations functions should be smooth and gradual to the extent possible. The popular way to implement this idea these days is to have 2 evaluation functions but gradually transition from one to the other as the game proceeds.

I saw a post or something where someone layed out some general principles for designing evaluation functions (was it Tord?) and I think he got it exactly right. For one thing redundant evaluation terms was mentioned and he said this was not good. I think this is correct because redundant terms (at least ones that overlap badly) tend to step all over each other and give your evaluation function jagged edges which is not good for improving the drag coefficient!

Has anyone ever noticed this phenomenon: You make some evaluation change to your program and it suddenly it requires more nodes to achieve the same depth of search and it also plays weaker at the same depth? This is like a wind tunnel test. I don't think you should take this analogy too far though ... sometimes an important change does improve the program AND while slowing down the search a little. But if it fails the wind tunnel test you should at least look a little deeper into what is going on.