A story about Python... sort of

[Ben Finney]

On Mon, 07 Jul 2003 03:27:04 GMT, Russell Reagan wrote:
> I agree that it is not good to worry about optimization prematurely,
> but computer chess might be a bit of a unique area.

I am extremely skeptical of any statement like this.  *Everyone* thinks
their area is a unique exception to the guidelines.

The area in which one chooses to specialise is fascinating, and one
spends a lot of happy time exploring its unfathomable complexities.  It
is a hideously common mistake to extrapolate, from this, that the area
whose complexities you know in detail is therefore more complex than
others, and thus exempt from the guidelines.  It is then a very small
step to assume a priori that it *is* an exception, in this one unique
area.

I'm not saying yours is not, but you'd better prove that "might be"
before it becomes "let's assume it is".

> This is also why OOP might not be of much use for chess programming.

Programming in Python doesn't necessitate OOP; one can make use of the
rich data structures as is while being happily procedural.

> There is really not a lot you can do to improve [position evaluation]
> short of starting over from scratch and creating your data structures
> in such a way as to exploit lots of low level tricks.

Sounds like you're already focusing in the right area.  Make smart data,
so that the code can be dumb.  The advantage is that you can write dumb
code in most any language -- so you can choose Python if you want to
prototype your smart data structures.

And, who knows, your data structures may be so well designed that your
dumb Python code is good enough, except just in this little bit here
that needs to be tweaked in C.

>> at least you've debugged a working algorithm, and can treat it as
>> pseudocode for the port to C.
>
> It sounds like you're thinking, "I'll just implement this python
> program in C/C++, and then it will be faster," but I'm not sure that
> is the case.

I was referring more to algorithms rather than entire programs, since
they are more often at a "module" level, but in essence, yes.  Once you
decide you've made the algorithm as fast as it can be while remaining
implemented in readable Python, that's the point to think about
re-implementing the algorithm in C.

> Sure it will be faster, but probably still pretty slow.

This is the assumption that will trip you up and cause you to optimise
prematurely.  Do *not* assume you know exactly where your program will
be slow until you see it working and profiled, or which parts will be
best implemented in C.

> Making a really fast chess program would require changing the data
> structures significantly, and I'm not sure what use the python code
> would be after you made a big overhaul of the data representations.

Again, make the data structures smart and you can manipulate them in
dumb code written in Python or C.

> What do you think? I may be way off. Maybe I'm putting too much
> emphasis on speed.

It's understandable, given that the focus on chess-playing programs is
mostly on finding ways to make them go faster or do more in the same
time.  But if you want to implement a program in Python, don't make any
assumptions about where it is slow.

Much of the Python core is *already optimised* in C libraries, so
attempting to optimise before profiling is doubly foolish.  One of
PYthon's strengths is rich data structures, that work very fast under
most all conditions because their implementation is smart.

Take advantage of Python's powerful types when you design your own smart
data; but start with the simple algorithms and tweak them only when they
prove to be slow in Python.

-- 
 \          "I spent all my money on a FAX machine. Now I can only FAX |
  `\                                       collect."  -- Steven Wright |
_o__)                                                                  |
http://bignose.squidly.org/ 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B