dynamically modified evaluation function

[Daniel Shawul]

To give you some perspective, all these 'inventions' based on the history
idea are done after Fruit's success with them. Then it was belivied it was
a crucial factor, and many authors have tried to use different formulas and use them for all
sorts of crazy things. Reductions, prunings & evaluation as well... Michael's experiments
for LMP and now Eval are also carried out in that time range.

I ,on the other hand, did not use history from the start as I never believed they were that important.
Later experiments showed that they were not that important infact prompting the change of name
from history reductions to late move reductions. History is not such a reliable data to begin with as evidenced
by the failure of the pruning and reduction ideas which seem to work as good or even better without it.
So by being pessimistic here, I saved some time that can be used elsewhere
My suggestion : don't use history use something else.

[Michael Sherwin]

To give you some perspective, all these 'inventions' based on the history
idea are done after Fruit's success with them. Then it was belivied it was
a crucial factor, and many authors have tried to use different formulas and use them for all
sorts of crazy things. Reductions, prunings & evaluation as well... Michael's experiments
for LMP and now Eval are also carried out in that time range.

I ,on the other hand, did not use history from the start as I never believed they were that important.
Later experiments showed that they were not that important infact prompting the change of name
from history reductions to late move reductions. History is not such a reliable data to begin with as evidenced
by the failure of the pruning and reduction ideas which seem to work as good or even better without it.
So by being pessimistic here, I saved some time that can be used elsewhere
My suggestion : don't use history use something else.

I am also one of the first to post that history tables were useless! I got rid of them from RomiChess. I also did an experiment with Fruit 2.1 where I got rid of the history tables after which Fruit 2.1 did no worse. That was before Bob dropped them from crafty. I also posted two other conclusions at that time. I posted that the only extension that is proven to be of any use was the check extension. Bob later removed some extensions from Crafty. I also said that a lot of ideas were left in programs just because they seem like good ideas that did not seem to hurt. I said that that was a bad idea. Bob came to both conclusions at a later date. I can go on with more examples if needed. The point is is that I have been ahead of the curve on a lot of things, all by my self.

So, why are the history tables back in RomiChess? Because, they work in RomiChess for LMR. And they work in RomiChess for feedback to the eval. I have tried dozens of times to get rid of them over the last several years, on account of, that I am still suspicious of them also. However, every attempt to get rid of them left me with an engine that was not as good! So, to imply that they are in my engine just, because, they are in Fruit and that I do not know what I am doing or I am just a copycat, is being an idiot. I thought that you were better than that! I know that you are better than that. So, I am going to believe that I misinterpreted what you posted!

[Michael Sherwin]

To give you some perspective, all these 'inventions' based on the history
idea are done after Fruit's success with them. Then it was belivied it was
a crucial factor, and many authors have tried to use different formulas and use them for all
sorts of crazy things. Reductions, prunings & evaluation as well... Michael's experiments
for LMP and now Eval are also carried out in that time range.

I ,on the other hand, did not use history from the start as I never believed they were that important.
Later experiments showed that they were not that important infact prompting the change of name
from history reductions to late move reductions. History is not such a reliable data to begin with as evidenced
by the failure of the pruning and reduction ideas which seem to work as good or even better without it.
So by being pessimistic here, I saved some time that can be used elsewhere
My suggestion : don't use history use something else.

I am also one of the first to post that history tables were useless! I got rid of them from RomiChess. I also did an experiment with Fruit 2.1 where I got rid of the history tables after which Fruit 2.1 did no worse. That was before Bob dropped them from crafty. I also posted two other conclusions at that time. I posted that the only extension that is proven to be of any use was the check extension. Bob later removed some extensions from Crafty. I also said that a lot of ideas were left in programs just because they seem like good ideas that did not seem to hurt. I said that that was a bad idea. Bob came to both conclusions at a later date. I can go on with more examples if needed. The point is is that I have been ahead of the curve on a lot of things, all by my self.

