Author: Christophe Theron
Date: 20:55:06 03/26/01
Go up one level in this thread
On March 26, 2001 at 23:23:28, Dann Corbit wrote:
>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)?
It could happen if we are talking about going from ply 1 to ply 2 or 3, MAYBE.
That is close enough to the origin to see this.
From ply 6 and on we are not anymore close to the origin enough to see this kind
of problem.
>2-3 plies is pretty weird, but I don't think it is unbelievable.
Not from a well designed program at the ply depths mentionned.
I'm talking about average behaviour on a significant number of position.
Oh... Maybe you can do that if you have a very complex QSearch from ply one to
ply 6, then suddently from ply 7 on you have no QSearch at all... But this is
not what I would call a well designed program.
Christophe
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.