Author: Dann Corbit
Date: 20:23:28 03/26/01
Go up one level in this thread
On March 26, 2001 at 22:59:33, Christophe Theron wrote: >On March 26, 2001 at 22:11:48, Dann Corbit wrote: > >>On March 26, 2001 at 22:00:41, Christophe Theron wrote: >>[snip] >>>Of course you could demonstrate your point about the 150 to 200 elo jump by >>>writting a program that really sucks until it can run at 800MHz or higher, but >>>my point is that a well designed program will not get a 150 to 200 elo increase >>>just because it is running on a dual, even at 3 0. >>> >>>The elo increase, at any time control, will be in the range around 25 ELO. >>> >>>Hey, if you go at 6 plies on a 450 and reach 8 to 9 plies on a 800, you have a >>>bloody serious problem somewhere in your program, believe me. :) >> >>Such changes are not at all unusual. >> >>If I have written a sorting algorithm that is O(n*log(log(n))) [and such things >>do exist] will it be faster for sorting three things than Shellsort? Surely >>not. But with enough data for input, it will always beat Shellsort. >> >>The curve may do all sorts of ugly, wiggly nonsenese near the origin, and have a >>high initial y intercept. But given enough time, it must beat the other >>algorithm because of the O(f(n)) behavior. >> >>If I have an algorithm with good O(f(n)) behavior, you may have an algorithm >>with much worse O(f(n)) behavior and consistently beat me bloody with your >>algorithm because of behavior near the origin. But if we both get faster and >>faster machines, at some point the tables will turn. >> >>Since Vincent's algorithm does not perform well at low CPU strength, that is >>certainly one possibility (among the myriad of possibilities). >> >>We should not be quick to assume that behavior on a slow speed CPU must have a >>linear match to behavior on a very high speed CPU. >> >>I have definitely seen programs for which blitz behavior does not parallel >>behavior when playing real chess. >> >>Amy springs to mind. Amy is not a good blitzer. Put Amy on a 1GHz+ computer >>and Amy shows her teeth. > > >We are not talking about ANY algorithm. We are talking about the well known >alpha beta with all the stuffs you can add on it. > >There is no reason that a program cannot have an consistent behaviour at any >time controls. You can check this with Chess Tiger. I'm not writting this out of >nowhere, I'm working on this since years. > >If someone's program sucks at short time controls and need faster hardware or >much longer time controls to show a decent play, then it simply has a very >suboptimal behaviour. I'm entitled to say this, because I know there exists a >better behaviour (which might also be suboptimal in absolute, but that's another >problem). > >That's why I'm saying to Vincent that it is strange (to say it mildy) that his >program gains 2 to 3 plies when you double its speed. Suppose that you have a very expensive evalution function. Suppose it costs 100 times as much as the one used in Chess Tiger. Do you still believe that your statements hold true (about behavior near the origin)? 2-3 plies is pretty weird, but I don't think it is unbelievable.
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.