Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: what classes all the serious C++ chess programs have?

Author: Andrew Dados

Date: 02:15:52 08/10/04

Go up one level in this thread


On August 10, 2004 at 03:41:12, Uri Blass wrote:

>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-
>
>Do you use classes?
>
>What I hate to see is that my code becomes slower.
>I have a lot of global variables and I believe that it is a wrong design if I
>care about speed.
>
>I do not feel bad with the fact that my program is not optimized to be the
>fastest but I do not like watching it becomes slower.
>
>Adding only class for time varaibles did movei slower.
>Maybe it is because of some random compiler optimizations but I do not like it.
>
>I know that difference in speed(in the order of 5% or less than it) is not an
>important difference but I dislike seeing it.
>
>I did changes in the past to make movei slower.
>At some point I decided to get rid of incremental evaluation that caused me bugs
>but after doing it Movei became slowe by 5-10% and I felt the need to do other
>improvements in pruning and evaluation and based on results the improvement
>clearly more than compensated for the loss of speed so I have no problem to live
>with it.
>
>Uri

For me classes are very useful to encapsulate some atomic functionality or
'entiety' within the program. For example parts of GUI make great, clean
classes. Or things like graphic shapes.

Now with chess engine you experiment a lot. You never know what info will be
used where - parts of eval in search, moveordering info in possibly incremental
move generator, then maybe the other way. So class design from ground up makes
little sense: sooner or later you start writing impromptu methods accessing
previously private fields and end up with tricly and mangled design to test some
pruning idea. I believe good modular design with functions is much easier
tweakable.

You have to answer for yourself if lots of structures and lots of globals are
bad for you. They are fast, easily accessible, and there is nothing inherently
wrong with them. After all class is just a pointer to (struct+some methods).

Now when you want to go SMP one day all search-related globals will have to go.
Then you'll have to either encapsulate them to classes or structs anyway.

If you think Killers->update(*move) is better programming then UpdateKillers()
then use classes :)

Of course that is all just IMO
-Andrew-



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.