Author: Robert Hyatt
Date: 11:03:08 06/22/00
Go up one level in this thread
On June 22, 2000 at 13:47:12, Tom Kerrigan wrote: >On June 21, 2000 at 21:56:25, Robert Hyatt wrote: > >>On June 21, 2000 at 13:33:14, Tom Kerrigan wrote: >> >>>On June 20, 2000 at 21:39:01, Robert Hyatt wrote: >>> >>>>On June 20, 2000 at 15:52:53, Tom Kerrigan wrote: >>>> >>>>>On June 20, 2000 at 15:03:48, Robert Hyatt wrote: >>>>> >>>>>>On June 20, 2000 at 14:07:39, Tom Kerrigan wrote: >>>>>> >>>>>>>On June 19, 2000 at 21:32:56, Robert Hyatt wrote: >>>>>>> >>>>>>>>On June 19, 2000 at 20:50:11, John Coffey wrote: >>>>>>>> >>>>>>>>>On June 19, 2000 at 19:48:36, Larry Griffiths wrote: >>>>>>>>> >>>>>>>>>>I have found bitboards to be an even trade-off on my Pentium system. I have to >>>>>>>>>>update about 6 bitboards when a piece moves and this generates a lot of >>>>>>>>>>instructions. I get it back in my IsKingInCheck code so it evens out. I like >>>>>>>>>>to have fast move generation code, but most of my gains have been through >>>>>>>>>>alpha-beta, hash-table, killer-move and movelist ordering etc. >>>>>>>>>> >>>>>>>>>>Larry. >>>>>>>>> >>>>>>>>> >>>>>>>>>Maybe I am too much of a novice, but I don't see yet why I should convert over >>>>>>>>>to bitboards. Is move generation faster? If so, why? My program scans the >>>>>>>>>board and uses simple loops to generate moves. Do you not have to do loops >>>>>>>>>with bitboards? >>>>>>>> >>>>>>>>Not to generate moves, No. You generate all the sliding piece moves with two >>>>>>>>table lookups... >>>>>>> >>>>>>>Hmmm. I do table lookups all over my program, and none of them seem to be >>>>>>>generating any moves... >>>>>>>The fact is that you DO need to loop to generate moves in a bitboard program. >>>>>>>Maybe it's not the same loop, but it's still a loop. >>>>>>> >>>>>>>-Tom >>>>>> >>>>>> >>>>>>Who says so? Ask the Dark Thought guys. >>>>>>Or Slate/Atkin. You only need to loop if you want to take the attack bitmap >>>>>>and turn it into a list of moves. This is not the way _all_ programs operate >>>>>>(chess 4.x, Dark Thought, others, any of which generate a few moves at a time, >>>>>>then take one and search it, without enumerating the other moves.) >>>>>> >>>>>>So loops are something you do (with bitmaps) if you want to, not because you >>>>>>have to. >>>>>> >>>>>>As far as your table lookups not generating any moves, that is a programming >>>>>>issue. Mine do. :) >>>>> >>>>>Maybe your makemove() function can take bitboards as input (i.e., here is a set >>>>>of squares that my pieces can move to) but mine sure can't. >>>>>-Tom >>>> >>>> >>>>You are missing the point. A move generator _can_ emit a single move, which >>>>can be fed into MakeMove(). Read "Chess Skill in Man and Machine", the chess >>>>4.x section. They explain this pretty well. It takes zero loops to emit a >>>>single chess move. You pick the source square. You do two table lookups for >>>>bishops (say) and you have all the target squares it can move to. A single >>>>FirstOne() and you have a <to> square, which is all you need to make the move, >>>>and recursively call Search(). >>> >>>So you end up having to call gen() a mess of times. I don't see how that isn't a >>>loop. >>>-Tom >> >> >>OK.. do this. Were are at position P, where at the previous ply, the opponent >>hung something. We have to capture it. Somehow we know that our bishop can >>take a free pawn. How do _you_ generate that capture to try it? > >When did the pawn come into the picture? Is that what's hung? We know it can be >captured "somehow"? How? This explanation is incomprehensible. Just to make the example easy to understand. We have a bishop (only one) that can capture a pawn (only one). How do you find that capture? I find it with no loops of any kind. > >>I generate the bishop moves by two lookups and then I OR the results together >>to get the set of bishop moves. I AND this with the opponent's occupied square >>bitmap, and I get that one capture. I use FirstOne() to grab the <to> square, >>and away I go. >> >>How do you generate that sliding bishop capture? > >Well, if I already know what piece I want to capture (as you seem to), it really >isn't so hard for me either. I only know that this bishop can capture something. to make it easy to understand. But in reality I can find that the bishop can't capture anything at all without using a single loop. I compute the attacks from the bishop square, AND this with opponent's pieces, and if zero, this bishop can't rip anything. > >>That is the point. To produce that one capture, you have to loop down each of >>the 4 rays to see if you hit an opponent's piece. I don't have that loop. We >>_both_ have a loop to select the next move. But I don't have to have one to >>enumerate the bitmap into individual moves. I happen to do it that way at >>present because I find it simpler to program. But I don't _have_ to generate >>all the moves and enumerate them into an array (see a later post on exactly how >>this is done, or see Frey's book). > >I know how it's done, and still I think you DO have to generate some sort of >move list if you want good move ordering. BTW, what's the point of having a >fancy SEE if you're only scoring one move at a time?... > >-Tom Remember I said _I_ use a loop to produce all the moves? For this reason. But several others are using MVV/LVA. And there one move at a time is easy with bitboards.
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.