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

Well, a strong chess player uses a good quiescence function. As in search until position quiet and evaluate.

Anything less than that is a downwards compromise based on inability to create a quiescence function that approximates it, and traditionally excused on the basis that bean-counting gives results.

I find the sidetomove bonus a kind of nonsense forced on the beancounting program as a kludge to cover its inherently problematical design.

You've heard of the concept of the coiled spring in chess? Perhaps in relation to some variations of the Sicilian. Black is forced back onto defending some weakness. But if white actually tries to do something and overextends, then, suddenly, all blacks pieces uncoil forwards from their defensive positions and white is in trouble.

My guess is that sidetomove bonus in that kind of situation is probably counterproductive.

Fact is this: the advantage of having the move is either positive, negative or neutral depending on the situation. Period.

In other words, the perfect bonus is one that is adaptive. Sometimes positive, sometimes negative. Most of eval terms are gambling terms. This is one of them. If you set it fixed to zero, you are actually wrong when it should be positive and wrong when it should be negative. You are gambling that zero will be the best compromise. So, technically, everybody has a sidetomove bonus, many of them set to 0. I really doubt that is the best number.

For instance, it is difficult to find positions in the opening in which is convenient that the opponent moves.

Miguel

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

[wgarvin]

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

Assymetric evaluation sounds risky. You might have a lot more evaluation values to tune, and it might be harder to tune them.

A single "side to move" bonus is a bit kludgy, but it lets you keep the other evaluation terms symmetric.

Would it make sense to compute a variable "side to move" bonus term which takes into account king attack, pawns, etc. but keep it separated from the main terms for those things?

[Zach Wegner]

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

Why is this distinction necessary? Why is it that adding side to move as a parameter for all evaluation terms is "correct", while the other method is not? I think you are putting constraints on the evaluation based on your experience as a human. Humans divide their conception of the position based on general concepts like king safety, but the engine doesn't have to. As a thought experiment, if I replace my evaluation with a complex table that takes in seemingly arbitrary pieces of the board representation and spits out a number, say derived from games, and the sum of these values is the evaluation, is that incorrect? It's not measuring anything in particular, but it still is an evaluation.

I think the evaluation should be made as simple as possible, while remaining robust. You should probably have a side to move term for passed pawns, as there it can make a huge difference in score, but anywhere else I don't think is necessary, at least for the type of evaluations that most people use. I don't know of any engine that evaluates king safety based on possible move sequences (except possibly you), they just give a general view of how unsafe the king is. Of course, some engines do static mate detection, but that's another subject.

Anyways, I think that if you can take all of the extremely small side-to-move-based components from the evaluation and make a nice average, you will still get mostly correct behavior while greatly reducing the complexity of the engine. And if you have side to move in the passed pawn code, and you take in to account mobility for the final bonus, I doubt the very small increase in accuracy will offset the difficulty of tuning and increased chances of bugs.

