Author: Christophe Theron
Date: 11:10:50 03/17/02
Go up one level in this thread
On March 17, 2002 at 10:53:38, Uri Blass wrote:
(snip)
>>That's good enough as a first step. You can build a reasonably strong chess
>>program with PSTs. It gives you a reasonably good evaluation (assumig your PSTs
>>are OK) and you can focus earlier on most important things.
>
>I think that evaluating pawn structure is also important and can
>give my program more than 50 elo improvement.
Definitely. I forgot to mention this, for me it was obvious.
So I rephrase: you can build a reasonably strong chess program even if your
evaluation has just pawn structure and PST.
The next thing to add will be evaluation of passed pawns. It is not part of
"pawn structure" because by pawn structure I mean evaluation of the position of
pawns relative to each other without looking at any other piece.
Evaluation of passed pawns requires to take into account the position of
non-pawns.
>I saw often in games against gnu chess that my program had problems with
>it's pawn structure.
>
>>
>>
>>
>>
>>>It can be improved by better order of moves and it can be also improved by
>>>better extension and pruning rules(it is using only some futility pruning today
>>>and it does not use partial extensions)
>>
>>
>>Chess Tiger does not use fractional extensions either. I just use more detailed
>>rules for extensions and I decide to extend or not. That's 1 or 0.
>
>I suspect that it may be a question of definition.
>
>Suppose you have 2 sets of moves that you may extend A and B.
>
>suppose you always extend 1 ply when you see a move from A
>suppose also that you always extend 1 ply when you see a move from set B
>and the total number of moves from set B in the line that you search
>is divisble by 3
>
>You can say that you always extend 1 ply or 0 plies but it is still
>the same as fractional extensions
>(1/3 ply for moves from set B and 1 ply for move for moves from set A).
>
>I think to do it as only 1 or 0 or -1 but the number is going to be based
>on fractional extensions.
>
>Today it is only 1 or 0 and the 1 is not based on fractional extensions.
I see your point. My decision algorithms for extensions do take into account the
history (the line leading to the current position), so it's fractional in
essence.
>>> but inspite of all the problems the
>>>latest version could beat Faile with no book 6-4 in a match(time control was 1
>>>minute/40 moves,2 minutes/40 moves...5 minutes/40 moves)
>>>
>>>It also lost 8.5-1.5 in a match against GNUchess5.03 in the same conditions.
>>>hardware was one pIII800.
>>>
>>>I believe that Faile and Gnuchess used hash tables in the matches(I told them no
>>>instruction about it but usually programs with hash tables use some hash tables
>>>by the default option)
>>
>>
>>Some advices for you:
>>
>>1) play fast games, manually, preferably on slow hardware. So the mistakes of
>>your program do not get hidden in very long PVs and you can more easily
>>understand what went wrong.
>
>Most of the games that I play are fast games.
>I also use test suites for testing changes that I do in search rules.
>
>
>>
>>2) Select an opponent only slightly stronger than your program. If your opponent
>>is too strong you learn almost nothing because both your evaluation and search
>>get badly beaten. You are just disgusted by the result and do not know what to
>>do. When you have improved, change to a stronger opponent.
>
>I do it.
>>
>>3) You'll soon discover that whatever you add in your evaluation, if your
>>opponent oursearches you there is nothing you can do: you lose. You will
>>probably have to spend months or even years improving your search algorithms in
>>order to avoid this. That's why I think that a PST program is OK to start with.
>>Don't make the mistake to try to add special cases in your evaluation in order
>>to cover your search's deficiencies. If you want you can add terms to evaluate
>>the tactical pressure on each side (couting the number of attacks for example),
>>but these terms must be kept general. Don't add code like "if black rook in a8
>>and black king in e8 and white knight on c7 then add penalty to black score".
>>That does not work.
>>
>>4) Don't try to fix a weakness as soon as you discover it. Just say "that's
>>life". Fix it only if it happens over and over again. Generally, start by fixing
>>the most obvious and big mistakes. Don't try to stuff in high level knowledge
>>too early in your developpement. You can't run if you do not even know how to
>>walk. This point is the reason why I believe that being a very strong chess
>>player is a handicap for a chess programmer (at least in the begining).
>
>I think that knowledge in the search is more important
>then knowledge in the evaluation so I am not going to do it
>in the near future.
I think you are on the right track.
>>5) Make a backup of your sources at least every day.
>
>I am going to do it but not every day but only after
>every significant change in my source code or significant improvement.
That's a mistake. You'll come across cases where your program is suddenly
broken, but you do not remember what you have changed.
That's why a daily backup is so important.
But you'll find out by yourself... :)
Christophe
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.