So, why are the history tables back in RomiChess? Because, they work in RomiChess for LMR. And they work in RomiChess for feedback to the eval. I have tried dozens of times to get rid of them over the last several years, on account of, that I am still suspicious of them also. However, every attempt to get rid of them left me with an engine that was not as good! So, to imply that they are in my engine just, because, they are in Fruit and that I do not know what I am doing or I am just a copycat, is being an idiot. I thought that you were better than that! I know that you are better than that. So, I am going to believe that I misinterpreted what you posted!

I regret making that reply. It is not your fault. It is this place. There are a lot of ugly people here towards the top that constantly leave a bad feeling in ones soul. I know that you are one of the 'good guys' so lets just forget it!

[Michael Sherwin]

Maybe there is something that I do different in my history tables than what Fruit did. Fruit scaled back the whole history table at once diluting all entries, even the ones that had few entries, iirc. That seemed bad to me, so, I only scale back one entry at a time. I use the full [type][fs][ts] for LMR. I don't believe that Fruit is that way. My threshold is very low, < 12% to trigger a reduction. An entry must also be an increase over the static eval as well as increase alpha. Maybe it works for me, for a good reason, just maybe!

[Daniel Shawul]

Don't worry Mike. All the nice people here have a sense of humor
I didn't even want to mention your name , if I was not cornered to point where I am supposed to feel like a shameless pessimist. Apology is mine.

Anyway, I strongly agree with you that many experiments on the LMR have been done before crafty started using them. I also hope to get a piece of the cake too with the "in pv reduction" and "no history data " . You know ,lately the inventions of these kind of things have been smartly being awarded to people I don't know in the past No paper,source or even forum post. I really don't like this at all. I guess people like it better if it is credited to someone unknown.. History reductions were sole property of glaurung/fruit... nobody uses history now... and suddenly its credit went to the 70's.

So in short, I appreciate your effort and standing to them as much as you can.

cheers

[Don]

To give you some perspective, all these 'inventions' based on the history
idea are done after Fruit's success with them. Then it was belivied it was
a crucial factor, and many authors have tried to use different formulas and use them for all
sorts of crazy things. Reductions, prunings & evaluation as well... Michael's experiments
for LMP and now Eval are also carried out in that time range.

I ,on the other hand, did not use history from the start as I never believed they were that important.
Later experiments showed that they were not that important infact prompting the change of name
from history reductions to late move reductions. History is not such a reliable data to begin with as evidenced
by the failure of the pruning and reduction ideas which seem to work as good or even better without it.
So by being pessimistic here, I saved some time that can be used elsewhere
My suggestion : don't use history use something else.

I think this comes down to human nature. If the best idea in the world is implemented and people are not ready for it, or it is not demonstrated in the number 1 world class program, people tend to discount it. Then some program gets to number one and even the bad idea in it become "the thing to do." And when that happens it's almost like they put a patent on it and get all the credit for the idea.

[SuneF]

I am also one of the first to post that history tables were useless! I got rid of them from RomiChess. I also did an experiment with Fruit 2.1 where I got rid of the history tables after which Fruit 2.1 did no worse. That was before Bob dropped them from crafty. I also posted two other conclusions at that time.

I don't think history tables are useless, but it is certainly possible to have a sub-optimal implementation of them.
One problem with them is that they saturate very fast, ie. become noise so that all the valuable information is just averaged out.

I posted that the only extension that is proven to be of any use was the check extension. Bob later removed some extensions from Crafty.

That's because you guys started doing full-ply extensions. Of course not much works if has to be extended a full-ply.

[SuneF]

It's silly that the search instability idea was used almost like a proof that the idea is no good. (It may be no good, but not for this reason.)

Wrong. History information is unreliable in the first place. LMR gains you a tad more than history does. The search instability is acceptable there like null move's is.
Now you pick on something that is very doubtful, add a search instablility like i never seen before, and expect it to work. Don't be surprized if some people are pessimistic about it.

