Author: Russell Reagan
Date: 12:04:28 07/30/03
Go up one level in this thread
On July 30, 2003 at 03:51:35, Bo Persson wrote:
>The Piece class is of course just a wrapper around your int or enum. Using lots
>of small inlined functions, you can get (at least) the same speed as with C,
>while making the code much more readable.
>
>I very much prefer code like
>
>if (Piece.isKing())
>if (Piece.isBlack())
>
>over
>
>if (Piece & KING_MASK)
>if (!(Piece & COLOR_MASK))
>
>because I find it much more readable. You also get all the Piece access code in
>one place, "piece.h". If you later find that your new compiler prefers "((Piece
>& COLOR_MASK) == 0)", you can change that in your isBlack() function and be
>done. Very convenient!
I like that kind of code too, but I run into problems. For instance, what is
your board? Usually I would use an array of int with enum values (wpawn, brook,
empty, etc.), but a piece (in real world object terms) can't be "empty". So now
we have to create a square class and have pointers to pieces or something, and
now we have to check pointers, and we are really just doing extra unneeded work
for the sake of keeping everything an object.
What good is using an object model doing if it's slowing us down and causing us
headache? I mentioned that the point of OOP was arriving at correct code, and
probably if we struggled with this for a while we'd arrive back at the array of
ints, which works very well, and is probably the simplest, fastest solution
anyway. "Keep it simple" is something I've had a lot of trouble doing when
trying to use OOP.
>It can be very beneficial to hide the implementation, because then you can
>change it if you find a better one later.
Not if there is no later because you bang your head against the wall for so long
trying to cram bitboards onto an object model that you've lost all life force :)
>Other classes shouldn't care that much about how Board is organized. If they
>want to know anything, they can ask the Board. :-) If it hasn't already got the
>proper "question" to ask, you will have to write one *in the Board class* not in
>the search or the move generator.
Tell me, how is a MoveGenerator going to efficiently generate moves if it
doesn't know the Board uses bitboards? I suppose we could create a kind of
abstract "piece list" or "piece set" class, which could be implemented either as
a bitboard or an array of pieces, but I think we digress here, creating extra
work for the sake of keeping an object oriented approach.
>What's wrong with correct code? :-)
>
>Also, I woudn't exactly say that computer chess is "solved" in any way.
I don't think I said anything was wrong with correct code or that chess was
solved.
>Maybe not. It also depends on what you mean by OOP. Some OOP "fundamentalists"
>reqiure polymorphism and dynamic allocation for everything. That's probably not
>very useful in a chess program. If you start out like:
>
>void makemove(piece x, square from, square to)
>{
> delete Board->Square[from];
> Board->Square[to] = new piece(x);
>}
>
>you are in deep trouble speedwise. Don't do that!
>
>
>To me, finding the right abstractions is also part of the fun. Getting classes
>like Piece, Square, Move, Bitboard, MoveGenerator, etc to work together without
>them knowing each other's internal representation (and without get/set
>functions), is great fun to me. Feels almost as good as seeing the piece images
>make good moves on the screen...
Good, maybe you can help me learn how to do it without having a stroke! :)
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.