Material Tables and Indexing

[Edsel Apostol]

I thought that search makes the engine play actively or passively. For example, if I reduce too much, the engine plays more speculative, it means more active but prone to lose more often.

Maybe that's why my engine is still not that strong. I will just try to make a solid search and an aggressive eval then, instead of an aggressive search and a solid eval.

[Dann Corbit]

I thought that search makes the engine play actively or passively. For example, if I reduce too much, the engine plays more speculative, it means more active but prone to lose more often.

Maybe that's why my engine is still not that strong. I will just try to make a solid search and an aggressive eval then, instead of an aggressive search and a solid eval.

T20080404x is quite strong. It looks pretty good here:
http://www.husvankempen.de/nunn/phpBB2/ ... b62cafe0a8

Although UFIM cleaned your clock.

[CThinker]

I thought that search makes the engine play actively or passively. For example, if I reduce too much, the engine plays more speculative, it means more active but prone to lose more often.

Maybe that's why my engine is still not that strong. I will just try to make a solid search and an aggressive eval then, instead of an aggressive search and a solid eval.

In the end, what eval says is a good score is what the search will pick.

In Thinker, what people consider as 'interesting' plays, are artifacts of a number of peculiar eval behavior.

For one, Thinker does not cap positional scores. It is, for example, possible to have more than 3 points of positional score. This means that the engine thinks that it is OK to be behind by 3 pawns as long as most of its pieces are mobile but the opponent's pieces are not.

Second, Thinker does not evaluate material balances. It is OK for the engine to trade materially equivalent pieces (e.g., a bishop or knight for 3 pawns). The absence of such complex code (and other complex/exotic) evaluation code, results in a small/compact code, and allows Thinker to get into interesting positions.

Third, Thinker gives a lot of bonuses for what I think are 'aggressive' behavior . An example of this, is a big bonus for the affinity of the King to the opponent's King. This causes the King to actually "attack" the opponent. This can easily backfire, as the King could end-up in the open or forego castling. But it is quite a sight to behold.

[Edsel Apostol]

Hi Dann,

The latest betas are much stronger. Some of them could already reach 40%+ against Spike 1.2 in blitz in slow hardware using Noomen Test Suite 2007 as opening suite.

The latest release version has a too aggressive pruning and has a bug in the search concerning hash table cut-offs.

Twisted Logic will exact revenge soon.

[Edsel Apostol]

Your giving me a lot of ideas Lance. A lot of other programmer's might be please to read this revelations also.

I have used Thinker as a sparring partner. It was indeed a sight to behold it sacrificing material for king attacks making my engine thinks it is ahead but after a few moves it was already mated. I replaced it with a weaker opponent though as it is too strong for my engine.

Good Luck to Thinker then. Hope someday it would catch up or surpass Rybka.

[Onno Garms]

I think the latter is a necessary prerequisite before the former statement can be anything but an unfounded guess.

We really should do some verification of the usefulness of material imbalance tables before we bother to think over an implementation.

But I would not really consider it a fair test if the very obvious Chess lore that virtually any engine has, such as that the Bishop pair is a significant advantage (but not worth a full Pawn), and that KBK and KNK are draw, would get lost , because the current Strelka relies for their implementation entirely on the material tables.

And the piece base values must of course be chosen such a that B or N > 3P, and N+N > R+P.

You are absolutely right. Would you accept the following procedure as a fair test?

- dump piece_bonus
- fit a linear regression in terms of Q, R, B, N, and BB through the table piece_bonus
- in initialization, replace piece_bonus by the values from linear regression
- dump pairs of pawn bonus (as in function calc) and phase, use mean of white's and black's pawn value
- fit a linear regression though the pawn values in terms of phase
- use result of regression as new pawn bonus
- keep Material[] with above modifications, keep recog_draw

Above steps reduce Material[] to the usual evaluation by Q, R, B, N, and bishop pair, and different pawn values in opening and endgame.

Keep or do not keep recog_osob. This contains some imbalance data for endgame, which is much more endgame knowledge then found in other engines and hard to implement without material tables. (I would run four tests: with and without osob, with and without above reduction.)

Btw: What does the word "osob" mean?

The problem with this approach is that some material differences occur more often then others and should have greater weight in the regression. Unfortunately determination of such weights would require extensive analysis of a game database.

I still think that this test is better then merely assigning "reasonable" material values to the pieces. The latter would require to analyse how the pieces affect other terms of the evaluation. Without having computed the regression yet, I assume that the bishop value must be much smaller then the knight value in Material[] because the bishop gets more points for mobility on average.

One more question on Material[] in Strelka: There is a strange modification in the function calc_material if the correction term is smaller then 2000 (5/8 pawn). First, calc is divided by 8, then a bonus for the bishop pair is added.

1. Is the division by 8 from Rybka or was it added in Strelka? (The second is clearly commented as added in Strelka.)
2. Did anybody examine the effect of these modifications on the playing strength?
3. Can you imagine a reason why the first modification could be useful? (The second modification might be useful as a fix for the damage by the first one.)
These modifications do not fit into the plan that I described above. I hope I can run the tests without them.