Object-Oriented Chess Program
G.
Alberto Santini
http://web.tiscali.it/albertosantini/chess/copycut.zip
--
Alberto Santini
"G." <g...@nomail.com> wrote in message
news:gYfa9.12189$6m61...@news04.bloor.is.net.cable.rogers.com...
Mark C.
http://www.gamedev.net/reference/programming/features/chess1/
G.
"Guy Macon" < Guy Macon @ http://www.guymacon.com/index.html > wrote in
message news:umlup7r...@corp.supernews.com...
> G. <g...@nomail.com> wrote:
>
> >Hello,
> >
> >I would like to conduct some experiments with chess algorithms and I'm =
> >looking for the source code of a chess program that's written in an =
> >Object-Oriented language preferably Java or even better C#.
> >
> >Any pointers would be appreciated.
> >
> >george
>
> Is FORTH object-oriented enough for you? <runs>
>
G.
thanks.
g.
"Mark C." <ab...@localhost.localdomain> wrote in message
news:akgctj$h...@dispatch.concentric.net...
G.
functional program?
g.
"Alberto Santini" <AS@N_O_S_P_A_M.it> wrote in message
news:akcsmg$7l3$1...@lacerta.tiscalinet.it...
Harumpel
"G." <g...@nomail.com> schrieb im Newsbeitrag news:gYfa9.12189$6m61...@news04.bloor.is.net.cable.rogers.com...
Dann Corbit
news:akp7vv$t8n$07$1...@news.t-online.com...
> Using object-orientation in chess programming DOES NOT MAKE ANY SENSE !!!
"Junior" by Amir Ban and Shay Bushinsky has won a world microcomputer
championship and also been at the top of the SSDF list. Junior also won the
2000 Cadaques tournament.
Junior is an OO chess program written in C++.
So perhaps the idea is not totally senseless.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm
Russell Reagan
> Using object-orientation in chess programming DOES NOT MAKE ANY SENSE !!!
I don't think you should make a generalized statement like this. Object
oriented programming offers many benefits. The main benefits that I like is
that you can create a program that works, with relatively few (if any) bugs,
you can make significant changes in the program without too much headache,
and you can develop your program in less time.
What does this mean for chess programming? It means that you have more time
to work on new ideas. It means that once you come up with a new idea, you
can add that new idea to your program without having to rewrite half the
code. You can do better testing of your modules to make sure they work
correctly. This basically means that you have more time to experiment with
new ideas you have for making your program stronger, and in the long run,
that will give you a better chess program than if you wrote it all in
assembler and it was insanely fast.
Think about it for a moment. Speed isn't the number one thing to strive for
in a chess program. Let me give you an example. Let's say you have a program
that you wrote in a non-object oriented manner. It searches using the well
known techniques. It can search a million positions per second, and has a
branching factor of about 3 (the best in the world are between 2 and 3). Now
let's say that I have a program that has all of that same well known stuff
in it (plus a little more), but my program does a whole lot of object
oriented stuff and it much slower than yours. My program only searches
100,000 positions per second, but I had extra time to spend thinking about
and testing new ideas for pruning methods. As a result of my extra thinking
and testing of ideas, my program has a branching factor of 2.5. Your program
will search 14 plies ahead in about 4.7 seconds, and my program will search
14 plies ahead in 3.7 seconds. In a game at a standard time control, your
program will be able to see a little more than 17.3 ply ahead during each
move (at say, 40 moves in 2 hours time control). My program will be able to
see about 18.2 plies ahead in that same time, even though it is 10 times
slower than yours.
The point is that speed isn't the number one goal in making a chess program.
In reality, my program might be only 10% slower than yours if it's totally
object oriented and uses lots of dynamic things such as virtual/abstract
base classes and dynamic memory allocation and so on. If my program was only
10% slower, then it would kill your program. So maybe you need to rethink
your statement than using object-orientation in a chess program does not
make any sense. IMO, not using it doesn't make much sense, because you can
always use OOP to get done quicker and test new ideas, then once you find
out new ideas that work, you can write them in C with assembler if you'd
like (because you'll have more time left to do this kind of thing). Not to
mention that you can inline most of your object oriented stuff anyway, and
it won't be any slower. You can write in an object oriented way without
sacrificing speed, and still get many of the benefits of OOP. I bet when you
think of "object oriented" you think of C++ or Java, but the truth is that
you can write in an object oriented (or "modular" if you prefer) style in
almost any language. In some languages it would slow you down because of
extra function calls (even though this would be very little of a slow down)
but in C/C++ you can inline your code, and suffer no penalty, and get all of
the benefits of OOP.
Russell
Robert Hyatt
> "Harumpel" <theo....@t-online.de> wrote
>> Using object-orientation in chess programming DOES NOT MAKE ANY SENSE !!!
> I don't think you should make a generalized statement like this. Object
> oriented programming offers many benefits. The main benefits that I like is
> that you can create a program that works, with relatively few (if any) bugs,
> you can make significant changes in the program without too much headache,
> and you can develop your program in less time.
It is just a case of the old "you can write sloppy code, or good code,
_regardless_ of the programming language you use. OO code, done right
for a chess engine, is every bit as efficient as normal C programming.
Done wrong, it can be horribly slow... as can C programming done wrong.
> Russell
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
Kym
Why the heck not!
OO optimizing compilers make very good fast code.
Digital/Compaq/HP OpenVMS compilers on Alpha made really slick machine code
in full optimizing mode.
Structuring an OO chess program is fine.
You can write slow aseembler, C , C++ or Java. You can also write good
code, depends on your coding skills.
Java may not be the best choice for reasons of raw speed (Java Virtual
Machine + array/bounds checks and other Java overheads is usually 1/2 the
speed of C++ etc.)
It would be interesting to see a compiled Java environment (maybe via G++
V3.x).
C++ is fine for chess. I think 64bit architectures and good optimizing
compilers mean that an OO chess program would be equal to C or even
assembler (human coded).
Russell Reagan
> Are you by any chance in Southern California, Russell?
> If so, please forward my resume ( http://www.guymacon.com )
> to your employer and see if he needs my skils. The above is
> *exactly* what I want to hear from a software engineer I work
> with. I have learned from experience that the above is the
> right way to develop software.
No such luck. I live in Texas and I'm currently going to school, and working
part time at a library. I've just been around a lot of people who have given
good advice as far as the method for developing software, and I've read some
good books on the topic. Maybe it doesn't take a CS degree to "get it." :-)
Russell
Jyrki Alakuijala
>
>>OO optimizing compilers make very good fast code.
>>
Much of the high performance code, including the Linux kernel, is still
written in C. That is not by accident.
>>C++ is fine for chess. I think 64bit architectures and good optimizing
>>compilers mean that an OO chess program would be equal to C or even
>>assembler (human coded).
>>
Perhaps the poster of the original article is not looking after high
performance, but only something to start experimenting. Writing a chess
program is a good learning experience, and perhaps he is after that. If
that is the case, he might be interested in a computer chess program
written in python, which is more abstract and easier than Java and C#.
http://www.kolumbus.fi/jyrki.alakuijala/pychess.html
--Jyrki
Russell Reagan
news:3D7E5ECC...@findme.from.google...
> Much of the high performance code, including the Linux kernel, is still
> written in C. That is not by accident.
Indeed. Programmers are lazy by nature. Why would anyone rewrite the thing
using OOP when it runs fine as it is? Besides, I don't imagine that the
linux kernel is a good candidate for being forced upon an OO model. Just
because "it was true 5 years ago" doesn't mean it's true today, especially
in the highly volatile medium of the computer world these days. Heck, just
because it was true a week ago doesn't mean it's true today. I personally
think this "OOP is slower" bit was true in the past, but I don't really see
it being that way now and especially in the future. C compilers have been
developed for decades now. Maybe there's room for improvement...maybe. C++
compilers and Java compilers are not as mature. There is more room to grow
in those two areas, and they are still (well, C++) about as fast as C.
Russell
Kym
news:3D7E5ECC...@findme.from.google...
> >
>
> Much of the high performance code, including the Linux kernel, is still
> written in C. That is not by accident.
Well 20 years ago most OS kernel code was assembler!
When Digital > Compaq > HP first brought out VMS it was coded
in either Bliss or Macro32 (Bliss was a high level assembler or low
level language - take your pick - macro was the assembler).
Later much of VMS (OpenVMS) was redone in C and C++.
Side note: VMS became OpenVMS at V5 as a marketing name change,
OpenVMS was NOT the Alpha version of VMS (a common myth).
OpenVMS was/is the OS on both VAX and Alpha HW.
Turns out that a good compiler can build (optimise)
better machine code than most people can code by hand.
Back in the 80's and even more in the 90's (Alpha) Digital
put a shitload of R&D into compiler machine code optimizations.
If you got a machine code listing of unoptimised C/C++ code
then recompiled with full optimizations and compared the listings
it was almost impossible to recognise what the highly optimised code was
doing.
The optimised code was much much smaller and tighter than the unopt. code.
It was even harder to relate the optimised machine code to your C/C++ code.
C++ was orginally implemented as a pre-processor for you fav
C compiler, so why should C be better than C++?
> >>C++ is fine for chess. I think 64bit architectures and good optimizing
> >>compilers mean that an OO chess program would be equal to C or even
> >>assembler (human coded).
>
> Perhaps the poster of the original article is not looking after high
> performance, but only something to start experimenting. Writing a chess
> program is a good learning experience, and perhaps he is after that. If
> that is the case, he might be interested in a computer chess program
> written in python, which is more abstract and easier than Java and C#.
Java performance is a problem for two reasons:
1. JVM adds another layer between compiled code and the native HW
2. Lots of runtime checking, which is a feature of the language/JVM
Most C/C++ compilers allow you to turn off runtime bounds
checking etc. and real slick machine code.
Jyrki Alakuijala
>
>Turns out that a good compiler can build (optimise)
>better machine code than most people can code by hand.
>
This has been true since the OoO (Out of Order) execution was taken
into wide use. That means the last seven years!
>C++ was orginally implemented as a pre-processor for you fav
>C compiler, so why should C be better than C++?
>
It is mostly the same reason why Fortran code is still usually faster
than C. The lower the abstraction the more control you have, the more
optimizations the compiler can afford to do etc.
For some purposes, simple C++ programming can produce faster code than
simple C programming. Especially templated algorithms can provide efficient
code with little work. For example, see
http://theory.stanford.edu/~amitp/rants/c++-vs-c/
However, usually the C++ factor comes into play and slows things down:
http://www.eventhelix.com/RealtimeMantra/Basics/ComparingCPPAndCPerformance.htm
Especilly, the orthodoxic text book OO-programming leads usually to a
bad physical
architecture, while the simple-minded functional or imperative
programming produces
acceptable overall architecture. But architecture is another issue, now
we are just
discussing the performance.
>Most C/C++ compilers allow you to turn off runtime bounds
>checking etc. and real slick machine code.
>
Which flags of the C/C++ compiler do you use to turn of the
runtime bounds checking? I am still using old-fashioned C/C++
compilers, like gcc 3.0, visual c++ 6, that do not perform these
checks. Perhaps you have another state-of-the-art compiler?
Seriously, none of the C/C++ compilers add bounds checking.
Even fewer do bounds checking by default.
I have been writing high performance code professionally for 12 years
and I still avoid OO approaches in performance-oriented code. Sometimes
I use STL in prototyping, but usually it is a better idea to finally
rewrite
for the specific case.
--Jyrki
Russell Reagan
> I have been writing high performance code professionally for 12 years
> and I still avoid OO approaches in performance-oriented code.
What professional project are you working on that you need that extra tiny
gain in speed that costs you more time and debugging in the long run? I have
a feeling that it's either your personal preference, or you're working on
something that is the exception rather than the rule.
Russell
Jyrki Alakuijala
>What professional project are you working on that you need that extra tiny
>gain in speed that costs you more time and debugging in the long run? I have
>a feeling that it's either your personal preference, or you're working on
>something that is the exception rather than the rule.
>
Most recently I have written a commercial (anti-OO) chess
engine with Java. With java, avoiding the oo features seems
especially important for performance.
However, most of my professional life I have been writing visualization,
image processing, simulation, data compression and optimization
algorithms for radiotherapy. The speed of these algorithms is,
unfortunately, a question of life and death. The people doing the
treatment planning cannot afford to wait for weeks for computations.
Also, almost all the computations are tradeoffs between accuracy
and speed. If we reduce the speed of the algorithm, we will obtain
lesser accuracy for the same amount of time. For being able to
sleep well, I need to do my best at both the speed and accuracy.
I have written a lot of architectural code, too. I started out as an
OO enthusiast, but saw the problems after few years. Still, I use
OO where I see it appropriate. When you use a full-blown
OO-approch, the physical design will suffer and compilation
times will easily be problematic in a large scale engineering
effort. That is when the code size exceeds million lines.
Especially, the concept of inheritance, as implemented in C++
leads to these nasty dependencies between modules. Naturally,
with a more modern language, such as Python, these problems
are minor.
Also, I have had the opportunity to compare two similar
projects. One was a modern C++ project and the other being
a Fortran/Tcl/Tk project. The complexity level was similar.
The performance of the project teams was quite nearly
the same, with the exception that the learning curve for
the C++ project was much worse due to the widely
used high-level abstractions. Maintenance is however
somewhat more costly on the Fortran side, balancing the
teams. This is unbelievable for young software engineers
who have learned that the tool is everything. However,
it is usually the complexity of product requirements
that create the problems, not the engineering tools.
Jyrki
ShoulinPriest
is pretty bad by any standards. But at least it can play and thats what counts.
It reminds one of the Star Trek where Spock has programmed the computer to play
chess and he wins. He should expect draws if he plays as well...
So maybe the reflection of the play is in your strength as a player.
Kym
In that episode it was 3D chess. Kirk was being framed for a crime he did
not commit. Spock realised that someone had tampered with the computers
because he was able to beat the machine when he knew it was unbeatable.
This led Spock to uncovering the plot to frame Kirk.
Now... Which news group was this? ;-)
"ShoulinPriest" <shouli...@aol.com> wrote in message
news:20020921025949...@mb-fm.aol.com...