Author: Christophe Theron
Date: 13:47:28 02/26/01
Go up one level in this thread
On February 26, 2001 at 13:18:15, Uri Blass wrote:
>On February 26, 2001 at 13:01:15, Christophe Theron wrote:
>
>>On February 26, 2001 at 08:09:24, Frank Phillips wrote:
>>
>>>On February 25, 2001 at 12:33:45, Christophe Theron wrote:
>>>
>>
>>(snip)
>>
>>>>
>>>>Here is the way I see this matter: there are some programs that SUCK if they are
>>>>not run on the fastest computers available.
>>>>
>>>>Saying that they need faster hardware to exploit their full possibilities is
>>>>just an excuse to hide the very poor performances on more standard hardware.
>>>>
>>>>I'm not saying here that it is the case of Gandalf or Chess System Tal. I don't
>>>>own these programs, and I have not seen enough games to give an opinion.
>>>>
>>>>Look: in a chess game, when it is your turn to move, you have the choice
>>>>between, say, a dozen moves that do not lose immediately.
>>>>
>>>>The more you think on the position, the more moves you are going to discard
>>>>because you can see with more time that they lead to bad positions.
>>>>
>>>>After a good while you are left with 2 or 3 playable moves. Choosing between
>>>>them is a matter of taste, or a matter of "playing style", and thinking more
>>>>about it is just going to be a waste of time.
>>>>
>>>>If a program is not able to see deep enough, and evaluate correctly, then if it
>>>>is not given enough time it will from time to time play a bad move and lose.
>>>>Then it is no surprise that, given enough time or enough processor power, even
>>>>poor programs are able to reach the point where they have successfully discarded
>>>>the bad moves and are left with the very few moves that are playable.
>>>>
>>>>And so it is no surprise that these inferior programs are able to compete with
>>>>much better ones only when you use very slow time controls or very very fast
>>>>computers. The best program is able to reach very quickly the point where only
>>>>playable moves are identified, and all the extra time is not going to help it
>>>>(it's like flipping a coin to decide which move amongst the 2 or 3 left you are
>>>>going to play). The other program is going to need much more time, but it does
>>>>not matter as anyway it has been given enough time or processor resources.
>>>>
>>>>If the number of possible moves in chess was higher, this effect would be less
>>>>obvious.
>>>>
>>>>That's an attempt to explain the so called "dimishing returns" in computer
>>>>chess.
>>>>
>>>>You can go even further and imagine what could happen if programs are given an
>>>>"almost" infinite time. They do not need high chess knowledge anymore. They just
>>>>need to know the basic rules and to be able to identify a checkmate when it
>>>>happens, because given enough time you can see all the forced lines from the
>>>>beginning to the end of the game. Then would you say that a program with almost
>>>>no chess knowledge is as good as one with a lot of knowledge just because, given
>>>>enough time, they are almost equal?
>>>>
>>>>Certainly not.
>>>>
>>>>Now you understand why I always find extremely doubtful the claims that a given
>>>>program needs longer time controls or more processor power in order to achieve
>>>>its full strength. It is either not true (people claiming this have not played
>>>>enough games to demonstrate their point), or it is true and in this case it
>>>>simply shows that the program in question SUCKS.
>>>>
>>>>
>>>>
>>>> Christophe
>>>
>>>This is an interesting and valuable, but I need the main points explaining more
>>>simply. The following comments illustrate my confusion (and are in no way
>>>intended to counter what has been said):
>>>
>>>The game ends in mate. So all the general rules of thumb (chess knowledge) are
>>>useless compared to this type of absolute knowledge determined by search (or
>>>EGTBs).
>>>
>>>General knowledge is secondary to specific knowledge in a position eg weak pawns
>>>versus losing a queen to a tactic revealed by search.
>>>
>>>Knowledge presumably takes cpu cycles to process, so faster machines help?
>>>
>>>If we had 32 man EGTBs, there would be absolute knowledge, no search and no
>>>chess rule of thumb knowledge of the type discussed.
>>>
>>>Presumably chess knowledge just encapsulates guiding principles for those
>>>position, which if we had enough searching power (or EGTB) we could prove were
>>>won, lost or drawn.
>>>
>>>My program sucks on both fast and slow hardware. I do not know enough about
>>>chess to add knowledge and the relationship between the various bits of
>>>knowledge it contains to deliberately make it better, although I add whatever
>>>rules of thumb I can find to try to guide the search away from positional
>>>aspects considered by others to usually be bad into good position.
>>>
>>>We will have the one move searcher when Eugene generates the 32 man EGTB. Until
>>>then I firmly suspect that searching deeper will help. As may more and more
>>>knowledge. Both of which benefit from faster machines. I fail to see why better
>>>means better on only slow machines or better on only fast machines. Presumably
>>>it is a balance in utilising available resources to maximise results.
>>>
>>>Frank
>>
>>
>>Searching deeper always help. I just want to say that the difference between a
>>program with a lot of knowledge and a program with less knowledge is more
>>obvious at fast time controls or on slow processors.
>>
>>At very long time controls, or on very fast computers, the difference between
>>the two programs is less and less obvious, because the number of available moves
>>in chess is somewhat limited, and given enough time even a bad program will be
>>able to discard all the bad moves and will be left with the 2 or 3 moves that
>>are playable.
>>
>>The very extreme example is a program that would be allowed to search very deep
>>with a very simple evaluation function. It would play at an incredible level,
>>not because it understands chess, but because it can discard all the inferior
>>moves and will always be left with good moves.
>>
>>That's why I say that the best programs are the one that are able to win at any
>>time controls. These programs are superior to the ones that need long time
>>controls or fast computers.
>>
>>I would even add that playing at faster and faster time controls is a way to
>>determine which programs are superior.
>
>I disagree because a program may have special extensions that are productive
>only at long time control and you will never discover it without playing at long
>time control.
How do you know?
>It is also possible to have pruning ideas that are productive only at long time
>control.
How do you know?
In both cases (extensions and pruning), can you give examples?
>It is possible that the same program is going to be the best at long time
>control and not the best at short time control because it use ideas to make it
>better at long time control.
That's something some people want you to believe.
As for myself, and I think I have tried A LOT, I have never seen any idea that
makes a program better at long time controls if it does not make it better at
short time controls.
>There is a diminishing returns from deeper search but inspite of the deminishing
>returns there are still cases when programs cannot find the right move in a long
>time.
We are talking about comparing programs against each other, not evaluating a
program in the absolute.
There are cases where the best program will find a move that an inferior program
will not find. That's why even at long time controls the best program will still
win more.
On the other hand there are less and less moves that the weaker program will not
find and that the best will find, as time controls increase.
The result is that the gap between the two is smaller when time controls
increase (or processor power increases).
That's the idea I'm currently trying to explain in simple terms.
>I did not see a lot of draws in comp-comp tournament even when the hardware is
>fast and it sugggest that we are not close to see cases when bad programs have
>good chances against good programs even at long time control.
The number of draws between players of the same strength is not very high
anyway. You cannot expect the number of draws to be higher when programs get
closer to each other. You can show this by letting a program play against
itself.
Christophe
This page took 0.01 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.