Here is a definition-of-easy idea. Though I have not tested it.Don wrote:What you want to see is that if a move is easy, such as the only obvious reply to a capture, the others should be cut of quickly and thus most of the time spent on this easy move. You are looking for this to reflect the move that is best. If the move is hard and many other moves are just as good or it's changing its mind frequently, you should see a lot of time spent on more than one move. Don

Perhaps someone can test it or tell me if it sounds good or bad.

Every move that is done and evaluated should get an additional value

together with its score. That value should be backed up in the search

and be written in the hash table or even in the triangular PV array.

The value should be short, like 4 bits, and in the range [0..15].

What value? An easy_value or predicted_value.

It is basically the move number in which you try the moves after they are

sorted by captures, killers, piece-square-tables and so on. But the real

number is based on the current move and its PV deeper in the tree.

Code: Select all

`easy_value = (MIN(15, move_number) + easy_value_from_deeper_pv) / 2`

If the move is the first move that comes out of the hash table you use the

stored easy_value instead of the move_number. Static evaluation counts as 0.

The effective weights of easy_values with increasing depth are

(1/2, 1/4, 1/8, 1/16, ...).

Example:

If the moves of a PV are (A, B, C, D, E, F, G) and the move numbers are

(1, 3, 2, 8, 1, 1, 4) then the easy_values are (2, 3, 3, 4, 1, 1, 2).

If the moves of a PV are (A, B, C, D_from_hash_with_easy_value_4)

and the move numbers are (10, 12, 4, 1#) then the easy_values are

(9, 8, 4, 4).

The PV in the first example was easy to find (2) and the PV in the second

example was hard to find (9).

After each iteration you have an easy_value for all the root moves and their PVs.

Harald