[computer-go] Re: Languages and bugs

["chrilly" <chrilly@xxxxxxxx>]

>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/