Hi Dex - yes I know thats just how Microsoft likes it I'm afraid. But sometimes I write programs just for my own use.

Hi Tom,

I have to say I disagree with a lot of what you say. Firstly, the database is NOT a database of moves as you say, but a database of game-theoretic valies for positions. It strengthens middle-game play by allowing accurate evaliation of nodes found during searches from middlegame or even opening root nodes, with immediate cut-offs allowing more time for the other nodes, thereby improving both depth of search and accuracy of evaluation. Also, Chess and draughts are both zero-sum two-person games, and as such equally amenable to any of the various alpha-beta derivative algorithms. Chess has a higher branching factor certainly, so chess game trees are typically not as deep as draughts search trees, but maximum efficiency in the search algorithm is just as important, and all succesful chess and draughts programs use some form of tree searching algorithm. There is one much overhyped neural network draughts program commercially available which claims to play at expert level but in fact plays extremely feebly and would lose every game against any of the top draughts programs available today. Plaat's algorithm is NOT chess-specific in any way, and if you had read his research papers you would know that he tested it in 3 different games, one of which was chess and the another of which was draughts, with the Chinook program (program - NOT algorithm) being used to implement MTDF and compare performance against Schaefer's own algorithm PVS. The size of the database has not been greatly reduced in spite of the best efforts of several developers, notably Murray Cash, Ed Gilbert, Martin Fierz and Ed Trice, to find more efficient ways to store the information. In fact, 5.5 GB is not that bad for over 440 billion positions. Thats quite an impressive number of positions per byte - could you do better and still allow fast lookups?

The fact that my "misguided" approach trounced the World Champion is, I think, justification enough for my faith in tried and proven methodology, but if you think you or anyone else can do better without alpha-beta or without an endgame database I would pit my program against yours willingly, and do so with confidence. The onus on any alternative, no matter how intellectually or academically interesting, to the existing algorithms based on depth first search and endgame database is to prove itself at least of equal strength ACROSS THE BOARD with a functioning program against an existing program using the orthodox approach. Several very attractive-looking alternative knowlege-based approaches have been attempted at various times in both chess and draughts programming, but all were eventually abandoned because they were found wanting and couldn't compete with boring old depth first search.

Whereas I am not an expert at the details of reading files from my hard drive using direct port access, I have been programming both chess and draughts for close to 30 years and so I feel I can speak with some knowlege on that subject. What you call obsolete is the method used by every strong chess or draughts playing program available today.

Roberto

good reply, I like it!

From a hardware and future roadmap point of view you'd probably be best off migrating to an AMD 64bit cpu with enough RAM, running Linux. There are mainboards out there today that can give you usable 16 GB with no problem, or more if you're willing to go for a multiprocessor board (all up to 128 GB!).

This also brings on the distant possibility to run your software first on other linux base machines and, if it doesn't use too much x86 assembly, also on any other Unix based server/workstation. If you're interested in expanding there are no limits in this dimension.

While I feel that any self development on pure assembler is commendable, in this case where there is a significant application there should be questions about interfacing, future hardware, roadmap, expandability. Going unix-based 64bit will give you all these and more. For example, you could put your master code to play online, easily.

Also future versions of Windows will definately support 64 bits and larger amounts of memory (Vista is almost here) and it will be much easier to make a 64bit Windows port from an existing 64bit Unix code than from a fully prioprietary 32 bit code.

FASM is also for Linux so we'll hopefully be able to assist you on this aspect should you need any help.

@kake_zinger, I disagree with you, i think he would be better off, do it the way he is, If he were to code it in C, than he should use linux, but not if using assembly.
The loading of 4GB is very simple. i could code a bootable program that could find a file and load 4gb from the Hdd, from pmode in less than 2k, maybe a days work.
So its not abig deal, compeared to fighting XP or linux.

For what it's worth, I have no plans to release this program publicly, although I don't rule it out, and it is primarily a project for my own interest rather than a commercial venture. I may, however, use it to compete at the next World Computer Draughts Championship if there ever is another one (draughts politics, but that's another story) or to challenge Murray Cash's World Computer Draughts Champion program Nemesis for the English Draughts Asdociation Computer Championship title. At least if I did ever choose to release it, it could run on any x86 box, since it doesnt require an operating system for anything other than file loading, and that can be done with only the bare essentials of DOS. However, as I doubt many customers would have 4 GB of RAM I woud then need to dynamically decide which parts of the database to load permenently into RAM and which to use buffers for, much as my Windows version does, which largely defeats the purpose of running without any disk access during the searches.

I have never much cared for C as a programming language, and my knowlege of it extends only as far as what I have had to learn in order to understand source code presented in C. This is the language Chinook was written in of course (not LISP!!!), and when Professor Schaeffer put the Chinook database up for download the rather complex access algorithm was only supplied as C source code, and that only for the 6 piece, not the 8-piece database, so I had to decipher this code well enough to write my own (hopefully more efficient) code in PowerBasic to do the same job. I don't think I would ever choose to program with C if I had a reasonable alternative, but that is just my personal preference.

Much as I would love to have a 64-bit processor and 16 GB of RAM, I am afraid that is a bit beyond my budget just now, especially having not long ago purchased the box I am presently working with. I write for the hardware I have available to me as otherwise testing and debugging would be nigh impossible.

Roberto

Is that a 64-bit machine you have there? If not, anything above 3GB is actually rather useless.