Author: Daniel Clausen
Date: 02:19:10 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. Hard to say someting is "bad OO programming" based on a list of classes. (although sometimes it is very easy :) I assume Volker uses C++, a language which supports many software-design paradigms, where the OO approach is just one of them. Whether it's clever to use just one of the supported paradigms and ignore all the others.. I really don't know.. Not quite sure what you mean with "slow from design": if you're referring to classes for square, piece etc, then yeah, your engine will be kinda slow, but when it comes to classes for evaluation for example, not really. Maybe Volkers evaluation methods are statics and then the class around it more or less serves as a wrapper. And then they're exactly as fast as some freeflying function. Maybe Volkers piece classes _are_ basically enums with accessors defined in the headerfile, so they can be inlined and are as fast as your C-enum. But maybe the piece class provides additional methods like toString(), which converts your enum 5 to 'White Knight' or something like that. >Take hashtable: allocate at startup (reallocate as option) then 2 functions: >store and retrieve. Does it need its own class? NO. Depends on what your requirements. Maybe he wants to be able to use multiple HTs because his engine wants to support engine-engine matches internally? Maybe something else? Who knows? (well, Volker I guess :D) >Const... (why not >const.h file?). I assume his Const-class just contains some lookup-arrays and stuff like that. In my engine I have the arrays for PSQ-values in a class context (with a static init() method, which initializes them) No biggie here. The class is just used as a namespace. (you could as well use the namespace-keyword for that) > Square and piece is just enum... why waste time to call its class is beyond my >understanding. Who knows? Maybe Volkers square and piece classes are more than enums? (see above for the toString() example) In my C++ engine, squares and pieces are typedefs/enums. Where I use a class though is for the movelist. In fact, my movelist is a STL vector. I don't have to know how many (pseudo-)legal moves can occur in a position. The STL-vector will increase its size, when there are more than its initial size. Setting the initial size makes sure that the vector doesn't have to reallocate itself when adding a new move. Board is of course also a class, but it's more used like a struct, that is, most instance members can be accessed directly. But it has methods like toString(), toFEN(), fromFEN() etc. The same could be done in C with a struct and related functions, which take a 'struct Board *' as their first argument. I just happen to like the C++ version better, although it's basically the same from a design POV. ><rant> I hate watching those sources where *everything* is wrapped in some >useless class - is it just me?</rant> "I hate watching those sources where *everything* is a useless list or part of a one - is it just me?" Well, maybe it's not Lisp's fault but just me. Or the problem I'm trying to solve just doesn't fit that language. Having said that, I'm not quite sure why Uri starts talking about classes. He could simply use normal structs in C. You don't have to choose between "having global variables" and "put everything in C++ classes". But maybe I misunderstood him. Sargon
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.