Author: Robert Hyatt
Date: 06:58:06 11/30/97
Go up one level in this thread
On November 30, 1997 at 06:58:43, Chris Whittington wrote: > >Ok, let's take a concept that will be important for a knowledge program, >but would be generally ignored by a fast program: "what is the largest >piece that can be safely moved into this square ?". ie a swap-off / >exchange evaluation rendered slightly more complex ........ > >offset: you have pre-computed attack lists of all defenders and >attackers and x-rays onto the square. these attack lists are organised >as 16-bit fields with the largest piece values in the mosts significant >bits. You also know which pieces are pinned and by what. > >64 bitmaps: you have bit fields of all pieces. should you have >pre-computed attack maps on each square - yes, if Crafty does. should >you have pre-computed x-ray maps onto each square - yes, if Crafty does. >should you have pin knowledge - yes, if crafty does. (and "yes, if >crafty does" should refer to what the currect version of carfty actually >DOES, not what Bob claims it could do if he wanted). more below, but you need to get past a basic misconception: anything you do now is hard or impossible for bitmaps. This is simply a false assumption based on lack of experience with bitmaps. After using these things for 3+ years now, I don't see *anything* I can do with offset that I can't do with bitmaps, and I see lots I can do more efficiently. IE, the square of the pawn idea I mentioned is one trivial example that replaced dozens of lines of code in Cray Blitz by a single load/AND operation in Crafty... > >Any offers to make the comparison ...... ? :) > >Chris Whittington I'm willing to compare *anything* you'd like... but I want to turn this around to show how "off-the-wall" your last paragraph is. Rather than my being able to use only what I now do, I suggest we *both* limit ourselves to what *I* do and no more. Why? Because I can add code just as easily as you can delete code, so why the nonsense limitation to "what I do now and not what I could do if I wanted?" *obviously* I now do what I need to do to run fast. So including such a pointless restriction basically means that the "comparison" won't work. And I fail to see the reason for wanting to compare anything like this. If we eliminate the above restriction, then we can compare. How do *you* create the list you are talking about? Incrementally or dynamically when you need it? Because I can do *exactly* the same thing, depending on whether it is faster to compute as needed or to keep something incrementally updated. to compare these two approaches, we need something that is not horribly complex to compute, otherwise I'm going to pick something I do that is easy, which would be hard for you to compute, and you will do the opposite, and we won't ever get an answer because neither of us will ever write the code to do the calculations. How about something we both do? Move generation? Some evaluation concept? Swap()? Partial pattern recognition (is this position a known Stonewall? Is it pretty close to a known Stonewall? etc.) However, I'm not going to write something grossly complicated that I don't intend to use, and I don't expect you to either. Therefore we need some common denominator that we both have and can compare. Move generation is certainly one, but most anything is comparable...
This page took 0.01 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.