Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Does your program resign here? (or better: is it evaluated correctly?)

Author: Uri Blass

Date: 11:12:49 01/11/03

Go up one level in this thread


On January 11, 2003 at 13:49:47, Jeroen Noomen wrote:

>On January 11, 2003 at 11:08:54, Uri Blass wrote:
>
>
>>It is not going to demage the program strength because in 99.99% of the cases
>>the program can see immediately that there is no draw.
>
>If you have a rule, you need time to check if the rule applies or not. If in
>99,99% of the cases the answer is 'no', then why add the rule.

I think that the time that you need to find the negative answer is not a
significant time in 99.9% of the cases.

If I decide to remember the number of non blocked pawns in a variable then in
almost every case this number is bigger than 2 and remembering this number and
checking it is going to cost almost no time.

>
>>If you say that the time that is used for thinking about the problem can be used
>>better than you may be right but demaging the program strength is relative to
>>it's strength before the change.
>
>That is exactly what I mean. As a chess player I don't check at avery move
>whether I have a mate attack or not. Only when the position is such a way that
>there is a good chance of delivering mate.

Yes and the program is not going to check every time if the position is
blocked(only in cases when all the pawns or almost all the pawns are blocked).
>
>>You do not need to define all the exceptions.
>
>Then: Which ones to choose?

I did not investigate the problem but the exception should include most of the
cases when a fortress happened in practical games.

I believe that you can cover 60% of the cases in maybe less than 20%
of the code that is needed to cover all the cases but I did not investigate the
problem.

I also believe that you can try to detect fortress only in special cases(for
example a case when you see a big advantage for yourself but you do not see
improvement in the evaluation for many plies)

It is possible that in that case you need to sacrifice something to prevent
fortress so in the next iteration you can search slower but detect fortresses.

>
>>We are going to see but David Omid is going to write an article about it and I
>>believe that he implemented knowledge about a lot of fortress positions with no
>>practical demage.
>
>I think fortresses are more important in a regular chess game than the example
>given in this thread. But still: There are many of them.

I agree.
>
>>The only point that I agree is that using a lot of time for small improvement is
>>not a good thing to do for playing strength but the point is that there are
>>things that are more productive for playing strength and not that it is demaging
>>for playing strength.
>
>If the position will never occur, you do not gain in playing strength and I
>cannot call it an improvement.

I agree but fortress happens so if you can be practically 1% slower in most of
the positions to detect practical fortresses then it may be productive to
playing strength.

Uri



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.