I agree Jon, that has got to be one of the most challenging problems a developer will face.So I had to work backwards, with an assembly-language debugger, to the point where the bad code was generated.
Thanks Lucas! Regarding your code suggestions, I do make the code "scream at me" when the board state is illegal. In the first two lines and the last line of the Board.PlayMove method.Well done. Debugging is an under-rated art. It is painful and unrewarding, but true programming skill is learnt debugging, much more so than writing code.
Code: Select all
Debug.Assert(Engine.Move.IsValid(Move));
Debug.Assert(AssertMoveIntegrity(Move));
// ...
Debug.Assert(AssertIntegrity());
You are correct about a need to generalize code. My priority is this regard is to eliminate all the color-specific code I have in my evaluation method. Also, remove duplicate code that controls sliding piece move generation and attack counts. Too much copy / paste / renaming of variables there. I need to generalize that code.you are missing the potential for generalisation
How frustrating, Dann, when developers misuse data structures (treating a by-val struct like a by-ref class) and create a jigsaw puzzle for the next developer who has to maintain the code.It turned out that there was this struct that was passed down, down, down, down way down deep
Mike, great story. Reminds me of a story my boss told me at my first job out of college. His experience in accounting and computers went back to the 70s. He explained the company would double-check account balances by having the day team do their work on paper, the day mainframe operator run the deck of cards (an accounting calculation), then ensure the two totals matched. Same procedure with the night team. Only the night mainframe run produced a different number. Every other method matched: two by-hand and the day mainframe calculations. Turned out one of the cards was shorter than the others. The day mainframe operator tilted the cards to the left and knocked them on a desk before feeding them into the mainframe. The night operator tilted the cards to the right. The misalignment produced different results for the computerized accounting calculation. Ridiculous!Banks often keyed an incorrect amount for check that was cashed. It was literally looking for needle in the haystack
That's a very good point, Ras. I will fix that. So perhaps I will add a limit check after all. Though I may locate it in the MoveHistory.UpdateValue method and keep the brute-force, unforgiving bit mask code in the Move.Set methods.The bugfix however seems to have another issue because the used history value will be somewhat off now if the bitwise & prevents an overflow.
That is an incredible story, Dann! Thanks for sharing.In the end, we found out his account number was the binary compliment of Exxon of Florida's and a programming error had caused the problem. Now there's a bug for you.