Reflections of a Newbie

[lauriet]

Disclaimer: If you are a seasoned chess programmer you will know this already.


I have written my first engine as an exerciser in learning. It has been very educational
and I have realised that you don't know how to write a chess program until you have written a chess
program. I have spent lots of time testing and modifying and getting advise and opinions here from other
authors. (Thanks to everyone)

I now realise that Im stuck with the original choices of data structures and I can't progress much further with it.
Many people here have advised that your first goal is to be bug free. This is so true, because a bug may not crash the program
or raise an exception, It may just make the program play less well than it should. Debugging this is quite difficult and
time consuming. (To debug a program you need to be smart enough to write a bug free program....therefore you are not
smart enough to debug your program)

SO.....its time to start from scratch, knowing what I know now.

These are all tips that you hear again and again.....they apply to all programming but I feel more so with a chess program.
For my next program I will take them to heed.

Its all too easy to sit and start typing and then see if what you have written is what you want. "Thought before keyboards"
You need to plan each function to do one thing and do it well.
Plan to debug..how will you test each function ?
I have just discovered that Free Pascal has "Asserts" so on entry to a function I will make sure my parameters and the
"state of play" is what I expect. Use them early and use them often.
You need to stepwise write and test each section one at a time. Don't make 2 changes and then test.
Write your first program in order to learn how to do it knowing you will write another one.
Use pencil and paper to design your data structures and don't be in a hurry. Mull over them and try to think of
the consequences of them. This is where you need to know how a whole program works and appreciate how each section interacts
with other sections.
Keep global variables to a minimum, but don't jump through hopes to do so. If a variable is used in most places
its dumb to pass it as a parameter to every function.
Read this website...there is no such thing as an original idea.
Read Bob Hyatt....he usually says "yes we tried that in 1987 on cray but....."
Don't copy verbatum another program, you learn nothing. Understand the alorithym and then write it.


If you have more tips, please add to the list.

Regards
Laurie

[Henk]

Maybe some functionality you have to rewrite ten times or even more but sometimes you find out that first implementation was best.

[jdart]

Maybe I'd add, besides having correct code, you need to have a disciplined process to measure improvement in playing strength. This IMO largely accounts for the progress we have seen in engines in the past 7-8 years, since Rybka popularized the idea of cluster testing using actual matches.

--Jon

[CheckersGuy]

First one should have a flawless MoveGeneration. To test this one can compare Perft numbers with already verified Perft numbers for a given depth.

[brtzsnr]

In addition to what was said before: try to make your program as simple as possible. Playing 30K games to prove that a patch doesn't regress might not be worth it, but in a long run the reduced the complexity of your program pays off. A simple good metric for code complexity is LOC, assuming you don't cheat, for example, by putting 10 lines on a single line.

https://en.wikipedia.org/wiki/Occam%27s_razor

... the simplest hypothesis proposed as an explanation of phenomena is more likely to be the true one than is any other available hypothesis, that its predictions are more likely to be true than those of any other available hypothesis, and that it is an ultimate a priori epistemic principle that simplicity is evidence for truth.

— Swinburne 1997