Author: Chris Whittington
Date: 08:09:40 11/30/97
Go up one level in this thread
On November 30, 1997 at 09:58:06, Robert Hyatt wrote: >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. No, I'm not saying that. I'm just asking the questions. It intrigued me that you used to say theat Crafty would really fly on a 64 bit machine; but then, when we saw the numbers, it didn't seem to be flying (and that was comparing a 32-but emulation of the 64 bit code, with the actual 64 bit code). So I thought, well lets take a look at these alleged bitmap advantages ....... >This is simply a false >assumption >based on lack of experience with bitmaps. Yes, its true. I'm a 64-bit virgin :) > 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, Indeed, can we get past this one ? Its software, we can do anything any way we want. I know. >and I see lots I can do more efficiently. Maybe, but the key is can you do intensive knowledge processing faster ? Because, if you can't, and if its more laborious to code/execute; then your paradigm is a design compromise that just about forces the designer to shy away from intensive knowledge and towards bits, bytes and all the other non-chess specific stuff. > 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... If you keep banging on about this one example only, forgive me for thinking it might be the only example. > > >> >>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?" Because if you need to add code to create the data that an intelligent offset program already has, then you'll be slower still. I want to know if thats going to be the case .... > >*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. No, no. You can have incrementally updated tables, just as long as you include the computation timne to get there. And, I'ld like to know if your tables are going to be 64 bitmaps - because if you want to generate offset tables to perform the exchange calculations, then ...... :) >And >I fail to see the reason for wanting to compare anything like this. To get to the bottom of the question of whether bitmaps are as cool as you say they are. > >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? Incrementally, at move time. > Because I can do *exactly* the same thing, depending on >whether it >is faster to compute as needed or to keep something incrementally >updated. We know you *can* do anything, Bob. What's at issue is what you have right now. What bitmaps and so on. if you want more data, that comes at cost. And if you want more data, you'll need to decide whether its bitmap or offset. I think you'ld be crazy to choose bitmap for piece safety on square evaluations. > >to compare these two approaches, we need something that is not horribly >complex to compute, Some important chess knowledge - like a full analysis of piece safety on moving into a square - just like I suggested. My contention is that you wouldn't want to do this with bitmaps. And, if this is so, that the bitmap approach forces a lack of knowledge in chess programs. >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. Which would suit a general obfuscation of the issue. Try the chess knowledge suggested. Bitmaps or offset ? > >How about something we both do? Move generation? Takes 0.05% in CSTal, therefore irrelevant. > Some evaluation >concept? >Swap()? Piece safety: what is the largest piece you can safely move into a square, taking into account pinned pieces ......... > 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... Not interested. Useful and difficult chess knowledge please. The sort that hardly any programs do ....... That would be the best test. Chris Whittington
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.