Author: Bas Hamstra
Date: 20:47:05 08/21/99
Go up one level in this thread
Hi Dan, You have the same "style" of programming as I do, I find your code much easier to read and understand than other programs like Crafty. The only confusing thing is the obscure way you count nodes. How do you count'em? Here is what I do: in every searchnode a Nodes++ and just before the QSearch is called I do a QNodes-- (to avoid double counting). And in the QSearch a Qnodes++. Total nodes = Nodes+Qnodes. However in fact I think it should me more appropriate to do Nodes-- in stead of a QNodes--, because the overhead of that node is in the QSearch (movegeneration for example). BTW I have tried nearly all possible datastructures and am still not sure what's fastest. So far my expermiments indicate incremental (pseudo-) attacks (if you do it efficienly) and bitboards are good. At the moment the bitboard version is slightly faster than incremental attacks. Plain 0x88 is also ok. I would say they are all competitive. My "feeling" is this: if you want to do SEE, bitboard and incremental pseudoattacks approaches are fastest. You pay overhead, but get capture generation and SEE very cheap, and many eval advantages. On 64 bits machines probably bitboards get the advantage. (experiments based on full (-inf, inf) window plain a-b material recursive nullmove R=2 search, with hash, one killer, no history sorting, without extensions). (Question: any idea what Fritz uses? My guess is some extremely efficient form of incremental attacks by which incremental movegeneration. *If* Fritz does incremental movegeneration plain 0x88 would be too slow to get its NPS, I think) Regards, Bas Hamstra. On August 20, 1999 at 14:24:54, Dan Homan wrote: >On August 20, 1999 at 13:40:28, James Robertson wrote: > >>On August 20, 1999 at 12:24:44, Jon Dart wrote: >> >>>Actually, the first thing I'd look for is the logic you have for >>>storing and retrieving hash values. If you do not always correctly >>>identify the node type (fail-high, fail-low, or in bounds) or >>>if you do not properly set the search bounds after a hash hit, >>>you will have problems like you describe. Having "almost right" >>>logic will appear to work for a while, but sooner or later you >>>will pull a bad value out of the hash table and you will be >>>hosed. >>> >>>Unlike many areas of computer chess, there is really only one >>>right way to do this. Look at Arasan, Crafty, or Gnuchess source >>>and do what they do (in Crafty, look at hash.c). >>> >>>--Jon >> >>I have tried to look at Arasan source several times and was always completely >>confused. Crafty is confusing because the hash stuff is split between 2 files. >>EXchess is of some help. The only program that is not confusing is JRCP, and it >>has too many bugs. :( > >The currently released version of EXchess (2.51) has some small bugs >in hash handling. I forget exactly what they are... it is basically >right, but even small bugs can be a big problem in the right >position. One bug that I can remember gives the same >behavior as your program... i.e. the MATE score is not always >properly adjusted to the ply depth. I can't remember the exact >cause, but I think it had something to do with trying to return a >MATE score when I only had a bound rather than an exact >score in the table. > >The newer version (currently in progress) has some fixes/improvements >in this area and many others. > > - Dan > >> >>James
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.