Author: Uri Blass
Date: 05:17:40 02/26/01
Go up one level in this thread
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
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.