Crafty bugs

Discussion of chess software programming and technical issues.

Moderator: Ras

jwes
Posts: 778
Joined: Sat Jul 01, 2006 7:11 am

Crafty bugs

Post by jwes »

I think I found two small bugs in crafty.

1. It looks like killer moves are searched twice. It appears that when you removed the history move code, it also removed the code that checked if a move was a killer move.

2. In TestEPD, if the id string is not quoted, crafty crashes rather than rejecting a bad epd.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Crafty bugs

Post by bob »

jwes wrote:I think I found two small bugs in crafty.

1. It looks like killer moves are searched twice. It appears that when you removed the history move code, it also removed the code that checked if a move was a killer move.

2. In TestEPD, if the id string is not quoted, crafty crashes rather than rejecting a bad epd.
Bug 1 is "correct". But if you compare the two you will see there is no difference in speed. I just searched the killer move and it failed to cutoff. I generate all moves and search it again, but find the resulting position in the hash table almost every time. The extra overhead to eliminate those moves actually compares almost perfectly with the extra overhead of searching them again, since the "elimination" code is applied whether the killers were even legal or not.

I'll look at the EPD issue... that should be easy enough to fix.
jwes
Posts: 778
Joined: Sat Jul 01, 2006 7:11 am

Re: Crafty bugs

Post by jwes »

bob wrote:
jwes wrote:I think I found two small bugs in crafty.

1. It looks like killer moves are searched twice. It appears that when you removed the history move code, it also removed the code that checked if a move was a killer move.

2. In TestEPD, if the id string is not quoted, crafty crashes rather than rejecting a bad epd.
Bug 1 is "correct". But if you compare the two you will see there is no difference in speed. I just searched the killer move and it failed to cutoff. I generate all moves and search it again, but find the resulting position in the hash table almost every time. The extra overhead to eliminate those moves actually compares almost perfectly with the extra overhead of searching them again, since the "elimination" code is applied whether the killers were even legal or not.
.
Maybe then you should not check if you are searching the hash move again, as you check for that several times.