bug-gnu-chess
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnuchess bugs & java


From: Xan Gregg
Subject: gnuchess bugs & java
Date: Tue, 31 May 2005 20:47:21 -0400

I've been porting GNU Chess to Java, and it's working as far as I can tell. It's at least to the point where I can point out some of the bugs/suspicious code found in the C code.

1. In BookBuilderOpen(), there appears to be an unnecessary close() of rfp and later a read_book(wfp) which should probably be a read_book (rfp).

2. In ParseEPD(), there's a "if (!++p)" that should probably be a "if (!*++p)".

3. In ScoreK(), need to check that the king isn't on the last rank before checking for pawns in front of the king. Otherwise, who knows what you're looking at.

4. InitHashCode() should be called before InitVars(), because the latter makes use of the hashcodes.

5. Misplaced parenthesis in ValidateMove()?:

  if (piece_id(mvstr[2] != empty))

6. In IsLegalMove(), need to check that moving a pawn to the 8th rank is marked as a promotion. What happened while trying BT2630.epd was a move g2-g1 was cached as a killer when it was legal (maybe a rook on g2) and considered later when there was a pawn on g2. IsLegalMove() let it pass, which caused an array index out of bounds while later processing the position with a pawn on the 8th rank.

7. In PhasePick1(), there's a 'while' that could be an 'if': the body ends with a 'return'.

8. trailz() is a bit cryptic, but it looks like it returns the bit index of the trailing 1 but, not the number of trailing zeros as expected by the name.

9. About a dozen unused variables or values, if anyone cares.

That's about it. The Java 1.4.2 version is running about one half the speed of the C code on my Mac G5.

Question: It looks like the code is assuming that hash(position1) == hash(position2) implies that position1 == position2. A hash has 64 bits, but there are supposedly around 2^160 chess positions, so there must be about 2^96 positions for every hash code. Is the code relying on luck to avoid collisions, or is there something in the design that prevents them?

BTW, any way someone can get rid of all the spam on this list?

xan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]