Author: Anthony Cozzie
Date: 07:32:27 08/10/04
Go up one level in this thread
On August 10, 2004 at 02:59:10, Andrew Dados wrote: >On August 09, 2004 at 18:26:10, Volker Böhm wrote: > >>Hi Uri, >> >>IceSpell has lot of classes for everything. It has a class for >> >>Square >>Piece >>Board >>Value >>Direction >>Position >>Evaluation (one class for every piece) >>Move-Generation (one class for every piece) >>SearchStack (holding the local information) >>Search >>Time-Control >>Move >>MoveList >>Killer >>History >>... >>(I don´t remeber everything). >> >>That had speed issues. Thats why Spike does not have those basic classes like >>Square, Piece, Value, Direcion, Move, ... >> >>Spike has got the following classes: >> >>1. A "Const" Class holding only constants that do not need memory (no const >>fields). Nearly every class is derived from the const class giving it the >>opportunity to access all relevant constant values. >> >>2. A "Const-Field-Class" holding basic lookup tables >>3. A Move-Generator-Class (only one) >>4. An Attack-Table Class >>5. A Board-Class >>6. An Evaluation-Class >>7. An Incremental-Evaluation-Class >>8. A Pawn-Hash Class >>9. A Hash Class >>10. A SEE Class >>11. A simple SEE Lookup-From-Attack-Table class >>12. A Search Class >>13. A Ponder Class >>14. An Interface Class (Supporting Winboard and UCI) >>15. A Time-Control Class (Controls that time does not exceed limit, calculates >>the "base" time and a maximal time for the current move. The base time is only >>calculated by time settings and amount of moves done) >>16. A Timefactor Class (Calculates the current time factor, the time-factor is >>only dependant of game situation and search issues (pv-change, value-change, >>...)) >> >>Maybe I forgot one or two. Some Classes are large, this is not good in a design >>point of view. But for Chess speed is most relevant. >> >>Greetings Volker > >IMO above is a typical example of bad oo programming: classes for everything. >Art for art imo. very scholar and 'proper' and sloow from design. Passing >pointers everywhere. > >Take hashtable: allocate at startup (reallocate as option) then 2 functions: >store and retrieve. Does it need its own class? NO. Ponder... Const... (why not >const.h file?). > Square and piece is just enum... why waste time to call its class is beyond my >understanding. > ><rant> I hate watching those sources where *everything* is wrapped in some >useless class - is it just me?</rant> > >-Andrew- Well we can argue about software engineering till the cows come home ;) My personal view is that a chess engine is a small enough project that speed should take precedence over abstraction, but that a certain amount of abstraction can (and should) be done for free. This means inline functions instead of macros, but not tons of inheritance and virtual classes and such. If I had to do it personally, I would have classes for Piece, Move, Board, Thread, Frame (necessary for iterative search), Hashtable, Interface, and Timecontrol, which is really not too far off from Volker's design. Not too surprisingly, I think his organization has improved a lot from IceSpell to Spike. I am thinking about switching Zappa from C to C++, primarily to make it simpler and easier to update. I don't think it would take that long (it could be done incrementally), and the code would be somewhat cleaner. Some of it is just a matter of taste: do you prefer int move; #define m_f_loc(A) ((A) & 0xFF) ... or class move { private: int move; public: inline int m_f_loc(void) { return move & 0xFF; } } I am fairly sure these will generate the same assembly. anthony
This page took 0.01 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.