Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: More doubts with gandalf

Author: Frank Phillips

Date: 07:23:58 02/26/01

Go up one level in this thread


On February 26, 2001 at 08:17:40, Uri Blass wrote:

>On February 26, 2001 at 08:09:24, Frank Phillips wrote:
>
>>On February 25, 2001 at 12:33:45, Christophe Theron wrote:
>>
>>>On February 24, 2001 at 18:58:07, Mogens Larsen wrote:
>>>
>>>>On February 24, 2001 at 17:20:10, Fernando Villegas wrote:
>>>>
>>>>>The point is the sheer size of the jump from one kind of hardware to another. Of
>>>>>course I know, as everydoby else, about improvements due to equipment, but this
>>>>>one is so large that, looking things from a reverse point of view, It could be
>>>>>said that the negative jump from a very fast hardware to a more average one is
>>>>>too great. And if the negative jump is too great, then I have certain ground to
>>>>>consider that when the product was commercially released  they did not put
>>>>>enough concern in how the thing was going to run in an average kind of machine
>>>>>proper of the average consummer, even in CCC. Or to say again in another way:
>>>>>delivery was premature at the cost of the purchaser. My idea is that even in
>>>>>chess programming, as in fact practically does almost every company of
>>>>>programmer, you ensure that the release will be enough good for the average
>>>>>machine proper of time. That's the reason that we, with machines from 90 to 800
>>>>>Mhz, all can say this or that product is very good, etc, although  recognizing
>>>>>that with the fastest one is better. The point is they give us something good
>>>>>even when running in no so fast equipment. So we not complain about Tiber or
>>>>>Rebel on the ground that they only run OK when loaded in a 1,2 Giga monster.
>>>>>I hope my point is clear, Mogens
>>>>
>>>>Yes, I do understand what you're saying. The point just isn't a valid concern in
>>>>my opinion. To my knowledge all top chess programs performs at a high level on
>>>>less than impressive hardware. There may be problems with certain processors
>>>>or/and very low clock speeds, but nothing that spoils the experience of a good
>>>>chess program AFAIK.
>>>>
>>>>The ones that don't, comparatively speaking, do so because of the way they're
>>>>constructed by the author. A prime example would probably be CS Tal, even though
>>>>I've never tried the program. It would be a shame if that project had been
>>>>compromised or cancelled due to speculations about processor speed.
>>>>
>>>>Requirement of certain conditions that needs to be fulfilled imposes a
>>>>limitation on ideas IMO. That isn't a sound development for the consumer or the
>>>>program authors.
>>>>
>>>>So I honestly don't see a problem lurking in the horizon.
>>>
>>>
>>>
>>>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.
>
>Better may be better only on fast hardware because it is possible that adding
>some knowledge make the program 10% slower on fast hardware and 30% slower on
>slow hardware.
>
>It is possible that doing the program 30% slower for adding the knowledge is a
>bad deal for playing strength and doing the program 10% slower for adding the
>knowledge is a good deal.
>
>It is possible that the programmer only tested the program on fast hardware and
>he even does not know that the program is 30% slower on slow hardware.
>
>Uri

Hypothetically, an infinitely fast searcher would not lose a match to a 32 EGTB
if both had the same number of whites, but both would beat a knowledge based
program or fast dumb searcher or something inbetween.

Better is relative.  As you say, I agree that the best balance of knowledge
versus search probably depends on the particular machine.

Frank




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.