[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnuchess bugs & java
From: |
Mridul Muralidharan |
Subject: |
Re: gnuchess bugs & java |
Date: |
Wed, 1 Jun 2005 10:49:40 +0530 |
Hi Xan,
Just to answer/comment on some of your questions and observations ...
See inline.
Regards
Mridul
On 6/1/05, Xan Gregg <address@hidden> wrote:
> 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.
It has been a while since I looked at the code , in my current scheme
, I just used the from-to info from killers to bonus the move ordering
, not really "use" that move directly in the search.
>
> 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.
leadz and trailz are commonly used opcodes for just that (returning
the position of leading one/trailing one).
>
> 9. About a dozen unused variables or values, if anyone cares.
Ok , this is not really it :)
Do this simple test , run GNUChess multiple times from the same
console window with nothing else changed sequentially and analyze the
starting position.
What I mean is , launch from the cmd , give "xboard\nprotover
2\nnew\nanalyze=n<wait for 1 min>exit\n".
Try this a couple of times (so each time gnuchess is exitting before
the next run.
You will observe all the classic cases of bugs in the program - the
node counts will be different , the pv's might be different , etc.
I used to strongly suspect the hash impl has bugs , but never bothered
to fix it.
>
> 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.
Try with -server option , and if possible try with 1.5 heard it has a
bit faster hotspot , better mem management , etc.
But half the speed is quiet good I must say ! since it has no "java"
optimizations yet :)
>
> 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?
The 64 bit int's used are all unsgned in gnuchess ... java does not
have a concept of unsigned long (actually , no concept of unsigned
itself).
So it is going to be interesting of how you plan to use it through java.
Book , hashing , etc will all be affected.
The trick you see above is called zorbist hashing - more info here :
http://www.seanet.com/~brucemo/topics/zobrist.htm and
http://www.seanet.com/~brucemo/topics/hashing.htm.
Actually the site : http://www.seanet.com/~brucemo/topics/topics.htm
has lot of beginer to fairly advanced level stuff ... can be a good
read if you have not done that already.
>
> BTW, any way someone can get rid of all the spam on this list?
I just rely on more agressive gmail filters ... I suspect that this is
kicking out valid questions from this list too - but way too much spam
for me to manually re-chec my spam folder *sigh*
Enjoy hacking on the program !
Mridul
>
> xan
>
>
> _______________________________________________
> Bug-gnu-chess mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnu-chess
>
- Re: gnuchess bugs & java,
Mridul Muralidharan <=