Author: Sune Fischer
Date: 09:30:12 11/15/02
Go up one level in this thread
>Once, I took a graduate course offered by the Math Department at the local
>university. The course title included the word "algorithm." Unfortunately,
>those "math people" are preoccupied with producing proofs, so we spent the
>entire semester proving theorems. : )
Ha, I did the same, they had a course on the finite element method, of course it
was all theorems and no code!
>I have a book, "Algorithms in C, Parts 1-4," 3rd Edition, by Robert Sedgewick.
>The book is interesting but does assume proficiency in C programming, which is a
>problem for me. What strikes me most, by scanning through this book, is that
>the algorithms discussed seem to be at a level of detail not far from the level
>of coding. In other words, the general "algorithm" you cited, having to do with
>one's early morning ritual, does not seem to be at the level of detail given in
>that book.
>
>I see sub-programs and functions as being the products of algorithm development
>and then of subsequent coding. Like a program, they may have started out with
>an idea, progressed to more detail [with the help of flow charts] until, at some
>magic point, the "algorithm level" is reached. Then the process of adding
>detail progresses through the coding phase until a fully debugged source program
>[or sub-program or function] is reached. That is my perception. Please correct
>me if my perceptions in this matter are not correct.
Well, algorithms come in all shapes and sizes, here is a three line algorithm to
find the larges number in an array:
max := -infinity;
for i=0 to N do
if A[i] greather_than max
max := A[i];
end if
end for
very simple, of course if you wanted to sort the array, A,
with largest elements first it would be much more complex.
Suppose you would need to sort this array 100000 times a second, for a chess
program for instance. You would want to do it as fast as possible, but then you
realize there are different methods, some more efficient than others. This is
why there are books on the subject :)
>Chess engines, it seems to me, are moderately complex computer programs. They
>include numerous different parts, sometimes interrelated, which should be
>considered to be implementations of various algorithms. Here, I a
m referring to
>"algorithms" as being at the level of the book discussed above.
>
>Here, at CCC, there has been much discussion about "search algorithms." This
>appears to be the most fruitful area for chess engine software development. It
>seems that the near-term advancements in chess engine software will be in
>finding better search algorithms. It's not surprising to see people here at CCC
>use the word "algorithm" when they really mean "search algorithm." Everybody
>here seems to understand and so there is no confusion.
I do not know the exact definition of the word, but there are things I wouldn't
call an algorithm, like this:
x = 2*x + square_root(x)
I would call that an equation and not an algorithm, of course square_root(x)
requires an algorithm of some sort. Confused, well maybe someone has a better
explanation :)
>Let me end this with a question:
>
>What types of algorithms are implemented in modern chess engines, other than
>"search algorithms"?
There are three main components in a chess program, generation of moves, search
of the game tree and evaluation of positions.
Plenty of algorithms go into all phases.
-S.
>Bob D.
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.