Author: Frank Phillips
Date: 05:09:24 02/26/01
Go up one level in this thread
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. Frank
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.