Tapered Eval

[Robert Pope]

My current code for game phase is really bulky, so I was looking at what some other programs do. I was reading a description of (I think) Rookie's evaluation, and I noticed that it was basing the game phase on the remaining pieces of the opponent, rather than all pieces. Is this common practice, or is it just as common to use all pieces?

While I was wondering about that, I wandered over to the chess programming wiki, and it appears that Fruit uses all pieces, but pawns have zero impact on the game phase. Did I read that right?

[bob]

My current code for game phase is really bulky, so I was looking at what some other programs do. I was reading a description of (I think) Rookie's evaluation, and I noticed that it was basing the game phase on the remaining pieces of the opponent, rather than all pieces. Is this common practice, or is it just as common to use all pieces?

While I was wondering about that, I wandered over to the chess programming wiki, and it appears that Fruit uses all pieces, but pawns have zero impact on the game phase. Did I read that right?

Most use total pieces. Not sure why you would just use opponent pieces, except perhaps for king safety scaling.

[matthewlai]

My current code for game phase is really bulky, so I was looking at what some other programs do. I was reading a description of (I think) Rookie's evaluation, and I noticed that it was basing the game phase on the remaining pieces of the opponent, rather than all pieces. Is this common practice, or is it just as common to use all pieces?

While I was wondering about that, I wandered over to the chess programming wiki, and it appears that Fruit uses all pieces, but pawns have zero impact on the game phase. Did I read that right?

It doesn't really matter in practice.

If there is a significant imbalance in material, the game is probably already won/lost anyways.

[bob]

My current code for game phase is really bulky, so I was looking at what some other programs do. I was reading a description of (I think) Rookie's evaluation, and I noticed that it was basing the game phase on the remaining pieces of the opponent, rather than all pieces. Is this common practice, or is it just as common to use all pieces?

While I was wondering about that, I wandered over to the chess programming wiki, and it appears that Fruit uses all pieces, but pawns have zero impact on the game phase. Did I read that right?

It doesn't really matter in practice.

If there is a significant imbalance in material, the game is probably already won/lost anyways.

It does make the resolution twice as coarse, which has a negative effect.

[Ferdy]

What do you mean by bulky?

[jdart]

I use opposing pieces as an index to the scaling factor. Pawns are not counted.

--Jon

[mvk]

My current code for game phase is really bulky, so I was looking at what some other programs do. I was reading a description of (I think) Rookie's evaluation, and I noticed that it was basing the game phase on the remaining pieces of the opponent, rather than all pieces. Is this common practice, or is it just as common to use all pieces?

While I was wondering about that, I wandered over to the chess programming wiki, and it appears that Fruit uses all pieces, but pawns have zero impact on the game phase. Did I read that right?

It is a bug to use the sum of pieces instead of opponent pieces. Think of king safety and passers. But it is a bug of the same order of magnitude as, say, worrying about opposite square colors for the bishop pair bonus: one of zero practical impact, if you consider winning or losing games. Many programs now copy the Fruit design with score tuples, and for that you need one scalar game phase. You don't need to follow.

Wether or not to ignore pawns is also rather arbitrary. The tuner will resolve any differences.

[matthewlai]

My current code for game phase is really bulky, so I was looking at what some other programs do. I was reading a description of (I think) Rookie's evaluation, and I noticed that it was basing the game phase on the remaining pieces of the opponent, rather than all pieces. Is this common practice, or is it just as common to use all pieces?

While I was wondering about that, I wandered over to the chess programming wiki, and it appears that Fruit uses all pieces, but pawns have zero impact on the game phase. Did I read that right?

It doesn't really matter in practice.

If there is a significant imbalance in material, the game is probably already won/lost anyways.

It does make the resolution twice as coarse, which has a negative effect.

The steps are also twice as big though, with every exchange.

[Robert Pope]

What do you mean by bulky?

In fruit, stage is a simple function of pieces captured. In Abbess, the stage is a lookup of the 1071 possible permutations of pieces on the board: Index=Pawns*63 + Minors*7 + Majors
so that every possible piece combination can have its own stage.

That is obviously bad, because I don't have adequate data to tune every combination. But at the same time, I disagree with a simple subtraction of pieces -- how much a Knight loss changes the phase should be different if you have only 5 pieces left than if it is in the first 5 moves. Also, you should be in 100% endgame well before you are down to K vs. K. So, I want to switch to something formula driven, but more tunable than just the parameters in Fruit.

[bob]

My current code for game phase is really bulky, so I was looking at what some other programs do. I was reading a description of (I think) Rookie's evaluation, and I noticed that it was basing the game phase on the remaining pieces of the opponent, rather than all pieces. Is this common practice, or is it just as common to use all pieces?

While I was wondering about that, I wandered over to the chess programming wiki, and it appears that Fruit uses all pieces, but pawns have zero impact on the game phase. Did I read that right?

It is a bug to use the sum of pieces instead of opponent pieces. Think of king safety and passers. But it is a bug of the same order of magnitude as, say, worrying about opposite square colors for the bishop pair bonus: one of zero practical impact, if you consider winning or losing games. Many programs now copy the Fruit design with score tuples, and for that you need one scalar game phase. You don't need to follow.

Wether or not to ignore pawns is also rather arbitrary. The tuner will resolve any differences.

Surely you don't mean a different "phase" for each side, since evaluation has to cover both sides? I don't see how this would be a "bug" at all. And doing it twice would have some computational cost.

If the piece counts are different for the two sides, I doubt the phase scaling matters much anyway, the game is already out of hand most of the time.