Improve the search or the evaluation?

[tpetzke]

Yes, probably it will.

But in my engine the move ordering is most determined by eval. If a move that is considered best with a low depth (and put at front of the list for time to come) is still considered good at higher depths means eval has guided search in the right direction.

Yes I know there are some history tricks to improve move ordering that are independent of eval but the gains you can get from that are somehow limited.

Thomas...

[hgm]

I agree that not having an eval term can be better than having the term with the wrong value but I assume that you did some tests to show that the knowledge that you have about pawn structure is productive for Joker(you do not need a lot of CPU time for it).

Actually I hardly ever did any tuning on Joker. That also holds for its piece-square tables. These were taken unmodified from Usurpator II. (And actually they are not really piece-square tables, but just square tables, as all pieces share the same table. Except Q and R, which do not use any table.

[jdart]

Most eval terms by themselves have a very small effect. That is why tuning an evaluation function is so difficult and time-consuming. If you are going to tune, IMO you should start with the big eval terms first (typically, advanced and/or connected passers, king cover/safety, rook on 7th).

Some search improvements can have a large effect. Pruning and reduction logic in particular.

In addition, I cannot over-emphasize the role of bug fixing. Practically every program has bugs and some of these may have a significant effect on strength. There is no magic for finding these but I have a lot of asserts in my codebase and have found some bugs by running debug builds with these turned on. I found some just by watching it play too and noticing things it did wrong, although that's not very scientific. Doing code review - reading your own code over or better, having someone else do it - can also be effective.

--Jon

[Steve Maughan]

Hi Jon,

[...]In addition, I cannot over-emphasize the role of bug fixing. Practically every program has bugs and some of these may have a significant effect on strength. There is no magic for finding these but I have a lot of asserts in my codebase and have found some bugs by running debug builds with these turned on. I found some just by watching it play too and noticing things it did wrong, although that's not very scientific. Doing code review - reading your own code over or better, having someone else do it - can also be effective.

I completely agree. You cannot "tune" anything until you have a mostly bug free base to start with. See my post here:

http://www.chessprogramming.net/compute ... bugs-bugs/

Steve

[JBNielsen]

I think that improving the search is more important certainly if you are at the level of 2200.

It is possible to get rating of 2500 only by search with a very simple evaluation and even at the level of stockfish it seems that most of the improvement is search improvements and not evaluation improvements.

Interesting. So everyone (without a program or) with a program below 2500 better take a copy of such a program and start improving that....