[computer-go] Re: Languages and bugs

[Don Dailey <drd@xxxxxxx>]

Hi Crilly,

For some reason I've always had more castling bugs than en-passant (at
least ones I  knew about :-) I usually get  en-passant right the first
or second time.

But the  castling bugs can be  pretty funny.  There are  a few obvious
things  that you  do  wrong or  forget  the first  pass through.   For
instance in queen side castling I once had a program that would castle
through a  piece sitting on  b1 (or b8).   Simply forgot to  check for
occupancy.  There  was one bug  I had that  I didn't notice  until the
program was pretty  advanced, if the rook never  moved (which I tested
for) but instead  was captured and then recaptured,  the program would
castle with the piece that captured the enemy rook.

I've had programs:

    1. Castle in order to make a capture.
    2. Castle out of check even though I thought I was testing for this.
    3. Castle through a piece on b1
    4. Castle with a non-rook.
    5. Castle with a non-king!
    6. Castle with an enemy piece on the rook square.

The time it castle with a bishop on a8 was in order to give a check by
the castling bishop to win material!

The reason you make bugs like  this usually isn't because you were too
stupid to think of these cases, it's usually because you are trying so
hard to be fast  and clever.  One example I fell for  was that I would
implement a  move counter  to count  how many times  the rook  or king
moved so I wouldn't castle  illegally, but when something CAPTURED the
rook, the  counter didn't change  and to save  time that would  be the
only test.  Woops!

- Don



   From: "chrilly" <chrilly@xxxxxxxxxxxxxxxxx>
   Date: Wed, 11 Aug 2004 10:34:02 +0200
   Content-Type: text/plain;
	   charset="iso-8859-1"
   X-Priority: 3
   X-MSMail-Priority: Normal
   X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
   X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software


   >And  c++ is  one of  the cruftiest  bug prone
   >languages I know of (along with C.)
   >
   I am programming since 1989 chess, since 1994 as a professional. I have
   analysed since the beginning the bugs in my programs. The result: Only a
   very minor percentages of the bugs can be attributed to the features of the
   programming languages (C, C++, Assembler and Verilog in my case). The error
   rate is unrelated to the programming language. One makes a few typical C
   errors, but also a few typical Assembler errors....

   In the current project I have even a surprising result: Although programming
   the hardware/FPGA in Verilog is much more cumbersome/low-level, I make more
   errors in the high-level and much easier to programm C simulator. There is a
   simple psychological reason for this. It takes more than 2 hours for
   compiling/synthesizing Verilog. One stupid bug and the day is over. So one
   checks rather carefull the code before one presses the compile-button.

   According my statistics there is a clear relation with the difficulty of the
   concept/problem. The hot-spot in a chess-program is enpassant. It is
   unbelievable how many enpassant-bugs one can make. The Deep-Blue team never
   managed to produce a chip which had no enpassant-bug. Second place is
   castle. In both cases depend the legal moves not only on the current
   position, but also on the game-history. These bugs are not direct
   programming bugs (see example below). One has simply missed some special
   cases.
   I could imagine that Ko is the enpassant equivalent in Go.

   I have also noticed, that knowing were one makes the bugs does NOT change
   the bug rate in the next programm. One makes still enpassant-bugs. But one
   knows were to spend higher testing effort. Or as ChessBase boss Matthias
   Wuellenweber has formulated it: A tester who finds no enpassant-bug is not
   worth his money.

   Enpassant-example-bug:
   A move is in chess-illegal, if the opponent can capture next the king. One
   rule to test this is: If the king was not standing in check before the move,
   one needs only to consider if the moving piece was protecting the king. One
   has to scan the direction king to from-square for opponent sliding pieces.
   If it is no possible sliding-direction, one can stop immediatly.
   This seemingly waterproof rule introduces an enpassant-bug. If the move is
   enpassant, one has also to check if the captured opponent pawn has protected
   the king. Obviously one can make this error in any programming language.

   Chrilly Donninger


_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/