Author: Bo Persson
Date: 07:44:18 08/02/03
Go up one level in this thread
On August 01, 2003 at 12:46:42, Russell Reagan wrote:
>On August 01, 2003 at 06:14:27, Bo Persson wrote:
>
>>Of course it can be empty! The default constructor Piece() results in an empty
>>position.
>
>I guess I would call this something else then. Like maybe SquareContents instead
>of Piece. It seems more correct that SquareContents could be empty than a Piece.
:-))
I actually did that initially, but after a while I felt too confused about where
it could be a SquareContents and where it *had* to be an actual Piece. So I
decided to invent the piece Empty (== 0) and place that on all free squares.
It actually took me quite a while to get from there to skipping the Empty
constant and use Piece() instead. If I remember correctly, it came from me
realizing that doing a null_move could be expressed as:
Board.Make(Move());
So if Move() can be a null_move, I guess Piece() can be a null_piece. Well...
>
>
>
>>My Square class doesn't hold pieces, but is used to index the board. The board
>>contains an array of pieces (and some bitmaps as an alternate representaion).
>
>This is basically what I do too, but I don't think you can hide the
>implementation very well without losing a little bit of speed. For instance, if
>you truly hide the implementation, then you should be able to take your Board
>that uses bitboards and turn it into an 0x88 based Board without having to
>change Square or Piece or anything else. If you use a 64-element array in your
>bitboard based Board, then it won't work correctly when you move to a
>128-element array for 0x88 (assuming Square is just a wrapper for a board
>index).
I haven't tried that, I have used bitboards all along.
I can see though that I would have to modify the Square class if I change the
Board layout, because it "knows" that there are 64 bits in a Bitboard, enum {
a1, ..., h8 }, and that the Board holds the same number of Pieces. Or maybe an
x88_board would have its own index type? Haven't tried that.
>
>That is my point. Writing wrappers for these things is fine, but to really hide
>the implementation as an OOP purist would have you do would mean your Board
>class would either be sub-optimal or Square would have to know how Board worked.
>
I am not a "purist", or "fundamentalist" as some people seems to be, I just like
formulating class abstractions for the program entities. Could be because I once
learned programming using Simula ("CS101", 1977).
The subject of this thread is "Any reason to use C?", suggesting that adding a
class of two would severely impact the speed of the program. IME it does not,
sometimes it can even improve the speed. To me these wrapper classes improves
the readability of the code, which sometimes makes me see things that I can
improve. It also sometimes helps the compiler to find errors or optimization
opportunities that it could not see if everything is just typedefs for int.
When I call foo(piece, square) in one place, and foo(square, piece) in another,
the compiler will tell me if piece and square are classes. If they are just
typdefs for int, I could have to run the debugger all night before I spot the
place.
For the compiler, a function foo(piece&, square&) can sometimes be optimized
better than a function foo(int&, int&), as the two ints can theoretically
overlap (be the same variable), while piece and square cannot because they are
different types. Some compilers use this to decide which variable can be put in
registers.
Bob writes Crafty in C partly because he wants it to be easily portable to a
large number of platforms. If you write in C++ you are limited to platforms with
good C++ compilers, mainly Windows and Linux. I would write for Windows anyway,
so I don't have to care about that.
>
>
>>It doesn't have to be slower, and I actually get less of a headache when the
>>code is "pretty".
>
>Part of the reason that bitboards work is because many parts of the program know
>that bitboards are being used. Same goes for 0x88 or 16x16 or whatever approach
>you use. If you hide the knowledge that the board is using bitboards inside the
>board class, many of the advantages go away. Take evaluation for instance. I
>don't think "evaluate" is something a board does, and you're going to have a
>hard time evaluating efficiently if you don't know what kind of board
>representation you're using.
I guess it is hard to evalute the board position if you don't know what
information is available. :-)
I see some kind of duality in the board - evaluation relationship (is that valid
a sentence?), in that writing the evaluation I must consider what info is
available, and how (including "how fast"). If the Board takes a week to answer
"How many squares around the king are attacked by multiple enemy pieces", the
evaluation might choose not to ask. Similarly, the Board may contain some
structures that are there just because the evaluation needs to know that info.
That makes it hard to be totally abstract.
I do have some latitide though in an interface, because when the evaluator or
the move generator asks the board for the bitmap EmptySquares(), the board can
either return an incrementally updated value or compute it from ~(WhitePieces |
BlackPieces). Which is the fastest depends on the particular computer, and how
often it is used.
>
>Part of the OOP approach is that you model the real world problem you're trying
>to solve. In the real world, you don't have empty pieces, or boards that
>evaluate themselves.
I have an old dedicated chess computer, doesn't that count as a self evaluating
board? :-)
>If you're going to forget about all of that and start
>creating fictitious things like empty pieces, then I think my point is shown,
>that OOP is only applicable to computer chess to a limited degree.
Could be, as usual it depends on how you define OOP. That's religiuos...
Anyway, the question was whether C is *always* much faster than C++. My answer
is "no". Good C can be better than bad or mediocre C++. Good C++ can be better
than bad or mediocre C. You choose!
Bo Persson
bop2@telia.com
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.