If You Were Starting From Scratch

[mjlef]

OK, I have started a new chess program, and was wondering what you all would do differently if you were starting from scratch!

So far, it is going well. It should be 2-3 times faster than the old Pascal program, both from compilers making faster code, and better data structures.

Mark

[Steve Maughan]

Mark,

WOW - big step! Here's what I'd do (actually have done - I seem to have rewrite-titis) when re-writing:

1. Minimize the use of global variables i.e. start creating data structures that can be easily used when you eventually convert it over to MP.
2. Try to create a test procedure for every procedure you write i.e. the #1 aim should be to create a bug free engine
3. Don't assume that anything is a given and test anything that may impact strength - e.g. does extending checks really make sense? Test it!
4. I'm sure you've done this already but make sure you have a board representation that will work well for i) generating move, ii) making and unmaking moves iii) evaluating positions

Is the new engine written in Pascal? Which compiler? Do you have a name for the engine?

Cheers,

Steve

PS Are you still based in Orlando?

[nczempin]

PS Are you still based in Orlando?

Yeah, that's the first thing I'd change.




Just kidding.

[mjlef]

l have a good position structure well suited to SMP, I think. I am still not sure how best to handle move history for rep detection across multiple processors. but it seems to be going well.

Mark,

WOW - big step! Here's what I'd do (actually have done - I seem to have rewrite-titis) when re-writing:

1. Minimize the use of global variables i.e. start creating data structures that can be easily used when you eventually convert it over to MP.
2. Try to create a test procedure for every procedure you write i.e. the #1 aim should be to create a bug free engine
3. Don't assume that anything is a given and test anything that may impact strength - e.g. does extending checks really make sense? Test it!
4. I'm sure you've done this already but make sure you have a board representation that will work well for i) generating move, ii) making and unmaking moves iii) evaluating positions

Is the new engine written in Pascal? Which compiler? Do you have a name for the engine?

Cheers,

Steve

PS Are you still based in Orlando?

[bob]

l have a good position structure well suited to SMP, I think. I am still not sure how best to handle move history for rep detection across multiple processors. but it seems to be going well.

Mark,

WOW - big step! Here's what I'd do (actually have done - I seem to have rewrite-titis) when re-writing:

1. Minimize the use of global variables i.e. start creating data structures that can be easily used when you eventually convert it over to MP.
2. Try to create a test procedure for every procedure you write i.e. the #1 aim should be to create a bug free engine
3. Don't assume that anything is a given and test anything that may impact strength - e.g. does extending checks really make sense? Test it!
4. I'm sure you've done this already but make sure you have a board representation that will work well for i) generating move, ii) making and unmaking moves iii) evaluating positions

Is the new engine written in Pascal? Which compiler? Do you have a name for the engine?

Cheers,

Steve

PS Are you still based in Orlando?

The simplest approach is to simply copy the move history for each thread. Then they can overwrite the parts they modify and still detect repetitions, without interfering with other threads that are searching a different part of the tree...

[BubbaTough]

I would say first thing is to pick your chess program philosophy, from which much of your design will spring. Maintaining true to the philosophy you choose for the lifetime of the program is my fundamental recommendation. The three main choices are:

Fast & Dumb: Crafty is a master of this. The reason (in my opinion) Crafty is stronger than most programs despite everyone getting free access to all its ideas and implementation details is that the program stays true to the "Fast & Dumb" philosophy very strictly, only adding things that slow it down if they can be demonstrated they are clearly needed. This approach can end up with hard to read, hard to maintain chess programs, and is probably best for people that like to fiddle with optimization (many people here have lots of advice on avoiding this, but in my opinion its just true).

Slow & Smart: You are going to be putting a lot of knowledge, and optimization is less important here. All that knowledge carries different implications for design and data structures and such, since that knowledge may be used in not just eval, but move ordering, extensions, reductions, pruning, etc.. If you care about the strength of your program, this design takes a lot of careful work because you can't make things too slow and still get good results. I don't think this approach is inherently weaker than Fast & Dumb, but it is probably a longer process to get to a strong program because while optimizations in the Fast & Dumb approach can often be shown to be good with a minimal set of tests, testing out a new idea for using chess knowledge is long and difficult and often relies on using your own intuition as a crutch. Of course, some people (like me) find this process more fun than optimizing for speed. Of course, if you really like trying out new ideas and maximizing results is not your main goal you can go with...

Toolbox: This approach concentrates on modular, readable, maintable code with the expectation that you are going to be trying out a lot of crazy stuff. Generally this approach will not be as strong as the other two, since you often sacrifice bits of performance to keep it easy to add/subtract functionality. The main difference between this and the Slow & Smart philosophy is that the slow and smart approach commits to the type of smarts it can support with ok performance while Toolbox is more general (even slower, but trying out new ideas is easier).

Anyway, in my discountable opinion, the reason most amateur programs are much weaker than the top notch open source programs is not that the coders are worse, or spend less time, or know less about chess, or have less testing resources, or... (though those and many other things are of course factors) but that most people get tempted into a hybrid. They build a simple engine, spend a lot of time on fast move generation (going down the Fast & Dumb route) and then start trying so cool chess ideas, and keep a bunch on them (slow & smart). Then they decide that to add some features to make adding and subtracting concepts easier (Toolbox). Then end result is code that combines the worst features of each approach since it is not that fast, is complicated and hard to maintain, has lots of bugs, etc..

-Sam

[Edsel Apostol]

Nice analogy Sam. Amateur programmers can learn from this post of yours.

Edsel Apostol (Twisted Logic)

[Michael Sherwin]

Then there is the RomiChess way. First you start with a slow, dumb programmer that is not very good at implementing anything new!

[mjlef]

Then there is the RomiChess way. First you start with a slow, dumb programmer that is not very good at implementing anything new!

I am shooting for "slow and dumb"!

You know, writing a second chess program is much, much easier than the first.

Mark