important ideas in chess programming

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Uri Blass
Posts: 10282
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

important ideas in chess programming

Post by Uri Blass »

I think that it can be good to summarize the ideas first(with no source code).

I think that it is better if we agree that there should be evaluation ideas and search ideas and move generation ideas that everybody agree that they are free to use(meaning that people who read the ideas and try to implement them are not going to be accused of cloning or having non original code).

I am afraid that most programmers miss some important ideas and it is the reason that they fail to get to level that is close to the clones because I believe that they should start at level that is close to the clones(not more than 100 elo weaker) if they implement all the important ideas(because small changes in the evaluation usually do not change the playing strength significantly so I do not think that tuning to have the exact optimal value
is especially important).

I do not claim to know all the ideas
summary of part of the evaluation ideas that I know that are probably worth more than 10 elo points(I did not include king safety evaluation that is also important).


1)The evaluation should be an average between opening evaluation and endgame evaluation that is dependent on the stage of the game.
In endgame evaluation the value of passed pawns should be relatively bigger and the value of pawns should be relatively bigger.

2)mobility evaluation of a piece can be based on the number of the squares that the piece can go into them.

3)The value of additional square for knight or bishop is bigger than the value of additional square for rook or queen.

4)There should be a bonus for passed pawn based on the rank of the pawn(bigger bonus for more advanced passed pawn)

5)There should be a penalty for weak pawns(pawns that cannot be defended by a pawn that can include also passed pawns).

6)There should be a bonus for a passed pawn that is protected by a pawn and again bigger bonus for advanced protected passed pawns.

7)There should be piece square table evaluation that encourage knights
to be at the centre and encourage pawns to go forward and encourage the king to go to the middle of the board in the endgame and not to go forward in the opening).

I did not add more ideas and after the decision that rybka is not original code I am afraid that if somebody is going to start from a list of many of the important ideas people are going to complain that it is not original
so we need to have accepted ideas that everybody agree that every programmer can read them and start from them without being quilty of non original code.

It may be interesting to have some ordered list of ideas together with some estimate for the value of every idea in rating points(and of course the value of an idea in rating points is dependent on ideas that the programmer implemented earlier in the program).
jdart
Posts: 4366
Joined: Fri Mar 10, 2006 5:23 am
Location: http://www.arasanchess.org

Re: important ideas in chess programming

Post by jdart »

Most of these eval ideas are very old (maybe that is your point).

I think quite a few were in Gnuchess version 4, circa 2000.

But most strong engines now benefit from other more recent changes: recursive null pruning, LMR, late move pruning and/or history pruning, incremental move generation, material imbalance scoring, to name a few.

Without these features an engine is going to be fairly weak (by modern standards) even if it has a fairly good eval, IMO.

--Jon
Uri Blass
Posts: 10282
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: important ideas in chess programming

Post by Uri Blass »

jdart wrote:Most of these eval ideas are very old (maybe that is your point).

I think quite a few were in Gnuchess version 4, circa 2000.

But most strong engines now benefit from other more recent changes: recursive null pruning, LMR, late move pruning and/or history pruning, incremental move generation, material imbalance scoring, to name a few.

Without these features an engine is going to be fairly weak (by modern standards) even if it has a fairly good eval, IMO.

--Jon
I did not mention specific search ideas and of course recursive null move pruning and LMR and late move pruning are important ideas but I decided not to mention them because I felt that some explanation of the algorithm is needed(about the conditions) and I prefered not to write much in the first post and only to start a discussion.

I am not sure about the importance of other ideas
that you mention.

It is not clear if history pruning gives much based on what I read
and I remember reading that there are strong programs that do not use history pruning.

It is also not clear for me if incremental move generation gives much in order to consider it as important idea and I wonder how much speed improvement programmers get from it(I never tried it because I dislike losing information for speed and I have some use for knowing the exact number of legal moves later in the search for example for my decision if to try or not to try null move pruning)

For material imbalance scoring it is also not clear to me if it is an important idea because you can usually avoid bad trades by having correct value for pieces (bishop and knight something near 3.5 pawns,rook something between 5 and 5.5 pawns and queen something near 10 pawns).
jdart
Posts: 4366
Joined: Fri Mar 10, 2006 5:23 am
Location: http://www.arasanchess.org

Re: important ideas in chess programming

Post by jdart »

For material imbalance scoring it is also not clear to me if it is an important idea because you can usually avoid bad trades by having correct value for pieces
I used to think this too and in version 12.2 of Arasan I actually did remove the trade scoring I had but that did not perform well, so I re-introduced a term that encourages trading pieces not pawns when ahead material, and also some special-case adjustments for specific material configurations. Without these factors it would regularly play into inferior endgames.

--Jon