Author: David Dory
Date: 14:58:46 02/07/04
Go up one level in this thread
On February 07, 2004 at 04:39:12, Maurizio Di Vitto wrote:
>Big thanks to Mr Dory,
>What do you exactly mean when you said that I should make the History class as
>closely as possible?
>Then I tried to write this UnMakeMove function, but the basic Idea about that
>function is right?
>How could I test it?
>
>Then I tried to write a very simple Search function, with a MinMax system, but
>as you can guess, I received the famous Windows error message maybe because I
>used a lot of pointer and I made some mistaked. Could you give some tips about,
>I know the two system MinMAx and AlphaBeta, what should I do to begin and to
>test that all my functions work good?
>THanks a lot again.
>MAuriio Di Vitto
>Italy
Here's what I'm doing for testing. Whenever possible, I code up the function I
want and test it without involving the complexities of the search, and full
evaluation. It allows a lot of easy bug killing from the start.
On the prototype program, I input the moves for both sides, and believe me I
give it all kinds of illegal moves, wrong key presses, I mean lots of sh*t.
Does the program handle that user input (abuse, really) OK? Does IsLegal()
verify the opponent's move's correctly, including castling and en passant under
difficult board conditions? Does it also confirm legality/illegality for all the
program's moves from GenMoves()? I use a pseudo legal generator so they have to
be confirmed if not culled by A-B.
So to test the UnMakeMove() functions, I just enter a bunch of illegal moves.
They are "made" by MakeMove(), then found to be illegal by IsLegal (which calls
InCheck() for help with check detection. Finally, the move is rejected and
UnMakeMove() is called, and all is put back in order.
By doing this enough times, I discovered a bug in re-setting my castling flags,
and a better way (I hope) of handling them, altogether.
I was amazed that you could code up all that work, without incrementally testing
it. I certainly can't do that. I'd be slammed in the face with the most horrid
list of errors, and have to face a sheer cliff of problems to climb, all at
once. Hate that!. "Meter by meter, life is sweeter", applies to programming
also, IMO.
In my opinion, as a hobby programmer only, that's your trouble. You're trying to
code up EVERYTHING at once. Instead, start with a few of the most important
things you want in that (any) function/Class, get it going, using dummy() {}
functions if/as needed. Then compile and run/test it. Then add some more,
working your way down from the most important items of code, to the least
important or smallest details. Always testing as you go. (I can still recall
clearly my instructor saying "put off the details", for the zillioneth time.)
The trick is to know just what those details are, but take a stab at it, and
you'll get better with practice.
What I meant by "close" is conceptually, a function or class should work hand in
hand with the code that use it. Like a glove fits a hand. I didn't see how you
Class would do this clearly, but that may well be my shortcoming, and not yours.
As an OOP programmer, I would make a better plumber. :)
David
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.