The "potential" in the idea is the concept that evaluation is unreliable and history is more reliable (or less unreliable if you prefer.)

This is more than just tactics in my opinion. Obviously a move is usually bad if placed on a square where it is left hanging, but there are many evaluation concepts that are based on future tactics such as weak pawns, king safety, trapped pieces, and so on. History might capture this in a way that is especially appropriate to the local situation.

This path dependency of the eval is very nasty stuff. It will more or less break the hashing resulting in a lot of researching. And it probably gets worse the deeper you search.

I once tried draw detection heuristics of this kind, iirc the idea was that if alpha > 0 and we are repeating our side position, then evaluate as draw. This broke the hash pretty badly and it started detecting every tiny shuffle as a draw.

It seems that it is ok to let the search use information from the eval, but to let the eval use information from the search is very dangerous.

Sadly the hash really prevents a lot of interesting heuristics from working. Think how easy it would be to detect fortresses by simple "no progress" evaluation terms if we got rid of the hash.

[Don]

I am also one of the first to post that history tables were useless! I got rid of them from RomiChess. I also did an experiment with Fruit 2.1 where I got rid of the history tables after which Fruit 2.1 did no worse. That was before Bob dropped them from crafty. I also posted two other conclusions at that time.

I don't think history tables are useless, but it is certainly possible to have a sub-optimal implementation of them.
One problem with them is that they saturate very fast, ie. become noise so that all the valuable information is just averaged out.

I posted that the only extension that is proven to be of any use was the check extension. Bob later removed some extensions from Crafty.

That's because you guys started doing full-ply extensions. Of course not much works if has to be extended a full-ply.

My program responds dramatically to history tables, and move extensions. We have certain capture extensions that are worth a surprising amount of ELO as tested by tens of thousands of games.

I've never understood why some people have such a distaste for history tables, but embrace the killer move heuristic. These 2 ideas are fundamentally the same.

On the other hand I am prejudiced against null move, an algorithm that I feel is far uglier than history. History can do no damage, it's just advisory but null move is based on inserting an illegal move into the game tree, embracing zugzwang problems and other such ugliness. Nevertheless, I still have to use it because it works.

In order of ugliness, killer moves and history is not even on the list, these are powerful statistical concepts. GHI and null move is at the top of the ugly list.

[Don]

It's silly that the search instability idea was used almost like a proof that the idea is no good. (It may be no good, but not for this reason.)

Wrong. History information is unreliable in the first place. LMR gains you a tad more than history does. The search instability is acceptable there like null move's is.
Now you pick on something that is very doubtful, add a search instablility like i never seen before, and expect it to work. Don't be surprized if some people are pessimistic about it.

The "potential" in the idea is the concept that evaluation is unreliable and history is more reliable (or less unreliable if you prefer.)

This is more than just tactics in my opinion. Obviously a move is usually bad if placed on a square where it is left hanging, but there are many evaluation concepts that are based on future tactics such as weak pawns, king safety, trapped pieces, and so on. History might capture this in a way that is especially appropriate to the local situation.

This path dependency of the eval is very nasty stuff. It will more or less break the hashing resulting in a lot of researching. And it probably gets worse the deeper you search.

I once tried draw detection heuristics of this kind, iirc the idea was that if alpha > 0 and we are repeating our side position, then evaluate as draw. This broke the hash pretty badly and it started detecting every tiny shuffle as a draw.

It seems that it is ok to let the search use information from the eval, but to let the eval use information from the search is very dangerous.

Sadly the hash really prevents a lot of interesting heuristics from working. Think how easy it would be to detect fortresses by simple "no progress" evaluation terms if we got rid of the hash.

You might be right, but I would have to try this for myself.

One big problem I see is that it might simply slow down the search too much. The "ideal" move ordering would change from iteration to iteration.


A simple test is to try making random modifications of evaluation function weights (or the piece square tables) between iterations and see how it affects things.