[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

Well, a strong chess player uses a good quiescence function. As in search until position quiet and evaluate.

Anything less than that is a downwards compromise based on inability to create a quiescence function that approximates it, and traditionally excused on the basis that bean-counting gives results.

I find the sidetomove bonus a kind of nonsense forced on the beancounting program as a kludge to cover its inherently problematical design.

You've heard of the concept of the coiled spring in chess? Perhaps in relation to some variations of the Sicilian. Black is forced back onto defending some weakness. But if white actually tries to do something and overextends, then, suddenly, all blacks pieces uncoil forwards from their defensive positions and white is in trouble.

My guess is that sidetomove bonus in that kind of situation is probably counterproductive.

Fact is this: the advantage of having the move is either positive, negative or neutral depending on the situation. Period.

In other words, the perfect bonus is one that is adaptive. Sometimes positive, sometimes negative. Most of eval terms are gambling terms. This is one of them. If you set it fixed to zero, you are actually wrong when it should be positive and wrong when it should be negative. You are gambling that zero will be the best compromise. So, technically, everybody has a sidetomove bonus, many of them set to 0. I really doubt that is the best number.

For instance, it is difficult to find positions in the opening in which is convenient that the opponent moves.

Miguel

Yes, I agree with you. Honestly I don't see what the fuss is all about. Every program has fixed values that do not adapt so well or not at all. If your program has piece square tables in them you are essentially hard coding values that have NO ability to adapt to changing situations. I think this is the primary mark of a beancounting program (to use Chris Whittingtons terminolgy), one that relies heavily on piece square tables to encode superficial knowledge.

[Don]

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

Why is this distinction necessary? Why is it that adding side to move as a parameter for all evaluation terms is "correct", while the other method is not? I think you are putting constraints on the evaluation based on your experience as a human. Humans divide their conception of the position based on general concepts like king safety, but the engine doesn't have to. As a thought experiment, if I replace my evaluation with a complex table that takes in seemingly arbitrary pieces of the board representation and spits out a number, say derived from games, and the sum of these values is the evaluation, is that incorrect? It's not measuring anything in particular, but it still is an evaluation.

I think the evaluation should be made as simple as possible, while remaining robust. You should probably have a side to move term for passed pawns, as there it can make a huge difference in score, but anywhere else I don't think is necessary, at least for the type of evaluations that most people use. I don't know of any engine that evaluates king safety based on possible move sequences (except possibly you), they just give a general view of how unsafe the king is. Of course, some engines do static mate detection, but that's another subject.

Anyways, I think that if you can take all of the extremely small side-to-move-based components from the evaluation and make a nice average, you will still get mostly correct behavior while greatly reducing the complexity of the engine. And if you have side to move in the passed pawn code, and you take in to account mobility for the final bonus, I doubt the very small increase in accuracy will offset the difficulty of tuning and increased chances of bugs.

I would be more swayed by Chris's arguments if I saw a really strong program that uses those ideas. Does such a program exist?

He may indeed have a real point and nobody has yet demonstrated it yet. But I have to go by the preponderance of evidence and I see that the programs that actually win games use simple stand pat bonus. But I haven't tried the Chris approach and so I don't have a good answer for him. However I can say that not doing ANYTHING is worse because my program plays better when I use the bonus. Presumably I could give up a couple of ply of search depth and do it Chris's way and in the bargain my program could make brilliant but unsound sacrifices too instead of just playing unsoundly Maybe Chris has it right, if you are going to go down in defeat, you might as well go down in a blaze of glory.

[chrisw]

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

Why is this distinction necessary? Why is it that adding side to move as a parameter for all evaluation terms is "correct", while the other method is not? I think you are putting constraints on the evaluation based on your experience as a human. Humans divide their conception of the position based on general concepts like king safety, but the engine doesn't have to. As a thought experiment, if I replace my evaluation with a complex table that takes in seemingly arbitrary pieces of the board representation and spits out a number, say derived from games, and the sum of these values is the evaluation, is that incorrect? It's not measuring anything in particular, but it still is an evaluation.

I think the evaluation should be made as simple as possible, while remaining robust. You should probably have a side to move term for passed pawns, as there it can make a huge difference in score, but anywhere else I don't think is necessary, at least for the type of evaluations that most people use. I don't know of any engine that evaluates king safety based on possible move sequences (except possibly you), they just give a general view of how unsafe the king is. Of course, some engines do static mate detection, but that's another subject.

Anyways, I think that if you can take all of the extremely small side-to-move-based components from the evaluation and make a nice average, you will still get mostly correct behavior while greatly reducing the complexity of the engine. And if you have side to move in the passed pawn code, and you take in to account mobility for the final bonus, I doubt the very small increase in accuracy will offset the difficulty of tuning and increased chances of bugs.

I would be more swayed by Chris's arguments if I saw a really strong program that uses those ideas. Does such a program exist?

He may indeed have a real point and nobody has yet demonstrated it yet. But I have to go by the preponderance of evidence and I see that the programs that actually win games use simple stand pat bonus. But I haven't tried the Chris approach and so I don't have a good answer for him. However I can say that not doing ANYTHING is worse because my program plays better when I use the bonus. Presumably I could give up a couple of ply of search depth and do it Chris's way and in the bargain my program could make brilliant but unsound sacrifices too instead of just playing unsoundly Maybe Chris has it right, if you are going to go down in defeat, you might as well go down in a blaze of glory.

Hey, this is way more fun than CTF

[Don]

Hey, this is way more fun than CTF

I never was on CTF so I'm not sure what you mean. But I didn't mean anything I said to be condescending - after looking at it again it could be interpreted that way and I'm glad you didn't take offense.

I actually admire your program for doing what it does the way it does, it's quite interesting. I realize that your goal wasn't to make it super strong but to be lots of fun and "Tal" like and you have certainly done that very well.

However, there is nothing wrong with wanting to build a strong program either, even if you feel some contempt for how it has to be done which you seem to. Having a really strong program seems to excite people as much or more than having a really fun program, although almost nobody can beat either these days.

- Don

[chrisw]

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

Why is this distinction necessary? Why is it that adding side to move as a parameter for all evaluation terms is "correct", while the other method is not? I think you are putting constraints on the evaluation based on your experience as a human. Humans divide their conception of the position based on general concepts like king safety, but the engine doesn't have to. As a thought experiment, if I replace my evaluation with a complex table that takes in seemingly arbitrary pieces of the board representation and spits out a number, say derived from games, and the sum of these values is the evaluation, is that incorrect? It's not measuring anything in particular, but it still is an evaluation.

I think the evaluation should be made as simple as possible, while remaining robust. You should probably have a side to move term for passed pawns, as there it can make a huge difference in score, but anywhere else I don't think is necessary, at least for the type of evaluations that most people use. I don't know of any engine that evaluates king safety based on possible move sequences (except possibly you), they just give a general view of how unsafe the king is. Of course, some engines do static mate detection, but that's another subject.

Anyways, I think that if you can take all of the extremely small side-to-move-based components from the evaluation and make a nice average, you will still get mostly correct behavior while greatly reducing the complexity of the engine. And if you have side to move in the passed pawn code, and you take in to account mobility for the final bonus, I doubt the very small increase in accuracy will offset the difficulty of tuning and increased chances of bugs.

Well, because the sidetomove value (if one uses one) is going to be dependant on position, the only way to know what it should be is by analysing the particular position. Since programs analyse positions chunk by chunk (to a greater or lesser degree of intelligence depending) then they would also sensibly build sidetomovebonus in likewise polynomial fashion.

I guess my argument goes like this: if one does a simple and robust evaluation (what I call bean-counting) then the sidetomovebonus is also going to be simple, robust and probably wrong in many cases. Such a program may get away with this through speed and effective search depth, indeed, as you say, simple = easier to tune and fewer bugs and and and. More complex = harder work, longer development, but quite possibly far more fun. Depends why you're writing a program, I suppose.

[chrisw]

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

Assymetric evaluation sounds risky. You might have a lot more evaluation values to tune, and it might be harder to tune them.

A single "side to move" bonus is a bit kludgy, but it lets you keep the other evaluation terms symmetric.

Would it make sense to compute a variable "side to move" bonus term which takes into account king attack, pawns, etc. but keep it separated from the main terms for those things?

Yes, writing a chess program is like wrestling a big complex monster and there is plenty of incentive to 'keep it simple'. But we have gazillions of these simple programs now. I find it more interesting both as a programming problem and also for endusers to use to mess with more complex evaluation and try and get chess knowledge into the design.

[chrisw]

Well, yes. Adaptive indeed. But this looks at the problem the wrong way round. To adapt the value requires chess knowledge. If you have a knowledge based polynomial evaluation function then you can account for sidetomove within the particular elemenst of the polynomial - rhather than add in some global value kludge at the end.

For example. Pair of bishops is worth something and sideonmove is probably unimportant.

Runningpawn evaluation - well, side on move should be taken into account there and then - could be a game winner. Pair of pawns on 5th or 6th vs Rook, again side on move very important - account for it during the sub-evaluation.

King attack - makes a big difference if on move or not. Account for it then.

Attack on piece, makes if big difference if exectuble immediately or need to wait for other side to move. Account for it there.

It's only the beancounter which has compromised away much evaluation that will be needing a global kludge value, isn't it? And will it work, be appropriate or even marginally accurate? I don't think so.

Why is this distinction necessary? Why is it that adding side to move as a parameter for all evaluation terms is "correct", while the other method is not? I think you are putting constraints on the evaluation based on your experience as a human. Humans divide their conception of the position based on general concepts like king safety, but the engine doesn't have to. As a thought experiment, if I replace my evaluation with a complex table that takes in seemingly arbitrary pieces of the board representation and spits out a number, say derived from games, and the sum of these values is the evaluation, is that incorrect? It's not measuring anything in particular, but it still is an evaluation.

I think the evaluation should be made as simple as possible, while remaining robust. You should probably have a side to move term for passed pawns, as there it can make a huge difference in score, but anywhere else I don't think is necessary, at least for the type of evaluations that most people use. I don't know of any engine that evaluates king safety based on possible move sequences (except possibly you), they just give a general view of how unsafe the king is. Of course, some engines do static mate detection, but that's another subject.

Anyways, I think that if you can take all of the extremely small side-to-move-based components from the evaluation and make a nice average, you will still get mostly correct behavior while greatly reducing the complexity of the engine. And if you have side to move in the passed pawn code, and you take in to account mobility for the final bonus, I doubt the very small increase in accuracy will offset the difficulty of tuning and increased chances of bugs.

I would be more swayed by Chris's arguments if I saw a really strong program that uses those ideas. Does such a program exist?

He may indeed have a real point and nobody has yet demonstrated it yet. But I have to go by the preponderance of evidence and I see that the programs that actually win games use simple stand pat bonus. But I haven't tried the Chris approach and so I don't have a good answer for him. However I can say that not doing ANYTHING is worse because my program plays better when I use the bonus. Presumably I could give up a couple of ply of search depth and do it Chris's way and in the bargain my program could make brilliant but unsound sacrifices too instead of just playing unsoundly Maybe Chris has it right, if you are going to go down in defeat, you might as well go down in a blaze of glory.

There are zillions of simple robust programs. They play huge tournaments with each other automated. Why keep building more or others of the same thing?

Actually I am sure that making a program speculative and also fast is possible - the key is that the programmer has, or can understand, some higher level chess concepts. Is it by accident that the Rybka programmer is IM? I'ld guess he has some knowledge chunks in there.