Big ELO jump for weak playing engines only

[Henk]

If you think you have alpha beta search and null move reduction working what would be the next step that increases ELO significantly ?

Actually I assume here that ID and IID and TT table are working correctly too.

[hgm]

Evaluation terms that cover the most important aspects of Chess.

Important is to look why the engine loses against opponents that it on the average scores 50% against. (And why it bungles won positions to a draw.) This will tell you the comperatively weakest spots.

E.g. when I was developing micro-Max the early versions lost a lot of games against TSCP because of initiating bad trades like piece for 3 Pawns or 2 Knights for Rook + Pawn. This obvious pointed to wrong piece values.

After I corrected that it kept loosing because it allowed TSCP to march his Pawns to 6th and 7th rank unhindred, from where they sooner or later promoted. Even without full passer detection and evaluation this could be prevented by evaluating a Pawn on 6th rank as ~1.7, and a Pawn on 7th rank as 2.5 Pawn.

Another weakness was that it drew many games where it had an advantage, by failing to push his Pawns forward. Increasing the Pawn-push bonus did not solve it, because it would then throw them foreward too enthousiastically in the opening, leaving his King without Pawn shield. But increasing the bonus with the amount of captured material (a primitive idea of game phase) solved that problem.

Of course repetition detection was even more basic; without that it hardly mattered what I would improve, as it would almost never win anyway. Virtually all games where it had a winning advantage would end in a repetition draw.

An engine is like a boat. As long as it has holes, it will sink. Plugging the holes makes little difference when there are still other holes: it just takes longer to sink, but the result eventually will be the same. So it is difficult to say how much plugging a certain hole will gain you; it depends a lot on which other holes you still have.

[Henk]

Evaluation terms that cover the most important aspects of Chess.

Important is to look why the engine loses against opponents that it on the average scores 50% against. (And why it bungles won positions to a draw.) This will tell you the comperatively weakest spots.

E.g. when I was developing micro-Max the early versions lost a lot of games against TSCP because of initiating bad trades like piece for 3 Pawns or 2 Knights for Rook + Pawn. This obvious pointed to wrong piece values.

After I corrected that it kept loosing because it allowed TSCP to march his Pawns to 6th and 7th rank unhindred, from where they sooner or later promoted. Even without full passer detection and evaluation this could be prevented by evaluating a Pawn on 6th rank as ~1.7, and a Pawn on 7th rank as 2.5 Pawn.

Another weakness was that it drew many games where it had an advantage, by failing to push his Pawns forward. Increasing the Pawn-push bonus did not solve it, because it would then throw them foreward too enthousiastically in the opening, leaving his King without Pawn shield. But increasing the bonus with the amount of captured material (a primitive idea of game phase) solved that problem.

Of course repetition detection was even more basic; without that it hardly mattered what I would improve, as it would almost never win anyway. Virtually all games where it had a winning advantage would end in a repetition draw.

An engine is like a boat. As long as it has holes, it will sink. Plugging the holes makes little difference when there are still other holes: it just takes longer to sink, but the result eventually will be the same. So it is difficult to say how much plugging a certain hole will gain you; it depends a lot on which other holes you still have.

So you suggest improve evaluation: Material values,Passes pawns, Pawn shield

And repetition detection.

[hgm]

Indeed, repetition detection is crucial. When I made improvements that seemed clearly working when I watched the games (i.e. it was not doing these stupid things anymore that I intended to cure), there still wasn't much improvement in the overall score. Once it got ahead it just kept falling in the repetition trap.

[Roger Zuehlsdorf]

For my engine ChessBrainVB (see forum General Topics) I had a similiar question:
How to add 1000 ELO to a 1500 ELO starting point (LarsenVB)?

The big ELO jumps came from (in order of ELO increase):
- add Hash Tables
- add Reduction logic similiar to SF6
- add King Safety logic similiar to SF6
- add Passed Pawn logic similiar to SF6
- optimize move ordering (detect pawn threats, king attacks)
- add 3x Draw Repitition detection during search root only before)
- optimize time management (especially important for 40/4m games)
- better eval: Threats, Pawn Structure, Material draw detection

Finally I reached the 2500 ELO I needed to convert the engine to the 15 times slower interpreted OfficeVBA with about 1950 ELO.

Hope this helps,
Roger

[jhellis3]

LMR

[tttony]

I was facing the same problem, I added a SearchRoot and Aspiration the engine became really weak, so I decided to just stay for now with a simple AlphaBeta search, I've added LMR --> http://www.glaurungchess.com/lmr.html and the elo jump is big, like 100+

[flok]

Indeed, repetition detection is crucial. When I made improvements that seemed clearly working when I watched the games (i.e. it was not doing these stupid things anymore that I intended to cure), there still wasn't much improvement in the overall score. Once it got ahead it just kept falling in the repetition trap.

But aren't repetitions not caught by the transposition table?

Or should I do the following:

- calc hash for current color, look that up in the tt

- if no tt hit, calc the hash for the opponent color; look that up in the history table. if there's a hit, don't do that node (return -infinite?)

[hgm]

If there is a TT hit, it doesn't follow that there is no repetition.

The normal procedure is that you calculate the hash key of the position after any move you want to search, and then compare that key with all nodes in the current branch with that same side to move since the last irreversible move. I.e. if the current node is at ply N, the move will lead to ply N+1, and you compare its key with the saved one for ply N-1, N-3, N-5 etc. If there is a match, the position is a repetition, and you score it as 0 without actually making or searching it.

There is an alternative that does use the hash table, which I use in KingSlayer/Simple: each time you enter a node you do a hash probe. If it is a hit, but for some reason not usable, (wrong bounds, or depth too low), you copy the entry (as some of the info in it, such as the move, would always be useful). You then create an entry for the node with 'exact' score 0 and maximum depth, and that will stay in there as long as you have not returned from that node. Because of the high depth and exact bound type it will always cause a hash cutoff when you encounter it again, returning the 0 score. In the mean time you update in the node itself the copy of the hash entry with any information the search of it gathers (e.g. each IID iteration you remember best move, score, depth and bound type there). When you leave the node you copy that info back to the hash table, overwriting the temporary draw entry you had made there with real search info.

This method is not usable in combination with SMP search, however, as other threads would use the same hash table, and would see a draw for nodes not in their own path but in the path of one of the other threads. This could be cured by having a dedicated bit for each thread in the hash table to flag a node is in the path of that thread, and test for that bit. But that would sort of destroy the idea, as it would require extra space for the flags (in every hash entry, while perhaps only 30 entries per thread would have it set), and an extra test of that bit in the hash probe.