1) Bug fix: in certain situation, en passant squares were not detected properly. That was when the position needed to be switch (black <--> white) before probing the table bases. This bug was reported by John Merlino. Thanks!
2) Warnings by 64-bit compilers have been silenced.
http://sites.google.com/site/gaviotache ... e/releases
It is unbelievable that this bug went unnoticed for such a long time. The tables are fine, but I missed two lines of code when probing a position with an en passant square.
In this position
[D]8/p7/7k/6pP/K7/8/8/8 w - g6
The probing code switches the position of the pieces internally and probes this position instead
[D]8/8/8/k7/6Pp/7K/P7/8 w - g3 0
and reverts the score afterwards, but I was not switching the ep square (keeping it as g6 rather than g3).
Miguel
Gaviota tablebases, probing code v4 (UPDATE)
Moderators: hgm, Rebel, chrisw
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
-
- Posts: 201
- Joined: Thu Mar 22, 2007 7:12 pm
- Location: Netherlands
Re: Gaviota tablebases, probing code v4 (UPDATE)
Hi Miguel,michiguel wrote:It is unbelievable that this bug went unnoticed for such a long time. The tables are fine, but I missed two lines of code when probing a position with an en passant square.
Miguel
I have been designing software for a living for many years now, and it still amazes me how easy it is (al least for me) to introduce bugs in what seems like straightforward code.
Programming should really be left to programs...
Jan
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: Gaviota tablebases, probing code v4 (UPDATE)
A bug is always a lesson.Jan Brouwer wrote:Hi Miguel,michiguel wrote:It is unbelievable that this bug went unnoticed for such a long time. The tables are fine, but I missed two lines of code when probing a position with an en passant square.
Miguel
I have been designing software for a living for many years now, and it still amazes me how easy it is (al least for me) to introduce bugs in what seems like straightforward code.
Programming should really be left to programs...
Jan
The tables are fine because I designed a very thorough testing and validation procedure (every single position does a one ply search and probe their descendants and makes sure everything is compatible). On the other hand, the probing code has been tested with "only" a couple of hundreds of positions (tbtest in gaviota). But... they do not need to be switched. So, the biggest sin here was not the code itself but the testing procedure.
In addition, the fact that this bug went unnoticed is unbelievable but not surprising
Alpha-beta has a tremendous power to "heal itself" against bugs. It always find workarounds to pick the right move and that is why is so challenging to remove all bugs from a chess engine. A bug may reduce 3 ponts elo, but the program may not crash (or may do it 1 in 10000 games).
Miguel
-
- Posts: 1357
- Joined: Wed Mar 08, 2006 10:15 pm
- Location: San Francisco, California
Re: Gaviota tablebases, probing code v4 (UPDATE)
Thanks for this update, Miguel. Your efforts at creating and maintaining this are very much appreciated.
Very glad I could help in some small way.
jm
Very glad I could help in some small way.
jm