dynamically modified evaluation function

[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.

I'm pessimistic about the idea myself, but I'm not eager to blow it off with a wave of the hand either. I would not have a very strong program if I made a habit of doing that.

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.

I can well imagine that many chess authors are very anal about their code, but I had to get over that a long time ago. You cannot write a strong program if you are afraid of doing something that is not (technically) correct, such as accepting GHI issues, search instabilities, evaluation functions that are a wild guess and not based on reality, LMR that often throws out the best move, null move selectivity based on playing an illegal move in the search, etc...

[Michael Sherwin]

How exactly does Romi chess use this idea?

Romi has two history tables:

One for LMR that is [type, fs, ts] with a short cycle.

One for the eval that is [type, ts] with a long cycle.

I better just go grab some code.

In the search

if(++evalHistTbln[fig][ts] > 200000) {
evalHistTbln[fig][ts] /= 2;
evalHistTblg[fig][ts] /= 2;
}

if(score > alpha) {

evalHistTblg[fig][ts] += 40;

Then in the eval initialization for the white bishop pst:

...
g = evalHistTblg[WB][sq]; n = evalHistTbln[WB][sq];
wBishopTbl[sq] += (n > 99 ? g/n/2 : 0);

This is simplistic, but, it helps Romi. I am sure that the idea can be improved upon.

[Daniel Shawul]

I'm pessimistic about the idea myself, but I'm not eager to blow it off with a wave of the hand either. I would not have a very strong program if I made a habit of doing that.

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

Please stop making assumptions about my cause. I am pessimistic with reason form the beginning and just that...nothing more nothing less.
You asked for opinions, I pointed out how severe the search instability could be ,which btw no one mentioned before I did. I call that a contribution to the discussion. Also, unreliability of history data is sort of common knowledge now. You can use log(sin(atan(H[from][to]))) and is still unreliable.. that is why fruit's way of doing LMR with history ratio did not work as expected.

Hmm.. you have a strong engine. yes I get it. Whats this got to do with anything ?
This is getting a bit childish. Can't you stick the topic at hand rather than implying how the other party can't do experiments because of your presumed pessimisim blah blah

Reasonable Pessimism is a good thing too, like optimism is

[Michael Sherwin]

Since we are on a secondary topic of history tables I will mention something else that I posted about concerning them. I started to test this idea, but was distracted and never got back to it.

For LMR/LMP and perhaps move ordering two history tables should be maintained. One long cycle and one short cycle. For LMR/LMP they both must agree that the search should be shortened. This should help isolate local inconsistencies.

[Don]

I'm pessimistic about the idea myself, but I'm not eager to blow it off with a wave of the hand either. I would not have a very strong program if I made a habit of doing that.

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

Please stop making assumptions about my cause. I am pessimistic with reason form the beginning and just that...nothing more nothing less.
You asked for opinions, I pointed out how severe the search instability could be ,which btw no one mentioned before I did. I call that a contribution to the discussion. Also, unreliability of history data is sort of common knowledge now. You can use log(sin(atan(H[from][to]))) and is still unreliable.. that is why fruit's way of doing LMR with history ratio did not work as expected.

Hmm.. you have a strong engine. yes I get it. Whats this got to do with anything ?
This is getting a bit childish. Can't you stick the topic at hand rather than implying how the other party can't do experiments because of your presumed pessimisim blah blah

Reasonable Pessimism is a good thing too, like optimism is

Sorry, I tend to react strongly to critical people. Most people think all criticism is constructive, but most criticism that we see today is negative and counter productive. However true constructive criticism is a different thing altogether.

I've been involved with people all my life who were what I call "no" people. There answer to every question or idea is "No, it won't work" or "No you can't do it." Much easier to say no than yes and much easier to criticize than to have actual ideas (or solutions.) I can tell you everything that is wrong with the world today, but do you think that is actually constructive? It's constructive only if it is followed up with a solution or ideas.

So forgive me if I cast you in that light, it was not my intent but the tone of it reminds me of the negativity I feel like I have often dealt with in my business life.

[Houdini]

Then in the eval initialization for the white bishop pst:

...
g = evalHistTblg[WB][sq]; n = evalHistTbln[WB][sq];
wBishopTbl[sq] += (n > 99 ? g/n/2 : 0);

This is simplistic, but, it helps Romi. I am sure that the idea can be improved upon.

That's quite interesting.
What is the the "eval initialization", a routine you run once at the start of the search, or at the start of each iteration?

[Michael Sherwin]

Here is something else that is loosely related to history tables that is very interesting and may be useful for feedback. My first working chess code was in 8086 assembler. It could not castle, cep or promote. It was a material only search that also kept the total beta cutoffs for each move. It would choose its move as the move with the highest count of cutoffs from the best material scores. You would not think that it would make very good looking moves, but, the moves it made were very surreal and quite good. It could not search as deep as CM5000, although it could give it a good game. Once it lasted for 65 moves (130 ply) and had a winning advantage at one point before loosing the end game. Very interesting! I've always wanted to explore that further.

[Michael Sherwin]

Then in the eval initialization for the white bishop pst:

...
g = evalHistTblg[WB][sq]; n = evalHistTbln[WB][sq];
wBishopTbl[sq] += (n > 99 ? g/n/2 : 0);

This is simplistic, but, it helps Romi. I am sure that the idea can be improved upon.

That's quite interesting.
What is the the "eval initialization", a routine you run once at the start of the search, or at the start of each iteration?

I construct the pst for every iteration at ply 0 and at ply one. The initialization done is the constructing of the pst.

[Houdini]

I construct the pst for every iteration at ply 0 and at ply one. The initialization done is the constructing of the pst.

Mike, thanks, I'm going to try the idea sometime in the future.
Really interesting...

[Michael Sherwin]

Here is something else that is loosely related to history tables that is very interesting and may be useful for feedback. My first working chess code was in 8086 assembler. It could not castle, cep or promote. It was a material only search that also kept the total beta cutoffs for each move. It would choose its move as the move with the highest count of cutoffs from the best material scores. You would not think that it would make very good looking moves, but, the moves it made were very surreal and quite good. It could not search as deep as CM5000, although it could give it a good game. Once it lasted for 65 moves (130 ply) and had a winning advantage at one point before loosing the end game. Very interesting! I've always wanted to explore that further.

I just remembered that I counted the total beta cutoffs for both sides did something to normalize the values and then subtracted the opponents to arrive at the final value. It has been too long ago to be any more exact.