An Open Letter to Computer Chess Programmers
Kevin Gowen
AN OPEN LETTER TO THOSE WRITING CHESS SOFTWARE
-or-
WHAT I'D LIKE TO SEE IN A CHESS PROGRAM
Dear Programmer(s):
After using a number of chess-playing software packages over the past
year, I've evolved a few "do's" and "don't's" that I'd like to pass on
to potential programmers. Actually, it's not much more than a list of
personal preferences and pet peeves, but hopefully others share them,
too.
DO make the opening book 100% configurable. Allow it to be totally
disabled, if that's what the user wants. Allow the user to
substitute his/her own opening book. Allow the opening book to be
dumped into an ascii file or some other easily readable format for
the user's inspection.
DO allow the user to configure the search depth, time spent, number of
nodes searched, etc.
DO make absolute time limits. For example, if I set a limit of 15
seconds per move, I want to see a move made in precisely 15 seconds.
I don't want to see 2 minutes go by before a move is made and then 5
seconds on each of the next three in order to make the average.
You'd think that this would be easy to implement, but there are a
large number of programs (particularly shareware) that fail.
DON'T rely on users that have purchased your product to beta test it.
Beta test it yourself. And do it *before* you release it.
DO implement the Fischer clock. Ordinarily, I am opposed to bells and
whistles that suck up RAM and disk space, but this is a frill that is
can be implemented economically.
DO realize (all you DOS programmers) that the users might be using one
of the DOS sub-platforms like Windows, Desqview, 4DOS, DRDOS, etc.
and make your software at least be aware of them. Do you hear me,
Software Toolworks!? There is absolutely no reason, other than poor
programming practice, why users of Chessmaster 3000 should have to
empty out their autoexec and config files of all TSRs, memory
managers and command.com substitutes in order to get CM3000 to run
without causing their PCs to freeze up at random intervals.
DON'T waste a lot of programming time and resources providing a
3-dimensional view of the board. A reasonable 2-dimensional
representation is enough. If I wanted to see 3-D pieces, I can
easily set up my analysis set on the desk alongside my computer.
DO forget about including any "alternate" piece sets. I doubt that very
many serious chess players are interested in analyzing their favorite
variation of the Closed Sicilian on a board with "King Arthur" pieces
or a "fantasy" piece set that looks like it was designed by J.R.R.
Tolkien on acid. Save such fluff for the mass market.
DON'T consume precious megabytes of disk space by requiring the user to
install *all* the fluff the product might have. Have the option
of a "bare bones" install, as well as configurable install options
so the user can decide what's fluff and what's essential.
DO provide lots of analysis options. Allow any analysis to be dumped
to an easily accessible file.
DON'T bother with copy protection schemes. Any hacker with an ounce of
imagination can probably defeat the protections on the various
chess programs in an hour or two, so all you're really doing is
making your software more of a nuisance for the legitimate
purchasers to use.
Yours sincerely,
-kevin
kgo...@cie.uoregon.edu
Feng-Hsiung Hsu
>DO make the opening book 100% configurable. Allow it to be totally
> disabled, if that's what the user wants. Allow the user to
> substitute his/her own opening book. Allow the opening book to be
> dumped into an ascii file or some other easily readable format for
> the user's inspection.
^^^^^^^^^^^^^^^^^^^^^
I seriously doubt that any of the competitive commercial programs will ever
do this. First, the utility to the typical users may be questionable, unless
they want to take advantage of holes in the opening book. From competitive
points of view, allowing the opening book to be easily readable would spell
disasters in computer vs. computer events, which would in turn seriously
affect their products' marketability.
>DO make absolute time limits. For example, if I set a limit of 15
> seconds per move, I want to see a move made in precisely 15 seconds.
^^^^^^^^^^^^^^^^^^^^
This is not so clear a choice here. What if the computer's intended move
just falls apart? Should it be allowed to find a better move, or you would
rather it died a horrible death immediately? Also, if the intended move
is a simple recapture of the queen, wouldn't you rather that the program play
it immediately? A better scheme might be the Bronstein clock--each player
is given an initial allotment of time, which gets decreased whenever the
player exceeds a pre-specified time on a particular move (but unlike the
Fischer clock, no additional accumulation of time allowed). Personally,
I think the absolute time limit is stupid. Give me either the Fischer clock
or the Bronstein clock.
Kevin Gowen
>In article <2fjdsj$e...@pith.uoregon.edu> kgo...@cie.uoregon.edu (Kevin Gowen) writes:
>>DO make the opening book 100% configurable. Allow it to be totally
>> disabled, if that's what the user wants. Allow the user to
>> substitute his/her own opening book. Allow the opening book to be
>> dumped into an ascii file or some other easily readable format for
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> the user's inspection.
> ^^^^^^^^^^^^^^^^^^^^^
>
>I seriously doubt that any of the competitive commercial programs will ever
>do this.
Zarkov already does. You can dump its entire opening book to an ascii file.
It's a great feature.
>First, the utility to the typical users may be questionable, unless
>they want to take advantage of holes in the opening book.
There's all kinds of reasons why a serious player would want to do this.
For example, he may want to "book up" on one particular opening so he could
program in a number of variations that the original book might not have.
>From competitive
>points of view, allowing the opening book to be easily readable would spell
>disasters in computer vs. computer events,
Why?
>>DO make absolute time limits. For example, if I set a limit of 15
>> seconds per move, I want to see a move made in precisely 15 seconds.
> ^^^^^^^^^^^^^^^^^^^^
>This is not so clear a choice here. What if the computer's intended move
>just falls apart? Should it be allowed to find a better move, or you would
>rather it died a horrible death immediately? Also, if the intended move
>is a simple recapture of the queen, wouldn't you rather that the program play
>it immediately?
Well, what if I *want* it to "fall apart"? What if I'm running tests on
the search/evaluation algorithm and I'm trying to see if I can break it?
Besides, if the computer's intended move after a 15 second search "just
falls apart", that doesn't say much for the algorithm, wouldn't you
agree?
>A better scheme might be the Bronstein clock--each player
>is given an initial allotment of time, which gets decreased whenever the
>player exceeds a pre-specified time on a particular move (but unlike the
>Fischer clock, no additional accumulation of time allowed). Personally,
>I think the absolute time limit is stupid. Give me either the Fischer clock
>or the Bronstein clock.
Perhaps I wasn't being very clear here. By "absolute time limit" I did
not mean "give me whatever move you're working on precisely at the point
that 15 seconds has elapsed." Presumably, the software is smart enough
to save the best move found so far and *that* move is the move that will
be given after 15 seconds. And to address your other point, if it's an
obvious or forced move, like a mate or a queen recapture, certainly I
would have no objection to the computer taking less time by playing it
immediately.
The situation I want to avoid is this: I want to play a quick game, so I
set the time limit to say, 10 seconds per move. I commence play and
soon we're at the end of its opening book so it starts to think. 10
seconds go by and I expect it to make a move. After all, I've set the
time limit to 10 seconds per move, right? This implies that it's going
to make a move in 10 seconds, right? But it doesn't make a move. It's
still thinking. 20 seconds go by. Then maybe 30. *Then* the move
comes. I make my reply. This time, 15 seconds elapse before I see a
the next move. Then maybe it'll make a few moves that each fall within
the time limit I have set, then I'll get some that don't. It appears to
me to be pretty arbitrary. My question is: if this is the case, then in
what sense does the "move in X" type time limit have any meaning?
Just in case you think I'm dealing in nothing but hypotheticals, I point
out that this happens to me all the time. My chess software of
preference is Zarkov 2.6 and although I like it a lot, it has this one
bug (or "feature", however you want to look at it...) and it drives me
crazy. It is not uncommon for it to take 3 or even 4 *times* the set
time limit to make a move. My usual time setting is "move in 15
seconds" and I have seen it take up to 2 minutes and 45 seconds to make
a move. That's why I thought maybe the time limit actually meant, "move
in 15 seconds *on the average*" I suppose I can understand this, but if
that's what I wanted, then I could easily use the standard "x moves in y
minutes" type time control. I can't see why precise time controls are
"stupid." Chessmaster 3000, for all it's faults, handles the time
limits correctly.
The author of Zarkov, John Stanback, is a sometime contributor to this
newsgroup; perhaps he could get in here with a few comments about this
subject if he feels so inclined. In my opinion, having these fuzzily
defined time controls mars what is otherwise a fine product.
-kevin
kgo...@cie.uoregon.edu
John Stanback
: In article <CIn9y...@hawnews.watson.ibm.com> f...@watson.ibm.com (Feng-Hsiung Hsu) writes:
: >In article <2fjdsj$e...@pith.uoregon.edu> kgo...@cie.uoregon.edu (Kevin Gowen) writes:
: >>DO make the opening book 100% configurable. Allow it to be totally
: >> disabled, if that's what the user wants. Allow the user to
: >> substitute his/her own opening book. Allow the opening book to be
: >> dumped into an ascii file or some other easily readable format for
: > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: >> the user's inspection.
: > ^^^^^^^^^^^^^^^^^^^^^
: Zarkov already does. You can dump its entire opening book to an ascii file.
: It's a great feature.
I think users will like this, but it will hurt if someone plays
Zarkov in competition against other computers where the other
programs are "booked up" against it -- I believe there might be
such tournaments in Europe, not in the US.
If I enter Zarkov in a tournament I will have to create a new
opening book.
: >>DO make absolute time limits. For example, if I set a limit of 15
: >> seconds per move, I want to see a move made in precisely 15 seconds.
: > ^^^^^^^^^^^^^^^^^^^^
I agree with CB here.
All computer algorithms will occasionally "fail-low" when they
discover a threat that was "invisible" on the previous iteration.
If this happens just before the 15 second "limit" and the program
realizes that its best move is much worse than it thought it
should allow itself extra time to try to find a better move.
This makes the program play stronger which is what I think
most people would prefer.
The fixed depth options that most programs offer can be used
to evaluate the search algorithm.
John Stanback
Paul A. Lane
>DO make the opening book 100% configurable. Allow it to be totally
> disabled, if that's what the user wants. Allow the user to
> substitute his/her own opening book. Allow the opening book to be
> dumped into an ascii file or some other easily readable format for
> the user's inspection.
There's some good stuff in there and some not so good stuff. I don't have
any burning desire to read the opening book and I doubt very many players
do. The substituting/modification stuff is a decent idea, though.
>DO make absolute time limits. For example, if I set a limit of 15
> seconds per move, I want to see a move made in precisely 15 seconds.
> I don't want to see 2 minutes go by before a move is made and then 5
> seconds on each of the next three in order to make the average.
> You'd think that this would be easy to implement, but there are a
> large number of programs (particularly shareware) that fail.
Hmm. I'd like my chess opponent to play a bit more like a human. Only
an idiot would waste his time on a forced recapture, so I don't see any
need to force the computer to do so. I suppose a better compromise would
have the time limit to be optionally set to limit the amount of time spent
per move.
>DO implement the Fischer clock. Ordinarily, I am opposed to bells and
> whistles that suck up RAM and disk space, but this is a frill that is
> can be implemented economically.
Perhaps four different options: (1) Time per game, (2) Time per move
(average), (3) time per move (fixed max), (4) Fischer. I'd have to say
that since I started playing ICS, I rather like the Fischer clock.
{awareness of possibilities deleted}
Not to mention my sound card, motherboard etc etc. In my view, this is all
a limit of DOS and its weirdness. (So go buy OS/2 everyone! That or keep
a minimized boot disk.)
>DON'T waste a lot of programming time and resources providing a
> 3-dimensional view of the board. A reasonable 2-dimensional
> representation is enough. If I wanted to see 3-D pieces, I can
> easily set up my analysis set on the desk alongside my computer.
I'm with you on this one. Three-D boards look kinda neat, but I suspect
not that useful for virtually anyone. I always shift to a 2-D board. The
screen is 2-D. The board is best 2-D.
{Gripes about weird piece sets & "fluff" deleted}
I would agree that a *minimal* installation option (as is available with
most mainline software would be desirable. It can't be that much trouble
and saves space. Alternatively, use sub-directories which can be deleted.
I would think that some of Kevin's gripes are not all that generally appli-
cable, but a couple should be given special attention. Being able to remove
options which waste disk space would be nice.
Paul
--
Robert Hyatt
I'll throw in a couple of really "obvious" comments.
First, when was the last time *you* played a game where you moved in
exactly "n" seconds *every* time? You don't, you say? Why? Because
each position is somewhat different and some require more time to follow
tactics than others. Cray Blitz has just such a time control as you
suggest, where each move is given "n" seconds. However, if a move fails
low (falls apart, re: above) then it can still overflow and take longer.
I have done this in speed. Even in time trouble, you sometimes stop to
"smell the roses" when you notice a check you had not considered...
Second, everyone wants a computer to play like a human, not snatch poisoned
pawns, etc. and yet you turn right around and want the program to play
"mechanically" vis a vis the time clock. In Cray Blitz, the time overflow
code is so "imbedded" in the search algorithm, that turning it completely off
is not easy without surrounding lots of little "code fragments" with if-
statement conditionals. Then you might complain that the search is too slow--
after all, it is asking "should I ignore time overflows" over and over...
Finally, I agree that going "way" over is annoying. My Mach III is a big
offender here. When playing games with it using "Sparc Blitz" when we are
tuning our program, sparc blitz pretty well averages whatever you say.
The Mach III seems really arbitrary, and when I use a real clock for practice,
it regularly loses on time. A far better answer would be to get a program
that is enough better than you are that you can set the time control to 5
seconds per move, and when it goes over, it still moves pretty quickly.
Bob
--
!Robert Hyatt Computer and Information Sciences !
!hy...@cis.uab.edu University of Alabama at Birmingham !
Bruce_L...@transarc.com
all said the same thing: "my [our] algorithm isn't robust enough for that."
It's quite possible to design a more robust algorithm. Where is their sense
of "the customer is always right"? The proper response was, "that feature
will appear in a future release ... sir!" (Well, I suppose that Hsu and Hyatt
can take a more arrogant position, since they are in the research sector.)
Fixed time limits used to be a popular format for speed chess.
As recently as the 1960's, I remember 10-second chess tournaments held at
the Pittsburgh Chess Club. Evidently, to cope with this type of play, humans
had to develop robust algorithms for coping with cheapos discovered in the
9th second.
Also, all the people whose response to Gowen was, "you don't really want that,"
get real. For every person like Gowen who posts his wish list, there are 10
who agree but don't have the gumption to post. And for every one who follows
up his post with a very careful elaboration of what he had in mind and why,
there are 100.
Roy Eassa
>The replies by Stanback, Hsu, and Hyatt to Gowen's desire for fixed time limits
>all said the same thing: "my [our] algorithm isn't robust enough for that."
>It's quite possible to design a more robust algorithm. Where is their sense
>of "the customer is always right"? The proper response was, "that feature
>will appear in a future release ... sir!" (Well, I suppose that Hsu and Hyatt
>can take a more arrogant position, since they are in the research sector.)
Whoa! I'm all for good customer relations and responsiveness to user
needs, but this is going too far. These programmers probably have a long
list of possible features and enhancements to make, along with the
never-ending work of improving the chess algorithms, trying new ones, and
testing the program and its strength. They must take any new requests in
their proper context and evaluate them in a reasonable fashion.
I use all of the top PC chess programs and have an entirely different set
of priorities than you do. The feature you asked for, IMHO, is not a
particluarly productive one for a programmer to implement. On the other
hand, I desparately want *every* chess programmer to standardize on a GUI,
menu structure, etc., within reasonable limits. I hate the radical
differences among Genius, MChess, Zarkov, etc.! The only PC chess
program that is decent for GUI is The Chess Machine. Macintosh is 10
years old, and every program has an identical look and feel for common
features (plus common keystroke shortcuts, long filenames, standard
dialog boxes for open/save, etc.). Windows achieves some of this on the
PC. Why, in 1993 (1994!) reinvent the user interface?! Use
standard-looking dialog boxes, scroll bars, click/double-click shortcuts,
pull-down menus, drag & drop, etc! Don't start each program from
scratch! Devote your time exclusively to the chess algorithms and
added-value features (e.g., Fischer clock, evaluation-to-disk, etc.) by
using tested, standardized, off-the-shelf technology for file open/save,
menus, scrolling, etc., etc! If not MS-Windows, then one of the many DOS
libraries for this.
John Stanback
: Bruce_L...@transarc.com writes:
: >The replies by Stanback, Hsu, and Hyatt to Gowen's desire for fixed time limits
: >all said the same thing: "my [our] algorithm isn't robust enough for that."
: >It's quite possible to design a more robust algorithm. Where is their sense
: >of "the customer is always right"? The proper response was, "that feature
: >will appear in a future release ... sir!" (Well, I suppose that Hsu and Hyatt
: >can take a more arrogant position, since they are in the research sector.)
: Whoa! I'm all for good customer relations and responsiveness to user
: needs, but this is going too far. These programmers probably have a long
: list of possible features and enhancements to make, along with the
: never-ending work of improving the chess algorithms, trying new ones, and
: testing the program and its strength. They must take any new requests in
: their proper context and evaluate them in a reasonable fashion.
This is certainly true! I would consider modifying my
time control algorithm (or other feature) if I were to get several
people making a similar request. One reason that I would hesitate
to modify the time control algorithm such that the program would
never take much longer than the stated time is that most
users would not realize that the fixed time levels are weaker than
they "should" be. I would probably have to make a separate option
for "move in exactly X seconds" and put up a message stating that
this weakens the program.
: I use all of the top PC chess programs and have an entirely different set
: of priorities than you do. The feature you asked for, IMHO, is not a
: particluarly productive one for a programmer to implement. On the other
: hand, I desparately want *every* chess programmer to standardize on a GUI,
: menu structure, etc., within reasonable limits. I hate the radical
: differences among Genius, MChess, Zarkov, etc.! The only PC chess
: program that is decent for GUI is The Chess Machine. Macintosh is 10
: years old, and every program has an identical look and feel for common
: features (plus common keystroke shortcuts, long filenames, standard
: dialog boxes for open/save, etc.). Windows achieves some of this on the
: PC. Why, in 1993 (1994!) reinvent the user interface?! Use
: standard-looking dialog boxes, scroll bars, click/double-click shortcuts,
: pull-down menus, drag & drop, etc! Don't start each program from
: scratch! Devote your time exclusively to the chess algorithms and
: added-value features (e.g., Fischer clock, evaluation-to-disk, etc.) by
: using tested, standardized, off-the-shelf technology for file open/save,
: menus, scrolling, etc., etc! If not MS-Windows, then one of the many DOS
: libraries for this.
This is not quite as easy as you would expect (at least for a DOS program).
When I started to write the interface for Grandmaster Chess and Zarkov3
I downloaded about 5 demo programs for some popular
DOS GUI interface libraries. It seemed that these libraries were not
very suitable. They all took so much memory that I could not fit
them and the chess engine and other chess functions within the 640K
DOS limit. Also, the libraries I looked at were non-standard
in the way the dialog boxes etc. functioned and most of them did
not look very appealing to me. I asked several game programmers
what they used for their interface and they all wrote their
own GUI -- so that's what I ended up doing also.
Perhaps the situation is better today than 1-2 years ago, but I'm not
so sure. One thing that is becoming a handicap for me is that I
have not had time to learn C++ and I think that were I to find a
good DOS GUI library it would require C++.
I'm slowly learning Windows programming, but I prefer to spend most
of my time working on the chess engine...
John Stanback
Jan Eric Larsson
>The replies by Stanback, Hsu, and Hyatt to Gowen's desire for fixed
>time limits all said the same thing: "my [our] algorithm isn't robust
>enough for that."
No, they didn't. They said that it is a BETTER algorithm to use some
extra time in those cases when the program suddenly discovers tha the
current "best" move seems to be a blunder. It hasn't got anything to
do with robustness.
It is quite simple to just cut the search when the time is up and have
a program play the current best move. In fact, this is simpler,
because it doesn't demand any special time decisions. The simple
reason for variable search time is that it can give better play in
games where it is allowed to use different times on different moves.
>It's quite possible to design a more robust algorithm. Where is their
>sense of "the customer is always right"? The proper response was,
>"that feature will appear in a future release ... sir!" (Well, I
>suppose that Hsu and Hyatt can take a more arrogant position, since
>they are in the research sector.)
Arrogant? Since when are you a customer of Hsu and Hyatt? Let these
gentlemen do whatever research they want. I think you are a bit
out of line here.
>Fixed time limits used to be a popular format for speed chess. As
>recently as the 1960's, I remember 10-second chess tournaments held at
>the Pittsburgh Chess Club. Evidently, to cope with this type of play,
>humans had to develop robust algorithms for coping with cheapos
>discovered in the 9th second.
This simplifies the distribution of time per move, which would most
certainly be very beneficial to chess programs, as compared to humans.
But why not?
>Also, all the people whose response to Gowen was, "you don't really
>want that," get real.
I would guess that most people find it more interesting to have a
time limit per game or certain number of moves, i.e., the more common
way. But whenever there is enough interest from customers, I am sure
that the forces of market economy will motivate the makers to put
in a fixed time per move choice. It doesn't demand any extra work
on the algorithm side, just some extra graphics or whatever sa that
the user can select it.
Jan Eric Larsson Phone: +1 (415) 723-0948
Knowledge Systems Laboratory E-mail: Lar...@KSL.Stanford.Edu
Stanford University
701 Welch Road, Building C "We watched the thermocouples dance to the
Palo Alto, CA 94304, USA spirited tunes of a high frequency band."
Feng-Hsiung Hsu
>The replies by Stanback, Hsu, and Hyatt to Gowen's desire for fixed time limits
>all said the same thing: "my [our] algorithm isn't robust enough for that."
No, it is not a matter of algorithm robustness. It is a matter of how to
get the most out of the computing time. First, it is not clear that Mr. Gowen
really wants the hard time limit, but rather something that plays sufficiently
fast for a given strength. With the current state of the art, a program will
typically exceed the soft time limit probably no more than twice per game.
[The program Mr. Gowen was complaining about seemed to be doing it more
often--it might have a faulty time control algorithm, or is relatively weak.]
Furthermore, it will probably play at comparable strength as the same program
would be when set at a hard time limit that is twice as long. That is, a soft
time limit mode allows faster average response time for the same playing
strength, and when the program exceeds the soft limit, you know that it is
sweating:-). For most users, my guess is that the soft time limit mode is
preferable to the hard time limit mode, and for running analysis, the soft
time limit mode is definitely preferable. If your resources are limited, which
mode would you throw out? I will keep the regular time control, soft time
limit, and Fischer/Bronstein mode. Sure, a hard time limit can be implemented,
but I don't think it should be high on the wish list. And I think the
current programs simply do not properly document what their time limit mode
does and hence the objection on Mr. Gowen's part.
Robert Hyatt
Hopefully CB and I weren't "too arrogant"... However, as I have said many
times in the past, Cray Blitz was written to compete against an opponent
using well-defined time controls. It can do any of the following:
(1) m moves in n minutes (average m/n minutes per move)
(2) m moves in n minutes followed by m1 moves in n1 minutes
[a secondary time-control added]
(3) m seconds per move (average time, knowing full-well that it
will occasionally move quicker and occasionally slower.
(4) sudden death in many variants
(5) search forever
(6) fixed depth search
We haven't added the "absolute" time per move as it simply isn't useful
in any way we can see. I don't want the program to ever play a move that
it (a) knows is bad and (b) doesn't know if there is a better one.
With Cray Blitz, you *can* demand a move at any time with the proper options
set (we use this mode to play in simul events where we "demand" a move just
as the simul player walks up to our board, letting the program think as long
as possible.
I personally think that an "adaptive" algorithm that does it's very best to
avoid bad moves is acceptable when quality is important. If you don't like
the delays, go for a faster machine, speed the program's search time limit
up proportionally, and wait less.
Kevin Gowen
Hyatt, who took the time to explain a little bit how the search
algorithms work to a complete neophyte such as myself. As I understand
it, the problem with my wanting an absolute time limit is what happens
when, near the back end of a time limit, the computer suddenly realizes
that its selected move is actually a horrendous blunder and extra time
must be alloted to find a better one. I also understand that forcing an
absolute time limit will result in a weaker algorithm. Further, this is
not one of those problems that is going to go away by throwing more
robust algorithms at it; chess programmers are always going to have to
be figuring out ways to handle bizarre or unexpected events that occur
at or near these types of boundary conditions.
Some observations:
If a master-strength computer program drops 100 points so it can have an
absolute time limit, the reduction in strength probably won't make too
much difference to weakies like me. Chessmaster 3000 has a time control
of the type I prefer. Compared to what else is available, it isn't a
top contender. Even so, it whomps my butt constantly, particularly in
blitz.
I used to force my chess program to make a move if it exceeded twice the
time limit. It didn't appear to me that the quality of these moves was
any less than "regular" moves. I got beat just the same. Of course,
this is hardly a scientific observation...
I was amused by those who responded by saying, basically, "don't you
want your computer to play like a human?" If I really wanted that, I'd
have to find a program that would drop pawns, hang pieces, play
brilliantly for awhile and then make a really stupid move, overlook 1
and 2 move cheapos, show its wins over me to all of my friends, and
threaten me with abusive language on ICS.
Perhaps it would be correct to say that for most programs, the "1 move
in x seconds" isn't really a meaningful time control. In that case, it
should be done away with entirely, or explained that the 'x' seconds is
actually a goal to be strived for but not necessarily what the computer
will actually do all of the time.
My main beef was with Zarkov 2.6. I have since upgraded to 3.0 and have
noticed a definite improvement in this time control. The target time is
being met a lot more often than in the older version. So now I'm happy.
-kevin
kgo...@cie.uoregon.edu
Johannes Fuernkranz
>(3) m seconds per move (average time, knowing full-well that it
>will occasionally move quicker and occasionally slower.
What's the heuristic behind moving quicker? Something like "Hey, I only have
15 seconds left for my average time, I can't possibly search the next ply!"?
Or do you "lie" to the program in the sense that you tell it it has less time
and rely on the program that it doesn't overextend it too often.
Or are there heuristics like "I have to re-capture that knight anyways?"
Or ...?
Juffi
--
Johannes Fuernkranz ju...@ai.univie.ac.at
Austrian Research Inst. for Artificial Intelligence +43-1-5336112(Tel)
Schottengasse 3, A-1010 Vienna, Austria, Europe +43-1-5320652(Fax)
--------------- "Life's too short for Chess." -- Byron ------------------
Robert Hyatt
>In article <1993Dec30....@cis.uab.edu> hy...@cis.uab.edu (Robert Hyatt) writes:
>>(3) m seconds per move (average time, knowing full-well that it
>>will occasionally move quicker and occasionally slower.
>
>What's the heuristic behind moving quicker? Something like "Hey, I only have
>15 seconds left for my average time, I can't possibly search the next ply!"?
>Or do you "lie" to the program in the sense that you tell it it has less time
>and rely on the program that it doesn't overextend it too often.
>Or are there heuristics like "I have to re-capture that knight anyways?"
>Or ...?
>
> Juffi
We "move quicker" for two distinct reasons:
(1) we make a move and then start "pondering" a reply to what we expect you
to play. If our target time for this move is 3 minutes, and you think for
2 minutes and then play our predicted move, we will think for another one
minute (for a total of 3 which was our target) and then make a move after
"only" 1 minute has elapsed. If you were to take 5 minutes to make the
predicted move, we would think for the whole 5 minutes (on your clock) and
then make an "instant" move when you enter your move. We use the "saved" time
either (a) when we get into trouble (time overflow) or to (b) increase the
average time per move (target time).
(2) we make a quick move when we consider it "easy." This is pretty
restricted, but works something like this. If your move is a capture, and
the best move (from our n-ply ordering search) is to re-capture this piece,
and only *one* recapture move is reasonable, then we will make a move after
only 1/3 of the target time has elapsed. If there are two ways to capture,
and both seem reasonable, we will use the entire target time to differentiate
between the two moves. Note that if you "hang" a piece, we won't consider it
"easy" as we are suspicious that it is a trap. If the evaluation is "up"
from what it was after we made our last move, we are also "suspicious" that
you are up to something. In short, for obvious re-captures we move quickly,
but not for anything else. One exception: If we have only one legal way to
get out of check or only have one legal move, we will do a minimal search so
that we have something to "ponder" for you and then will make the forced move
immediately. We typically use a couple of seconds on a Cray for such moves to
produce a reasonably long principal variation for pondering.
Hope this helps.
Bruce_L...@transarc.com
in connection with Robert Hyatt, who is Mr. Nice Guy on r.g.c.
Let me clarify what I meant by "robust". Suppose an algorithm is faced with
a time limit of 10 seconds, and after 9 seconds of thinking, it discovers that
the combination it was planning on loses a piece. If it plays that move
anyhow, it's not robust. If it plays a random move, it's not robust. But if
it does what I do, which is to buy time by playing as non-committal a move as
it can find, then it's robust. It's usually pretty easy to find
non-committal moves; a lot easier than finding the best move.
This can be done in the first second, rather than the last.
Of course, there is some decrease in the quality of play. But this is limited.
Apparently some contributors to this thread felt that random play was the
only alternative, and of course that would lead to an unacceptable decrease in
the quality of play. But that's just a straw man.
This hack is helpful not only for "10-second" play, but for any severe
time-pressure situation. Every human does it; strong players better than
weaker ones, of course. I don't see any difficulty in translating it to the
computer domain, in spite of the difference between computer and human
chess playing algorithms.
Roy Eassa
>Let me clarify what I meant by "robust". Suppose an algorithm is faced with
>a time limit of 10 seconds, and after 9 seconds of thinking, it discovers that
>the combination it was planning on loses a piece. If it plays that move
>anyhow, it's not robust. If it plays a random move, it's not robust. But if
>it does what I do, which is to buy time by playing as non-committal a move as
>it can find, then it's robust. It's usually pretty easy to find
>non-committal moves; a lot easier than finding the best move.
>This can be done in the first second, rather than the last.
>Of course, there is some decrease in the quality of play. But this is limited.
>Apparently some contributors to this thread felt that random play was the
>only alternative, and of course that would lead to an unacceptable decrease in
>the quality of play. But that's just a straw man.
>This hack is helpful not only for "10-second" play, but for any severe
>time-pressure situation. Every human does it; strong players better than
>weaker ones, of course. I don't see any difficulty in translating it to the
>computer domain, in spite of the difference between computer and human
>chess playing algorithms.
How in the heck can a computer recognize a non-commital move? To it, all
moves are just moves. They each need to be analyzed as deeply as
possible to get a good evaluation. Any move might lose material or the
game in a variation that's deeper than what has already been analyzed.
So choosing a non-commital move during the first second implies not
having analyzed that move as deeply as the one that at first seemed best
but turned out to lose a piece (in your example); how on Earth can the
program assume that the less-analyzed move avoids this material loss at,
say, ply 10?
Mark Mittelstaedt
-> want your computer to play like a human?" If I really wanted that,
-> I'd have to find a program that would drop pawns, hang pieces, play
-> brilliantly for awhile and then make a really stupid move, overlook 1
-> and 2 move cheapos, show its wins over me to all of my friends, and
-> threaten me with abusive language on ICS.
Have any of the programmers thought of taking some kind of averages that
human players do these kinds of things at different levels and then
statistically implement these into their programs? I know the masters
out there will find this proposterous but I think the weaker players
would find it fun and valuable to train with for clubs and such...
Stuart Cracraft
> seconds per move, I want to see a move made in precisely 15 seconds.
> I don't want to see 2 minutes go by before a move is made and then 5
> seconds on each of the next three in order to make the average.
> You'd think that this would be easy to implement, but there are a
> large number of programs (particularly shareware) that fail.
[Gazebo does this.]
Gazebo(c) is a computer chess program for Microsoft Windows(TM) 3.0,
3.1, and Windows NT. Gazebo(c) is written entirely in object-oriented
Microsoft Visual C++ Professional(TM).
Gazebo(c) uses the null-move and history heuristics in implementing an
iterative depth-first alpha-beta search with full quiescence and
combined terminal-node and ply-1 evaluation tables. Depth-limited and
time-limited search are featured.
Gazebo(c) is a tightly-coded, efficient algorithm, which avoids
the "bloated" approach of other chess programs, yet still offers
beautiful color graphics, an attractive icon, integrated mouse
handling, and super-fast startup.
Gazebo(c) is priced at $25 and is offered by The MSM Company, 25682
Cresta Loma, Laguna Niguel, Ca. 92677 USA, 714-347-8107. Gazebo(c) is
copyright (c) 1994 The MSM Co.
Shaul Markovitch
|> In article <4h8Peyf0B...@transarc.com> Bruce_L...@transarc.com writes:
|> >The replies by Stanback, Hsu, and Hyatt to Gowen's desire for fixed time limits
|> >all said the same thing: "my [our] algorithm isn't robust enough for that."
|> >
|> >It's quite possible to design a more robust algorithm. Where is their sense
|> >of "the customer is always right"? The proper response was, "that feature
|> >will appear in a future release ... sir!" (Well, I suppose that Hsu and Hyatt
|> >can take a more arrogant position, since they are in the research sector.)
|> >
Yaron Sella and I did some study about time allocation strategies for game-playing.
The reference:
Learning of Resource Allocation Strategies for Game Playing, Shaul Markovitch
and Yaron Sella, The proceedings of the 13th International Joint Conference
on Artificail Intelligence, Chambery, France, 1993.
==============================================
Shaul Markovitch, Computer Science Department
Technion - Israel Institute of Technology
Haifa 32000, Israel. (TEL. 972-4-294346)
Email : sha...@cs.technion.ac.il
==============================================