Author: Robert Hyatt
Date: 08:19:11 06/16/98
Go up one level in this thread
On June 15, 1998 at 15:41:36, Albert Silver wrote: >On June 14, 1998 at 11:01:05, Don Dailey wrote: > >>On June 12, 1998 at 22:02:33, Albert Silver wrote: >> >>>On June 12, 1998 at 15:18:42, Don Dailey wrote: >>> >>>>On June 12, 1998 at 13:15:04, Johanes Suhardjo wrote: >>>> >>>>>On June 10, 1998 at 17:40:21, Don Dailey wrote: >>>>>>But the "bad bishop" is not quite the same as a bishop lacking >>>>>>mobility. Our bishop was not "bad" in this sense. The classical >>>>>>definition is that your bishop is highly restricted behind a >>>>>>pawn on e3 or d3 (if you are white.) It can be bad in other >>>>>>cases but I think this is the common case. It's more a statement >>>>>>of it being undeveloped, and very difficult to get developed. >>>>> >>>>>The reason I'm looking at bad/good bishop is that I want to speed up my >>>>>program and one place to reduce work is to get rid of bishop mobility >>>>>code (besides, Bob Hyatt often says that it's clear whether mobility >>>>>is the cause or the effect of good positions). Well, looks like this >>>>>is a problem I have to experiment with. >>>>> >>>>>Thanks to all who responded! >>>>> >>>>> Johanes Suhardjo (johanes@farida.cc.nd.edu) >>>>>-- >>>>>Paradise is exactly like where you are right now ... only much, much >>>>>better. >>>>> -- Laurie Anderson >>>> >>>> >>>> >>>>That's exactly my reasoning too, I did not want the count squares >>>>type of mobility. So I used the 6th rank attacking definition I >>>>mentioned. Also I have a counting rule for colors of pawns. >>>>Friendly pawns on the same color hurt the bishop, but enemy pawns >>>>on the same color are good. Our rules weight one case more than >>>>the other though. Other than a small general centralization and >>>>advancement bonus, that's all we have. Of course we also have >>>>piece cooperation terms but this applies to the material value >>>>as a more general case. >>>> >>>>- Don >>> >>>Piece cooperation? How do you explain to a program that it's pieces are >>>cooperating? >>> >>> Albert >> >> >>I work from the most general to the specific. It is well known that >>certain pieces work well together. So I assume that if they are on >>the board together, the potential exists for them to work together >>well and they get bonus points for it. >> > >I assume you are talking about famous piece combinations in the middlegame such >as Queen and Knight together or in endgames where it is known that as a rule >Rook and Bishop are superior to Rook and Knight. The problem is that while these >are valid and correct pieces of information I don't see them as being general, >but rather as being very specific. This last is I believe worthy of being >included in a program's knowledge but the first? Telling the program to favour >an exchange of a bishop for a knight because the only other pieces on the board >are queens would seem to me to be a double-edged sword which would potentially >be more prejudicial than beneficial. > this is a good example of an idea that may or may not work. A R+B is better than a R+N, if there are pawns on both sides of the board. If all the pawns are on one side, the N is usually better, because it can help attack both colors of squares. I once had this in Crafty, but found so many exceptions that I took it out completely. I started off with R+B is better period, later qualified it to only if there are pawns on both sides, but even found exceptions to that. Now I rely on the bishop's mobility to make this attractive.. >>But it may very well be that in some given circumstance they are NOT >>working well together. When I can, I try to address these situations >>in more detail. >> > >You may be able to balance out the potential disasters by throwing in a number >of exceptions but unless the knowledge provided is absolutely crucial I would >say let searching do it's job. I guess the question is what knowledge outweighs >the loss of depth in the search. Of course, this is only true of "memory >starved" machines as Hyatt once put comparing PCs to Deep Blue. Perhaps in 20 >years time the whole idea of worrying about an algorithm slowing down the >program's search will seem ludicrous. > > Albert Silver very possibly. I'd bet that the next thing we see in PC's is something like the old writable-control-store seen on the VAX in the early 80's... where you can write microcode to implement a few useful instructions in hardware that make your application run much faster. The alpha has something similar in the "PAL code" although it isn't used for this purpose yet. But as transistor counts go up, we might be able to implement things far more efficiently by defining new opcodes that provide chess-specific things quickly. btw, I did a "generate moves" instruction for the vax, and it was *very* fast compared to the normal way of doing it... > >>A simple example is having two bishops. This in the most general case >>is quite good. But it may not be much use in a highly blocked >>position. So I have more specific terms that try to determine this. >>But having 2 bishops always get a bonus, it represents a long term >>potential even when they are currently NOT working together. >> >>- Don
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.