On every Monday, I ask myself if enough improvements have been made to BozoChess to justify a source release.
On this Monday, the program can now play real chess (but not very well) and while some features are missing, there are no known bugs with those which are present. So I've emailed a copy of the Pascal source to those who've gotten earlier versions. Also, I can send a copy to anyone else who might want to review and experiment; just let me know.
The BozoChess 2011.12.12 source is 13,062 lines long and about 375 KB in size. A free Pascal compiler can be had from the http://www.freepascal.org/download.var web page.
I hope you have not already answered this question, but just out of curiosity I was wondering why you chose Pascal?
I have a warm spot in my heart for Pascal as it was my first compiled language, the $50 Turbo Pascal from Borland and it was a wonder to behold coming from interpreted basic. Any given program was something like 40 or 50x faster when written in Pascal.
So why Pascal over C or C++? Just a preference? Surely you give up some performance for this choice, although I know Pascal these days is still pretty fast.
Don
sje wrote:On every Monday, I ask myself if enough improvements have been made to BozoChess to justify a source release.
On this Monday, the program can now play real chess (but not very well) and while some features are missing, there are no known bugs with those which are present. So I've emailed a copy of the Pascal source to those who've gotten earlier versions. Also, I can send a copy to anyone else who might want to review and experiment; just let me know.
The BozoChess 2011.12.12 source is 13,062 lines long and about 375 KB in size. A free Pascal compiler can be had from the http://www.freepascal.org/download.var web page.
Don wrote:I hope you have not already answered this question, but just out of curiosity I was wondering why you chose Pascal?
I have a warm spot in my heart for Pascal as it was my first compiled language, the $50 Turbo Pascal from Borland and it was a wonder to behold coming from interpreted basic. Any given program was something like 40 or 50x faster when written in Pascal.
So why Pascal over C or C++? Just a preference? Surely you give up some performance for this choice, although I know Pascal these days is still pretty fast.
I wanted to provide an open source, educational chess program written in a well supported portable language which itself was designed for pedagogical purposes. Pascal has all the good stuff of ANSI C++ plus better control flow structure and lexically scoped routines. It is easy for a student to read a single file Pascal source from top to bottom than to attempt the same in any other language.
The Atkin/Frey Chess 0.5 program from 1978 was a good attempt. But in the third of a century since then, Pascal has improved in many ways and has better standard support and portability. Chess programs have gotten better as well including better search techniques, better evaluation ideas, and use of data interchange format standards for interoperability. It's time for an update.
As I promised back in early October, I'm changing the name of the project as the program is starting to play somewhat decent chess. Also, I don't want to worry about possible copyright problems with the old name, even if it was given in jest.
So from here on out, the program's name is CookieCat. Why? Well, many good names like TreeFrog and IronFish have already been taken. And CookieCat should be easily searchable on the net without too many false positives.
In other news:
1) CookieCat now runs the generate/execute/retract machinery abut seven percent faster than before, at least on a 64 bit CPU.
2) I've found a couple of compiler bugs and have coded around them. If the CookieCat source were smaller, I'd submit bug reports or maybe fix the compiler bugs myself as I have the compiler sources.
3) CookieCat has five different transposition tables. One of them is the prft table, used only by the perft subsystem. The other four are used (or will be used) by the search: eval (evaluation), main (traditional), pawn (pawn structure), and tbas (tablebase probe results).
4) The incrementally updated material signature routines are present and working. These are needed for fast tablebase probing.
5) The tablebase initialization code is present and working. This took much longer than expected, but the result is both general and fast. The general part is that the code can handle upper limits on class size from 2 to 10 men without any hard coded class information. The fast part is the binary probe of the tablebase signature table. The difficulty in writing the initialization code came from the work needed to generate all the tablebase names without misses, duplications, of malformations. The unsavory alternative would have been a boatload of explicit array element initializations.
6) Next for tablebase support: file I/O operations, file seek position offset generation, score decoding, and integration with the tbas transposition table. There is not a lot of code here, but it is largely specific to the flavor of tablebase files in use. For now, this isolated code will handle only my tablebase format, but it could be changed to handle other formats.
I hope to send out a new release on Monday, Dec 19th.