Author: Tim Foden
Date: 00:36:00 07/16/03
Go up one level in this thread
On July 15, 2003 at 18:26:58, Russell Reagan wrote: >On July 15, 2003 at 16:03:10, Tim Foden wrote: > >Wow Tim, that is too cool! I really got thrown for a loop when I saw this: > >> UINT64 bitmap = (ExtVert(movesA) & DiagAMask(a)) | >> (ExtVert(movesH) & DiagHMask(h)); > >I couldn't figure out how you were getting diagonal attacks from the "vertical" >table. Anyway, it "clicked" finally. My coworkers probably think I'm crazy now >because I've been sketching bitboards on paper for the last half hour, and now >I have a big grin on my face :) I could have given more hints as to what was in the lookup tables, but I'm sure you had more fun working it out for yourself! :) >A few other things. I remember in the Winboard forum you posted some code >involving CPosition (http://f11.parsimony.net/forum16635/messages/50247.htm), >and in your example here you use CBoard. I was wondering what the difference >between CPosition and CBoard is. My guess would be CPosition contains a board, >along with extras like fifty move counter, en passant square, etc. ? In GLC I have the main engine high performance board code, which is all static, so there can only be one in a program, and is inside a namespace called CBoard. To set up a position on this board, or to retrieve a position from this board, I pass in a CPosition. CPosition is a lightweight board representation, using a simple board (int[64]) and associated stuff to support FEN info. It can also generate and make moves (but not unmake, you need to keep copies of CPosition objects). It also has facilities to parse and output SAN. This is the class that gets used in my PGN parser (e.g. for book building, and loading and saving games). > Or is >CBoard something new in your new program? CBoard in my new program is a class (not a static namespace), so I could have multiple instances of it if I want (e.g. for SMP). There is no CPosition in the new program yet, but if I need it, I'll just copy it accross from GLC. > BTW, is your new program going to be a >new version of GLC, or a new program entirely? A new program entirely... but it's going to take some time before it is available. :) As I mentioned before, its being written because I have lots of ideas that I have acumulated while writing GLC, but which would be difficult to implement in GLC. Why? Here are some possible reasons... GLC moves... 23 bits. New prog moves... 14 bits. GLC scores... P=1000, 20 bits. New prog scores... P=100, 15 bits (or 64,14). GLC TT... separate pri/sec tables, separate black/white tables. New prog TT... aligned pri/sec (hopefully better on cache), hash for B/W. GLC board... only 1 instance. New prog board... can have multiple instances. I guess I hope that it will eventually take over from GLC (but not in name... its got its own name :), but its just a shell with movegen and makemove/unmakemove at the moment. >Thanks, >Russell No problem. Cheers, Tim.
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.