Author: Uri Blass
Date: 09:11:45 03/19/03
Go up one level in this thread
On March 19, 2003 at 11:37:28, Ricardo Gibert wrote: >On March 19, 2003 at 09:54:02, Uri Blass wrote: > >>On March 19, 2003 at 09:29:04, Matthias Gemuh wrote: >> >>>On March 19, 2003 at 08:28:02, Ricardo Gibert wrote: >>> >>>>On March 19, 2003 at 06:33:01, Matthias Gemuh wrote: >>>> >>>>>I decided to stop chess programming but even the latest version of my program >>>>>sucks. How can I quit in peace? >>>>>It calculates this attack information (bitboards of attackers to 64 squares) >>>>> BITBOARD AttacksTo[64] >>>>>from scratch at each node. I tried to do this incremementally and it quickly got >>>>>messy and buggy because of sliding pieces, castle, en passant. >>>>>How do you attack attack boards (even the conventional type)? >>>>> >>>>>/Matthias. >>>> >>>> >>>>Let me share a couple of observations I have made concerning the development of >>>>amateur chess programs. >>>> >>>>The 1st big mistake I see repeatedly is being in too much of a rush make their >>>>programs strong by adding "fancy stuff." A very simple program can be fairly >>>>strong (> 2200 elo). You just need to get the fundamental things to work right >>>>*first*. Gerbil is a good example of what is possible with a reasonably simple >>>>program (about 2400 ICC rating). Don't layer the "fancy stuff" on top of the >>>>incorrectly implemented fundamental stuff. >>> >>> >>>Hi Ricardo, >>>I, indeed, do layer "fancy stuff" on junk :). >>>That explains why my prog scores a miserable 260/300 WAC at 5sec/pos on 1.8GHz. >>>BTW, my prog (BigLion) is at least 5 times slower than Gerbil, but equal in >>>strength at 1 minute/move. >>>If I should ever come back to chess programming, I think I would follow your >>>instructions. I just want to correct my fancy stuff now (my evaluation function >>>depends heavily on it). >>>Thanks, >>>Matthias. >> >>Did you try to spend time to search for the reason that your program is so weak >>in WAC? >> >>If you find a position that other programs are more than 100 times faster than >>biglion then it may tell you about bugs in your program. >> >>Movei solved 276 position on WAC in 1 second on 1GHz so I do not believe that >>lack of speed is the only problem of biglion. >> >>I do not think that speed optimization are bad idea. >>speed optimization can also tell you about bugs in your program. > > >Let me clarify what I mean by "speed optimizations." A program with low NPS >*can* be an indication of improper implementation. NPS should be at a reasonable >level. Rectifying such bugs I do not consider a "speed optimization", but rather >simply "bug fixing." Ditto for time to depth, etc. I do not know what is low nps. Movei nps is today only 200-300 Knodes per second on 1000Mhz(can be slightly less than it in the opening or slightly more than it in endgames). Note that deciding to prune moves before I make them and not after I make them may reduce the nps but my target is not to increase the nps and I prefer to make the program faster even if it means less nps. I already dicovered the bug and it was the fact that I did not update some information during null move pruning. The information was relevant for the evaluation. This bug is not relevant for 0.799 but it is relevant for the versions after it that used king safety evaluation. Uri
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.