Deep Blue vs. Kasparov
Jose Lopez Jr.
with Garry Kasparov on Feb. Does anyone have any details on any
matches it played with Grandmaster's and their comments on Deep Blue.
Is it really a match to Grandmaster's...and does it stand a chance
for the upcoming match with Kasparov? Any comments about Deep Blue,
anyone?
D Kirkland
Yes, we have heard (well most of us anyway). I'm not sure if Deep
Blue as actually played yet (last I heard, it was the Deep Blue
software on the old hardware).
Unless they have come up with something very different from what
we have seen so far, Deep Blue does *not* have much of a chance of
winning the match. When compared to the top players in the world,
current chess algorithms come up short. And I just don't see how
a faster, deeper search is going to make up for this.
So, is there any hope that computer chess will beat the world
champion in the near future?
Well, if I actually ever get around to putting my ideas in a
program, I think there is a good chance of seeing even common
desktop computers beat the world champion.
Until then...?
dan
Bradley K. Sherman
>Well, if I actually ever get around to putting my ideas in a
>program, I think there is a good chance of seeing even common
>desktop computers beat the world champion.
>
Such modesty!
Is there any evidence that computers are falling behind
the strongest players? Now that there is money to be
made beating up on computers GM's may be puting a bit more
effort into finding the weaknessess of silicon-based players.
--bks
Robert Hyatt
-->: In case no one's heard. Deep Blue is going to have a match
-->: with Garry Kasparov on Feb. Does anyone have any details on any
-->: matches it played with Grandmaster's and their comments on Deep Blue.
-->: Is it really a match to Grandmaster's...and does it stand a chance
-->: for the upcoming match with Kasparov? Any comments about Deep Blue,
-->: anyone?
-->
-->Yes, we have heard (well most of us anyway). I'm not sure if Deep
-->Blue as actually played yet (last I heard, it was the Deep Blue
-->software on the old hardware).
-->
-->Unless they have come up with something very different from what
-->we have seen so far, Deep Blue does *not* have much of a chance of
-->winning the match. When compared to the top players in the world,
-->current chess algorithms come up short. And I just don't see how
-->a faster, deeper search is going to make up for this.
-->
-->So, is there any hope that computer chess will beat the world
-->champion in the near future?
-->
-->Well, if I actually ever get around to putting my ideas in a
-->program, I think there is a good chance of seeing even common
-->desktop computers beat the world champion.
-->
-->Until then...?
-->dan
A couple of points.
1. According to Hsu, Deep Blue has actually played games. It was at the
SuperComputing '95 Conference and played several games with Byrne. He did
not explain much about the configuration, and how many processors they were
using, nor about how much faster they expect to be for the Kasparov match.
2. I tend to agree about its chances in February. I suspect that, given
a couple of years, the machine/program may well have a chance, but based on
my experience with Crafty (and Cray Blitz and ...) it takes a lot of time
to tune a new program, or an old program to new hardware. If you plot the
performance of Crafty, last January, it was a 2000 player on ICC. Today it
is a steady 2600-up player, with an average standard rating of 2450 or so
against IM -type players. This is the "time factor" I'm talking about. It's
taken a lot of tuning, tweaking and testing to reach this point, and it's
still nowhere near the top of the performance curve yet. Give them enough
time to tune that beast, and it's going to be a terror. The concern is, then,
how well it can do in February.
3. "putting your ideas into a chess program" is probably a *whole lot more
difficult* than it appears. Don't think that all of us are not trying to
solve some of the obvious computer-like problems current programs exhibit.
And don't think we aren't making progress either. It's just evolutionary
rather than revolutionary, but just as steady an improvement as you would
expect/hope for. Once you "jump into the ring" and give this a whirl, you
can then get by with making statements like the above. Until then, I can't
count the number of people saying "when I design a program like I think it should
be designed, look out." This goes for amateurs as well as a former world
champion. It's *not* easy. Done correctly, it *can* be fun. It *is* a
heck of a lot of work. Ask how many ICC'ers see me on after 1am CST. As
long as it continues to be fun, I'm in for all I can do. However, please
don't assume that all we are after is raw speed. I take a lot of heat about
Crafty's huge book. "why don't you make it more selective so it will only
play lines that it understaands?" My response is that I want to improve its
knowledge so it can play *any* opening system equally well. It's doing better
than Cray Blitz ever did in this respect, and it's continuing to get better. I
want it to "eavesdrop" on strong players by looking at their games, and then
decide "Hmmm.. I like this position and will try it given the chance." or "Hmm..
this doesn't suit my open style of play very well, think I'll avoid it." For
the long run, obviously, this will make my life a lot simpler. Just feed it
current opening theory and let it run on its own. A lot of promise, but a
difficult task to accomplish this.
I don't intend for this to be taken as a flame, by any stretch of your
imagination. Rather, that it be taken as an explanation of what I (and many
others) are trying to do. Believe me, we want to eliminate Kh1, and g3/Bb5
as much as you do. :)
Bob
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
Ed Seedhouse
>Is there any evidence that computers are falling behind
>the strongest players? Now that there is money to be
>made beating up on computers GM's may be puting a bit more
>effort into finding the weaknessess of silicon-based players.
I think it is to be expected that there would be a plateauing effect
because of this. When GM's start to take computers seriously (which
they will do when there is money to be made or lost playing them) we
would expect them to start playing to their specific strengths and
weaknesses.
You often see much the same effect when a new player comes into the
local scene. No one knows how to play against him and he does rather
better than he otherwise would until his style gets well known.
Happened to me back in the 60's when I moved to Toronto. Got a nice
100 point rating boost - for awhile.
However, I expect that they are merely holding back the tide for a
short period - maybe 10 years or so. Eventually programs will get so
good and computers they run on so fast that they will beat everybody.
Ed Seedhouse
President, Victoria Chess Club.
CFC Rating: 2040
Joseph McCaughan contra
Attached below are some stats and projections from the Harvard Cup from
Craig Jefferies. This was posted before. I have to believe that
Deep Blue is pretty much in a class by itself. It would be nice to see it
in these Harvard Cup tournys though. It is certainly "beatable".
Maybe the DB team has too much to lose if they entered it. Gee, what
if it "didn't" win. After all the research and money etc...
--
Joe McCaughan / Do yer givin,
jmc...@hposl61.cup.hp.com \ While yer livin,
Phone: (408) 447-7892 / So yer knowin,
\ Where it's goin. Unknown
================== snip ==============
Christopher F. Chabris pointed out that the first Harvard
Cup was 1989 (and the second was 1991), so using elapsed
years as the independent variable, the revised forecast
(a better fit, but still not super) would be:
1989 1991 1992 1993 1994 1995 1996F 1997F 1998F
x: 0 2 3 4 5 6 7 8 9
y: 9% 25% 28% 25% 39% 35% 43% 47% 52%
So, 1998 still would be the forecasted victory year for the computers.
This linear regression shows a 4.4% annual increase average for the
computers.
Again, it's not a very serious forecast...but it might be close!
Kerrigan42
they're ahead, because Mr. Kirkland has been thinking *really* hard...
Cheers,
Tom
D Kirkland
Good thing you said "probably", as you do not know what my ideas are. :)
: Don't think that all of us are not trying to
: solve some of the obvious computer-like problems current programs exhibit.
I don't!
: And don't think we aren't making progress either. It's just evolutionary
: rather than revolutionary, but just as steady an improvement as you would
: expect/hope for.
Yes, it's kind of like building a race car. It's a hell of a lot harder
getting the second 1000 horsepower than it is the first 1000 horsepower.
And when you finally do get to 2000 horsepower, darn it but it still
won't go twice as fast as it did with 1000 horsepower!
: Once you "jump into the ring" and give this a whirl, you
: can then get by with making statements like the above.
I can't get by with making such statements now? :(
: Until then, I can't
: count the number of people saying "when I design a program like I think it should
: be designed, look out." This goes for amateurs as well as a former world
: champion. It's *not* easy.
Well, it looks like cake to me! (Please, I'm joking with this one!)
: Done correctly, it *can* be fun. It *is* a
: heck of a lot of work. Ask how many ICC'ers see me on after 1am CST. As
: long as it continues to be fun, I'm in for all I can do. However, please
: don't assume that all we are after is raw speed. I take a lot of heat about
: Crafty's huge book. "why don't you make it more selective so it will only
: play lines that it understaands?" My response is that I want to improve its
: knowledge so it can play *any* opening system equally well. It's doing better
: than Cray Blitz ever did in this respect, and it's continuing to get better. I
: want it to "eavesdrop" on strong players by looking at their games, and then
: decide "Hmmm.. I like this position and will try it given the chance." or "Hmm..
: this doesn't suit my open style of play very well, think I'll avoid it." For
: the long run, obviously, this will make my life a lot simpler. Just feed it
: current opening theory and let it run on its own. A lot of promise, but a
: difficult task to accomplish this.
:
: I don't intend for this to be taken as a flame, by any stretch of your
: imagination. Rather, that it be taken as an explanation of what I (and many
: others) are trying to do. Believe me, we want to eliminate Kh1, and g3/Bb5
: as much as you do. :)
Yes, I know. Just a nice way of saying "Hey kid, your still wet behind
the ears!". :)
Well, this is a bit nicer and much more of a response than I expected.
But there is not really anything here that I did not already know.
Okay, so there are a number of very good (world class even) chess programmers
that read and post to this group. And, yes, I'm pretty new to chess
programming compared to most people on here (I have been researching chess
programming just over a year now).
So I should be a bit red in the face right now.
But wait! It gets worse!
Well..., maybe I shouldn't mention that I have never been to high school.
(I'm sure it shows in my writing though.) And I'm pretty sure that saying
that I got into chess programming so I could write a chess program for the
HP48 (that's right, the calculator!) wouldn't impress anyone. And I surely
should not tell you people that I can't program anything else worth a damn!
There is even more, but this should keep you people laughing for a while...
So my face should be glowing a very bright red now..., right?
Well maybe so. But I really do understand chess programming very well.
And I am tired of keeping quiet about it. And, I'm too damn selfish
to just give my ideas to the world. (They're MINE! *pout*)
So is there really a chance that *any* of my ideas are really any good?
Well I don't make such statements as I made litely. Which means I
think so. But most of my ideas would be very limited, or totally useless,
on the HP48. I'm only getting about 100 nodes per second on the HP48.
And I'll *never* be able to program other machines anywhere near as good
as someone like Mr. Hyatt. So I'm going to look into some other options.
Well, I could say more, but I think I have pretty much told where I'm
stand. Maybe, for now, we should just wait and see how good my HP48 chess
program is going to be...? I am a very *slow* programmer, so it's going
to take a bit of time. It's a pretty sure bet that it will never beat
Kasparov! :)
But hey, just for fun, why don't some of you "experts" give me some
guesses as to what kind of playing strength you think I should be able
the get out of the wimpy HP48. (Please!)
: Bob
:
:
: --
: Robert Hyatt Computer and Information Sciences
: hy...@cis.uab.edu University of Alabama at Birmingham
: (205) 934-2213 115A Campbell Hall, UAB Station
: (205) 934-5473 FAX Birmingham, AL 35294-1170
Thanks Bob! (Okay, my wrist has been slapped!)
And Now that I have made a fool out of myself, I think I will
shut up for a bit (a day..., a week..., a month..., a year...,
aw hell, I'll just go hide under a rock!)
dan
Joe Stella
dbk...@cc.utah.edu (D Kirkland) writes:
>>So is there really a chance that *any* of my ideas are really any good?
How can anyone answer that for you, after you have already stated that you
aren't going to tell us what your ideas are?
>>And I'll *never* be able to program other machines anywhere near as good
>>as someone like Mr. Hyatt.
Why not?
If you can program a calculator, then why can't you program in a high-level
language like C? Programming in C is much less tedious than what you
are doing now.
Sorry, but it sounds to me like you are just making excuses. It's a lot
easier to say "I have great ideas" than it is to prove it. I don't mean
this as a flame, any more than Bob did; I just think you should get
yourself a real computer and a C compiler. You won't be such a "slow"
programmer anymore once you do this. Right now, you are just slow because of
method of programming you have chosen.
Joe S.
Joe Stella
dbk...@cc.utah.edu (D Kirkland) writes:
>>Oh boy! Another *flame* that is not meant to be a flame!
I second Bob's suggestion that you need to get a thicker skin. There
is a difference between a flame and a criticism. If you don't like to
be criticized, then don't post.
>>And I must say, you people are a pretty close minded group.
>>You spend untold amounts of time trying to improve your chess programs.
>>Clearly, you think there are still ways to improve chess playing programs.
>>Yet when someone says they have some ideas that may improve a computer's
>>chess playing abilities, all you can come up with is a bunch of lame
>>flames.
What kind of reaction do you think we *should* have had?
I never said that your ideas are not going to work. Part of the reason
why I suggested that you should start programming your ideas is so that
you can see if they really are good or not. If they are, you can be sure
that all of us who are already programming would welcome your efforts and
contributions.
If you don't have the money to buy a computer yet, well I guess that is
indeed a big stumbling block. Just remember though, you don't need a
Pentium 133 with 16 Mb RAM just to test your ideas. A used 386 running
DOS 6.22 and the GNU C compiler (it's free) would be good enough.
I hope you don't think *this* was a flame...
Joe S.
D Kirkland
: they're ahead, because Mr. Kirkland has been thinking *really* hard...
Please NO!
It will be no fun if there is nobody to beat...
dan
D Kirkland
: -->some ideas that could greatly improve computer chess? If so, THEN
: -->GIVE IT UP!
: -->
: -->Because if you people don't come up with some good ideas of your own,
: -->then one day you will find your program getting *creamed* by a program
: -->using my ideas!
WOOPS! There clearly should have been a smiley after this part!
While I do have a couple of ideas that I think *may* be an improvement
over current chess programs, I also realize that these ideas are untested
and should be treated as such.
: <WHHOOOFFFF!!!!> (flame on)
:
: First, I'd like to suggest that you either get thicker skin, or else take
: your posts somewhere else. If you don't want any criticism, it's best to
: simply shut up. I responded to your original post simply because of the
: naive point of view you expressed, namely that none of "us" have done as
: much as we should in trying to emulate human thought.
I'm sorry. I did not realize I had expresses that point of view.
What I said:
: -->Yes, we have heard (well most of us anyway). I'm not sure if Deep
: -->Blue as actually played yet (last I heard, it was the Deep Blue
: -->software on the old hardware).
: -->
: -->Unless they have come up with something very different from what
: -->we have seen so far, Deep Blue does *not* have much of a chance of
: -->winning the match. When compared to the top players in the world,
: -->current chess algorithms come up short. And I just don't see how
: -->a faster, deeper search is going to make up for this.
: -->
: -->So, is there any hope that computer chess will beat the world
: -->champion in the near future?
: -->
: -->Well, if I actually ever get around to putting my ideas in a
: -->program, I think there is a good chance of seeing even common
: -->desktop computers beat the world champion.
: -->
: -->Until then...?
: -->dan
It seems that you pretty much agreed with the part about Deep Blue
not having much of a chance in the up comming match. You did go
on to add that you think Deep Blue may have a chance after some
more tuning and such. If that tuning helps improve a couple of
areas very much, I would maybe agree.
And I don't see how my statement about my ideas express the point
of view you mentioned. I don't see how my mention of my ideas
degrads anybody at all! I put the line "Until then...?" because
I realize that my ideas may become obsolete before I ever get
them into a program.
: If you'd read as much as the rest of us, you'd realize that this is a bogus
: concept. *unless* you think that the 200+ people that have contributed to
: computer chess over the years are a bunch of complete idiots.
Again, it seems to me that you have read something into what I said
that just is not there...?
: My point of view has always been the following: Someone suggests an idea,
: I either try it, or report the results if I've already tried it. I have yet
: to consider any new idea as "sheer idiocy" without a test. However, I *am*
: willing to put my money where my mouth is and try the suggestion even if I
: don't think it'll work, and then report the results regardless of whether or
: not I was right. See the famous SEE discussion a while back. Turned out
: that SEE and MVV/LVA where much closer than I thought if I culled the forward
: pruning I do with SEE. Surprising, yes, but it didn't give me a moment's
: hesitation to try and report.
Yes, I was here for that discussion. And I also remember getting very
quick responses from the emails that I sent you. Seems you are *always*
on the computer.
: When someone comes along and says, "I have these *great* ideas that will make
: all the other programs look silly," then I and many others reserve the right to
: remain skeptical of such snake-oil claims. If you have something you think is
: cute, want it kept private, I've done many such tests and *not* kept the stuff
: in Crafty to avoid making the idea public. However, if you (a) don't want
: those of us that have been doing this for *years* to try your ideas for you
: and (b) can't implement them yourself, then it makes little sense to cry "foul"
: when we greet you with well-deserved skepticism. If a former world champion
: (Botvinnik) can't deliver on his promises (ever) then what would lead any of
: us to believe that you can, with absolutely no data.
I did not really expect anybody to believe me. But I had hoped for more
positive responses. Seems like anytime someone that is not a well
established chess programmer says anything about having some ideas, that
only negative vibes are given in response...
: You want to keep secrets, keep 'em. When you show up on ICC or at an ACM
: event with a program, and it is reasonably (or very) successful against
: Crafty, Ferret, Zarkov, Wchess, Genius, Fritz, Now, Socrates, Deep Blue,
: HiTech, or any of the rest of the programs that I didn't name, then you'll
: get our attention. Otherwise, publish your ideas and let those of us with
: the necessary skill and experience implement and test the ones that seem
: appropriate. The third alternative is to do none of the above, and then
: flame away when you get grilled for specifics that aren't forthcoming, nor
: is any example of how these mystery ideas work.
:
: This is a lot closer to a flame than my original post, because I was simply
: point out that, by myself, I have invested many man-years in computer chess,
: and I'm *not* a dummy programmer. There are many others as good or better
: that have also spent a lot of time doing this. When you slide into this
: newsgroup like a turd into a toilet bowl and start telling us how what we are
: doing is "all wrong", better put on that asbestos parka first. We do *lots*
: that's wrong, but if you check program performance improvements over the years,
: we are also doing *lots* that's right.
I never said, nor did I *ever* mean to imply that you were a dummy
programmer. In fact, I said that I would never be as good a programmer
as you are, and I meant it! And I *never* said anybody was doing things
"all wrong" (did I? what's with the quotes?)...? Again, it seems you
have read much more into what I said then I ever intended to be there.
: <whifff> (blowing out the flame).
:
: Bob
:
:
: BTW, this *is* a <flame> :)
Kewl! But a little over doing it maybe?
: --
: Robert Hyatt Computer and Information Sciences
: hy...@cis.uab.edu University of Alabama at Birmingham
: (205) 934-2213 115A Campbell Hall, UAB Station
: (205) 934-5473 FAX Birmingham, AL 35294-1170
Sorry to bring out such negative stuff from you guys.
Like I said in my second post, maybe we should wait until I get
my HP48 chess program finished. Then maybe we all can see if I
even know what a chess program is supossed to do...?
Sorry...
dan
D Kirkland
: : they're ahead, because Mr. Kirkland has been thinking *really* hard...
:
: Please NO!
:
: It will be no fun if there is nobody to beat...
WOOPS! Another place where I should have put in a smiley!
Heh, sorry...
dan
D Kirkland
:
: >>So is there really a chance that *any* of my ideas are really any good?
:
: How can anyone answer that for you, after you have already stated that you
: aren't going to tell us what your ideas are?
If you read the following paragraph, you should have realized that I did
*not* expect an answer from others...
: >>And I'll *never* be able to program other machines anywhere near as good
: >>as someone like Mr. Hyatt.
:
: Why not?
:
: If you can program a calculator, then why can't you program in a high-level
: language like C? Programming in C is much less tedious than what you
: are doing now.
:
: Sorry, but it sounds to me like you are just making excuses. It's a lot
: easier to say "I have great ideas" than it is to prove it. I don't mean
: this as a flame, any more than Bob did; I just think you should get
: yourself a real computer and a C compiler. You won't be such a "slow"
: programmer anymore once you do this. Right now, you are just slow because of
: method of programming you have chosen.
:
: Joe S.
Oh boy! Another *flame* that is not meant to be a flame!
Sure I can program the calculator, and I'm pretty good at it...
BUT, I am *very* slow, even at programing the calculator, when
compared to others.
Also, let's take writing for example. Some people are very *fast*
writers, and many are not. I am a *very* slow writer. It can take
me 60+ minutes to write a silly little post like this. My programming
is much the same, *very* slow.
And then, there is my disability...
Yes, I am disabled. And it very much compounds my problems (and speed!).
Still, I could learn so program on another platform. It would likely
take me a bit longer to learn than it does with most other people.
And it would take me even longer to write the program once I got into
the swing of things. But this IS one of my options...
The first thing I would need is a computer. But right now, a computer
is down a bit on my list. The state has helped me get an okay apartment,
but it did not come with any furniture. And, I am a bit tired of sleeping
on the floor. I have enough money now to buy a bed, and even a TV (yes,
I have my priorities right! :). But I don't see a computer any time soon.
But even with all the right tools and such, it would take a long time.
So I am going to look at some other options (I have already talked to a
local student programer, but just talk...).
Now that has been said..., it's my turn to flame a little right back!
If you will notice, I have *never* asked that anyone believe what I have
been saying! I said it mostly to see what kind of response I would get.
And while I had some hope of getting something a bit different, I have
got pretty much what I expected.
And I must say, you people are a pretty close minded group.
You spend untold amounts of time trying to improve your chess programs.
Clearly, you think there are still ways to improve chess playing programs.
Yet when someone says they have some ideas that may improve a computer's
chess playing abilities, all you can come up with is a bunch of lame
flames. (And please, call them what they are! None of this "I don't
mean this as a flame" crap!)
Is it really so hard to accept the posibility that someone could have
some ideas that could greatly improve computer chess? If so, THEN
GIVE IT UP!
Because if you people don't come up with some good ideas of your own,
then one day you will find your program getting *creamed* by a program
using my ideas!
(And if no one follows up with any lame flames or such, I won't follow
up with any more claims. As both are obviously wasted!)
dan
Gary M. Watson
>And I must say, you people are a pretty close minded group.
>
>You spend untold amounts of time trying to improve your chess programs.
>Clearly, you think there are still ways to improve chess playing programs.
>Yet when someone says they have some ideas that may improve a computer's
>chess playing abilities, all you can come up with is a bunch of lame
>flames. (And please, call them what they are! None of this "I don't
>mean this as a flame" crap!)
You have yet to show any of us that you have the first clue how
the existing chess programs work, which previous "clever" ideas
have been tried and found to be unworkable over the last 20
years of some of the greatest minds in computer science, or
that you have any understanding of the basics of computer
science. You say you have "ideas", but you know there's an
old engineering axiom that says "everybody has a brilliant idea
to solve the problem which will not work". There's more of a
probability that you fall into this category than you are
holding some secret to the Unified Field Theory.
You claim to have ideaS (plural). Want some credibility? Tell
us about merely ONE of your brilliant ideas and we'll see if
you know squat or are just a braggard with nothing to brag
about. Or, alternately, look at one of the publically available
chess programs source code (e.g. Crafty) and tell us one or
two things it does incorrectly or could do better. If you're
such a genius, that should be a piece of cake.
>Is it really so hard to accept the posibility that someone could have
>some ideas that could greatly improve computer chess? If so, THEN
>GIVE IT UP!
It's not hard to accept the possibility that someone has all kinds
of ideas that could improve computer chess, maybe even dramatically.
It's just hard to accept the possibility that _you_ have any
useful ideas. You sound like just another arrogant, clueless
newbie to me. Put up or shut up.
--
Gary M. Watson
Electronic Engineer Internet: tr...@netcom.com
Sigma-Trimm Technologies, A Division of Robroy Industries
350 Pilot Road
Las Vegas, NV 89119 Phone: (800) 423-2024 x2115
** Enclosures for SCSI, RAID, Fibre Channel, and SSA **
Robert Hyatt
D Kirkland <dbk...@cc.utah.edu> wrote:
-->: dbk...@cc.utah.edu (D Kirkland) writes:
-->:
-->: >>So is there really a chance that *any* of my ideas are really any good?
-->:
-->: How can anyone answer that for you, after you have already stated that you
-->: aren't going to tell us what your ideas are?
-->
-->If you read the following paragraph, you should have realized that I did
-->*not* expect an answer from others...
-->
-->: >>And I'll *never* be able to program other machines anywhere near as good
-->: >>as someone like Mr. Hyatt.
-->:
-->: Why not?
-->:
-->: If you can program a calculator, then why can't you program in a high-level
-->: language like C? Programming in C is much less tedious than what you
-->: are doing now.
-->:
-->: Sorry, but it sounds to me like you are just making excuses. It's a lot
-->: easier to say "I have great ideas" than it is to prove it. I don't mean
-->: this as a flame, any more than Bob did; I just think you should get
-->: yourself a real computer and a C compiler. You won't be such a "slow"
-->: programmer anymore once you do this. Right now, you are just slow because of
-->: method of programming you have chosen.
-->:
-->: Joe S.
-->
-->Oh boy! Another *flame* that is not meant to be a flame!
-->
-->Sure I can program the calculator, and I'm pretty good at it...
-->BUT, I am *very* slow, even at programing the calculator, when
-->compared to others.
-->
-->Also, let's take writing for example. Some people are very *fast*
-->writers, and many are not. I am a *very* slow writer. It can take
-->me 60+ minutes to write a silly little post like this. My programming
-->is much the same, *very* slow.
-->
-->And then, there is my disability...
-->Yes, I am disabled. And it very much compounds my problems (and speed!).
-->
-->Still, I could learn so program on another platform. It would likely
-->take me a bit longer to learn than it does with most other people.
-->And it would take me even longer to write the program once I got into
-->the swing of things. But this IS one of my options...
-->
-->The first thing I would need is a computer. But right now, a computer
-->is down a bit on my list. The state has helped me get an okay apartment,
-->but it did not come with any furniture. And, I am a bit tired of sleeping
-->on the floor. I have enough money now to buy a bed, and even a TV (yes,
-->I have my priorities right! :). But I don't see a computer any time soon.
-->
-->But even with all the right tools and such, it would take a long time.
-->So I am going to look at some other options (I have already talked to a
-->local student programer, but just talk...).
-->
-->
-->Now that has been said..., it's my turn to flame a little right back!
-->
-->If you will notice, I have *never* asked that anyone believe what I have
-->been saying! I said it mostly to see what kind of response I would get.
-->And while I had some hope of getting something a bit different, I have
-->got pretty much what I expected.
-->
-->And I must say, you people are a pretty close minded group.
-->
-->You spend untold amounts of time trying to improve your chess programs.
-->Clearly, you think there are still ways to improve chess playing programs.
-->Yet when someone says they have some ideas that may improve a computer's
-->chess playing abilities, all you can come up with is a bunch of lame
-->flames. (And please, call them what they are! None of this "I don't
-->mean this as a flame" crap!)
-->
-->Is it really so hard to accept the posibility that someone could have
-->some ideas that could greatly improve computer chess? If so, THEN
-->GIVE IT UP!
-->
-->then one day you will find your program getting *creamed* by a program
-->using my ideas!
-->
-->(And if no one follows up with any lame flames or such, I won't follow
-->up with any more claims. As both are obviously wasted!)
-->
-->dan
<WHHOOOFFFF!!!!> (flame on)
First, I'd like to suggest that you either get thicker skin, or else take
your posts somewhere else. If you don't want any criticism, it's best to
simply shut up. I responded to your original post simply because of the
naive point of view you expressed, namely that none of "us" have done as
much as we should in trying to emulate human thought.
If you'd read as much as the rest of us, you'd realize that this is a bogus
concept. *unless* you think that the 200+ people that have contributed to
computer chess over the years are a bunch of complete idiots.
My point of view has always been the following: Someone suggests an idea,
I either try it, or report the results if I've already tried it. I have yet
to consider any new idea as "sheer idiocy" without a test. However, I *am*
willing to put my money where my mouth is and try the suggestion even if I
don't think it'll work, and then report the results regardless of whether or
not I was right. See the famous SEE discussion a while back. Turned out
that SEE and MVV/LVA where much closer than I thought if I culled the forward
pruning I do with SEE. Surprising, yes, but it didn't give me a moment's
hesitation to try and report.
When someone comes along and says, "I have these *great* ideas that will make
all the other programs look silly," then I and many others reserve the right to
remain skeptical of such snake-oil claims. If you have something you think is
cute, want it kept private, I've done many such tests and *not* kept the stuff
in Crafty to avoid making the idea public. However, if you (a) don't want
those of us that have been doing this for *years* to try your ideas for you
and (b) can't implement them yourself, then it makes little sense to cry "foul"
when we greet you with well-deserved skepticism. If a former world champion
(Botvinnik) can't deliver on his promises (ever) then what would lead any of
us to believe that you can, with absolutely no data.
You want to keep secrets, keep 'em. When you show up on ICC or at an ACM
event with a program, and it is reasonably (or very) successful against
Crafty, Ferret, Zarkov, Wchess, Genius, Fritz, Now, Socrates, Deep Blue,
HiTech, or any of the rest of the programs that I didn't name, then you'll
get our attention. Otherwise, publish your ideas and let those of us with
the necessary skill and experience implement and test the ones that seem
appropriate. The third alternative is to do none of the above, and then
flame away when you get grilled for specifics that aren't forthcoming, nor
is any example of how these mystery ideas work.
This is a lot closer to a flame than my original post, because I was simply
point out that, by myself, I have invested many man-years in computer chess,
and I'm *not* a dummy programmer. There are many others as good or better
that have also spent a lot of time doing this. When you slide into this
newsgroup like a turd into a toilet bowl and start telling us how what we are
doing is "all wrong", better put on that asbestos parka first. We do *lots*
that's wrong, but if you check program performance improvements over the years,
we are also doing *lots* that's right.
<whifff> (blowing out the flame).
Bob
BTW, this *is* a <flame> :)
--
Peter Gillgasch
You are close minded Bob ;) The guy has promised to buy a
telly so there are chances that he leaves us weirdos alone
in the future. But I am still puzzled where you can buy a
calculator with internet support...
-- Peter
------------------------------------------------------------
Peter W. Gillgasch
Klosterweg 28/I-113 email gil...@ira.uka.de
76131 Karlsruhe/Germany Phone ++49/(0)721/6904255
Robert Hyatt
D Kirkland <dbk...@cc.utah.edu> wrote:
Maybe you are reading between the lines here. in your original and follow
up post, you made two points:
1. you have some ideas that are somehow different than what is regarded
as current "state-of-the-art". I don't have a problem with that as new
ideas are always welcome. While everyone is skeptical of such comments, since
the highway of computer chess is littered with litterally hundreds of such
corpses, no one will put you down for having new ideas.
2. your second point went overboard, in that you directly lambasted many
programmers for doing this "all wrong" and not spending enough time trying
to emulate human thought. This was what I took issue with. Have you read
DeGroot's "Thought and Choice in Chess"? He spent a heck of a lot of time
trying to figure out how GM's play and analyze. Not much resulted from
this as the problem is very much non-trivial.
I simply suggest the following: if you have ideas you want to share, or
want me or others to try, feel free to suggest. If you want to keep them
to yourself to avoid giving away some competitive edge in the future, feel
free to do so. However, don't infer that a lot of work has gone "down the
drain". Either *everyone's* stupid as all get out, or else...
I only took issue with "you guys are going about this the wrong way."
A statement like that takes more than "I have an idea" to support it. It
takes empirical data.
D Kirkland
: >
: >You spend untold amounts of time trying to improve your chess programs.
: >Clearly, you think there are still ways to improve chess playing programs.
: >Yet when someone says they have some ideas that may improve a computer's
: >chess playing abilities, all you can come up with is a bunch of lame
: >flames. (And please, call them what they are! None of this "I don't
: >mean this as a flame" crap!)
:
: You have yet to show any of us that you have the first clue how
: the existing chess programs work, which previous "clever" ideas
: have been tried and found to be unworkable over the last 20
: years of some of the greatest minds in computer science, or
: that you have any understanding of the basics of computer
: science. You say you have "ideas", but you know there's an
: old engineering axiom that says "everybody has a brilliant idea
: to solve the problem which will not work". There's more of a
: probability that you fall into this category than you are
: holding some secret to the Unified Field Theory.
You are right. I did say something about waiting until my HP48
chess program was finished to see if I had any idea what was up.
: You claim to have ideaS (plural). Want some credibility? Tell
: us about merely ONE of your brilliant ideas and we'll see if
: you know squat or are just a braggard with nothing to brag
: about. Or, alternately, look at one of the publically available
: chess programs source code (e.g. Crafty) and tell us one or
: two things it does incorrectly or could do better. If you're
: such a genius, that should be a piece of cake.
Well, really there are just two major ideas. Then there are many
more smaller ideas that are supposed to help make the major ideas
work (I hope anyway). On there own, none of the ideas are likely
any good.
"brilliant", "genius"?
Okay, I did say something about a common desktop beating the world
champion. But I also said "I think" and "chance". So this is just
my opinion and I'm clearly not sure. And I would never suggest using
such terms as those above with clearly unproven ideas.
But thanks for trying! :)
: >Is it really so hard to accept the posibility that someone could have
: >some ideas that could greatly improve computer chess? If so, THEN
: >GIVE IT UP!
:) :) :)
: It's not hard to accept the possibility that someone has all kinds
: of ideas that could improve computer chess, maybe even dramatically.
: It's just hard to accept the possibility that _you_ have any
: useful ideas. You sound like just another arrogant, clueless
: newbie to me. Put up or shut up.
Yes, you are probably right!
But then again...? :)
dan
: --
John Coggi
wrote:
|
| The first thing I would need is a computer. But right now, a computer
| is down a bit on my list. The state has helped me get an okay apartment,
| but it did not come with any furniture. And, I am a bit tired of sleeping
| on the floor. I have enough money now to buy a bed, and even a TV (yes,
| I have my priorities right! :). But I don't see a computer any time soon.
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What? No computer! Are you saying you programmed your calculator to send
this USENET message? Now I'm impressed! Seriously, enough of this
"I've-got-a-secret-and-I'm-not-going-to-tell-you" nonsense. Put up or
shut up.
Deep Belch
--
John M. Coggi | "What I have written, I have written"
The Aerospace Corporation | P. Pilate, c. 35 AD
http://www.aero.org |
john_...@qmail2.aero.org |
----------------------------------------------------------------------
**** KEEP BILL OFF THE HIGHWAY **** SUPPORT YOUR INDEPENDENT ISP ****
Bruce Moreland
>
>Verification search? It can be proven that this doesn't work; You have a
> hashtable which will ALWAYS return >= beta. Besides,
> when DOES nullmove not work? I haven't seen a single
> GAMEPOSITION!
Null move screws up a lot. It tends to cause you to overlook some mate
threats, which is invariably fatal.
It also screws up if you use it too aggressively in endings.
Bob Hyatt is collecting null move failures, he has a lot of practical
examples.
bruce
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation.
Vincent Diepeveen
>Yes, it's kind of like building a race car. It's a hell of a lot harder
>getting the second 1000 horsepower than it is the first 1000 horsepower.
>And when you finally do get to 2000 horsepower, darn it but it still
>won't go twice as fast as it did with 1000 horsepower!
>I can't get by with making such statements now? :(
>: ...
>: Done correctly, it *can* be fun. It *is* a
>: heck of a lot of work. Ask how many ICC'ers see me on after 1am CST. As
>: long as it continues to be fun, I'm in for all I can do. However, please
>: don't assume that all we are after is raw speed.
>Yes, I know. Just a nice way of saying "Hey kid, your still wet behind
>the ears!". :)
Everyone is wet behind the ears i'm afraid. Don't be ashame: only the
thing that you write msg's for a large public should compensate for the
things you say; guys that DON'T say anything, but just listen and listen,
i hate them. Don't forget that almost 100% of ALL chessprogrammers read
this msg!
If you tell something wrong about there programm in this newsgroup,
that is something they WILL remember. They'll crusify you when they
get the chance. "You stupid writing analphabetic fool! My programm DOES
find that combination, you forgot to turn on it's hashtables. It uses
its hashtables for singular extensions needed to find that combination.".
Of course: the great public doesn't here from this...^8
They simply beleive some bad-programming guys publishing things, which
are tested on stupid programms.
Killer moves? Are working excellent, but how long has this already been known?
Refutation things? Doesn't work.
Countermove? Doesn't work.
Probability cutoff? Doesn't work. Of course, if you are a rook behind, then
it is probable that score will not change, but nullmove
already works very very fine there. Just remove extensions!
Verification search? It can be proven that this doesn't work; You have a
hashtable which will ALWAYS return >= beta. Besides,
when DOES nullmove not work? I haven't seen a single
GAMEPOSITION!
I mean: why not testing new phenomena's on STRONG or middlestrong programms;
when you test these things on a programm with a branching factor of 11, then
everything WILL work, even a random sorting!
However, even my own stupid program already has a branching
factor of < 3.5 when searching > 10 ply.
I use nullmove R=2 and hashtables (however > 10 ply loading factor is
much much greater then 1), no other forward pruning things.
With a branching factor < 4, then even checkextensions is then a problem.
Not to mention things like singular extensions which i also use.
I should remove them! (finding mating combinations is a problem then)
>Well, this is a bit nicer and much more of a response than I expected.
>But there is not really anything here that I did not already know.
How can you talk about things that are not known, that is not
rec.games.chess.computer but rec.future! :)
>Okay, so there are a number of very good (world class even) chess programmers
>that read and post to this group. And, yes, I'm pretty new to chess
>programming compared to most people on here (I have been researching chess
>programming just over a year now).
>So is there really a chance that *any* of my ideas are really any good?
Here i'll tell something Hyatt already mentionned in another msg few
weeks ago, so i guess that it is hard for me to say it better (my English
also sucks):
Humans use 'ideas'. computers use bits.
That is the REAL problem.
How do you convert ideas into bits?
That is not possible; you can only estimate it, or hardcode them.
>Well I don't make such statements as I made litely. Which means I
>think so. But most of my ideas would be very limited, or totally useless,
>on the HP48. I'm only getting about 100 nodes per second on the HP48.
>And I'll *never* be able to program other machines anywhere near as good
>as someone like Mr. Hyatt. So I'm going to look into some other options.
>
>Well, I could say more, but I think I have pretty much told where I'm
>stand. Maybe, for now, we should just wait and see how good my HP48 chess
>program is going to be...? I am a very *slow* programmer, so it's going
>to take a bit of time. It's a pretty sure bet that it will never beat
>Kasparov! :)
>
>But hey, just for fun, why don't some of you "experts" give me some
>guesses as to what kind of playing strength you think I should be able
>the get out of the wimpy HP48. (Please!)
>
That is what the DB-team currently is facing: all things are very
well handled by there programm; tactics (huge depth), openingsbook (special
guy in team to do that), but what if Kasparov doesn't make a tactical error,
nor an openingsbook error?
It is hard to beat a computer because of tactics.
When computers play, then a programm that gets more ply will always have
a chance to win, even if it has no knowledge.
For that reason depth is important. I guess you need at least > 10 ply
to overcome the most simplest tactics (including forced variations
from the viewpoint of humans) that show up every game.
For that reason 100 nodes a second will be a problem.
I get 6000 nodes a second on a P100, which is also a problem
(8 ply average in middlegame with 90 seconds a move). Only getting 8 ply
is simply not enough. I must get > 10 ply. So i'm working on that, i guess
you should to. May be a new HP?
I mean a DEC Alpha you can also call a calculation machine?
After analysing a lot of positions i figured out that 12 ply (in middlegame,
and checks not included) will in most games give you enough tactics to
play most games to prevent from walking into a tactical joke.
So assuming smart ideas are important, then knowledge is important.
For that reason i tried to implement knowledge, which will occupy me the
rest of my life i guess (but every year i live i guess my programm will
get better then other programms, as knowledge becomes more important
because computers are again faster! I guess a hundred others also thought
this...:) ).
Now assuming you don't have to worry about depth, then you have another
problem: knowledge consumes time and space.
As i'm not a bad player (please don't compare me with the profs!) i want
of course believe in knowledge. For that reason i'm putting knowledge
in my programm. I assume that chessprogramms, besides getting as much
plies as possible, need some basic knowledge. It is clear that currently
no programm does have this knowledge. However the more knowledge you put
in, the more CPU-time it eats. You forgot however that knowledge also
occupies memoryspace: You need advanced code. In order to store that you
need hashtables and things like that. I have 16 mb of memory, from which
14.5 mb are used for hashtables. The executable itself eats about 1 megabyte
(i need also space to generate semi-legal moves fast and space for things
like killer-tables etc).
For a 1 minute calculation 16 mb is enough. For a 2 minute calculation
it is NOT enough. I could do much better with 32 MB or more. With a 15 minutes
calculation ALL that 14 mb is entirely filled. about 8 mb of that 14.5 mb
is used for transpositiontables. The rest is purely used for knowledge.
I mean: i need the memory of a supercomputer or workstation to store knowledge
generated by a programm that is run on a slow pentium 100!
Have you thought of that: the huge trade-offs of knowledge?
Do you know the difference between bad and good bishops, bishop pair and
bishop knight?
>: Bob
>:
>:
>: --
>: Robert Hyatt Computer and Information Sciences
>: hy...@cis.uab.edu University of Alabama at Birmingham
>: (205) 934-2213 115A Campbell Hall, UAB Station
>: (205) 934-5473 FAX Birmingham, AL 35294-1170
>
>Thanks Bob! (Okay, my wrist has been slapped!)
>
>And Now that I have made a fool out of myself, I think I will
>shut up for a bit (a day..., a week..., a month..., a year...,
>aw hell, I'll just go hide under a rock!)
>
>dan
--
+--------------------------------------+
|| email : vdie...@cs.ruu.nl ||
|| Vincent Diepeveen ||
+======================================+
Robert Hyatt
Vincent Diepeveen <vdie...@cs.ruu.nl> wrote:
-->>Good thing you said "probably", as you do not know what my ideas are. :)
-->
-->>Yes, it's kind of like building a race car. It's a hell of a lot harder
-->>getting the second 1000 horsepower than it is the first 1000 horsepower.
-->>And when you finally do get to 2000 horsepower, darn it but it still
-->>won't go twice as fast as it did with 1000 horsepower!
-->
-->>I can't get by with making such statements now? :(
-->
-->>: ...
-->>: Done correctly, it *can* be fun. It *is* a
-->>: heck of a lot of work. Ask how many ICC'ers see me on after 1am CST. As
-->>: long as it continues to be fun, I'm in for all I can do. However, please
-->>: don't assume that all we are after is raw speed.
-->
-->>Yes, I know. Just a nice way of saying "Hey kid, your still wet behind
-->>the ears!". :)
-->
-->Everyone is wet behind the ears i'm afraid. Don't be ashame: only the
-->thing that you write msg's for a large public should compensate for the
-->things you say; guys that DON'T say anything, but just listen and listen,
-->i hate them. Don't forget that almost 100% of ALL chessprogrammers read
-->this msg!
-->
-->If you tell something wrong about there programm in this newsgroup,
-->that is something they WILL remember. They'll crusify you when they
-->get the chance. "You stupid writing analphabetic fool! My programm DOES
-->find that combination, you forgot to turn on it's hashtables. It uses
-->its hashtables for singular extensions needed to find that combination.".
-->
-->Of course: the great public doesn't here from this...^8
-->They simply beleive some bad-programming guys publishing things, which
-->are tested on stupid programms.
-->
-->Killer moves? Are working excellent, but how long has this already been known?
-->
-->Refutation things? Doesn't work.
-->Countermove? Doesn't work.
-->Probability cutoff? Doesn't work. Of course, if you are a rook behind, then
--> it is probable that score will not change, but nullmove
--> already works very very fine there. Just remove extensions!
-->
-->Verification search? It can be proven that this doesn't work; You have a
--> hashtable which will ALWAYS return >= beta. Besides,
--> when DOES nullmove not work? I haven't seen a single
--> GAMEPOSITION!
-->
-->I mean: why not testing new phenomena's on STRONG or middlestrong programms;
-->when you test these things on a programm with a branching factor of 11, then
-->everything WILL work, even a random sorting!
-->
-->However, even my own stupid program already has a branching
-->factor of < 3.5 when searching > 10 ply.
-->I use nullmove R=2 and hashtables (however > 10 ply loading factor is
-->much much greater then 1), no other forward pruning things.
-->
-->With a branching factor < 4, then even checkextensions is then a problem.
-->Not to mention things like singular extensions which i also use.
-->I should remove them! (finding mating combinations is a problem then)
-->
-->>Well, this is a bit nicer and much more of a response than I expected.
-->>But there is not really anything here that I did not already know.
-->
-->How can you talk about things that are not known, that is not
-->rec.games.chess.computer but rec.future! :)
-->
-->>Okay, so there are a number of very good (world class even) chess programmers
-->>that read and post to this group. And, yes, I'm pretty new to chess
-->>programming compared to most people on here (I have been researching chess
-->>programming just over a year now).
-->
-->>So is there really a chance that *any* of my ideas are really any good?
-->
-->Here i'll tell something Hyatt already mentionned in another msg few
-->weeks ago, so i guess that it is hard for me to say it better (my English
-->also sucks):
-->
-->Humans use 'ideas'. computers use bits.
-->That is the REAL problem.
-->
-->How do you convert ideas into bits?
-->That is not possible; you can only estimate it, or hardcode them.
-->
-->>Well I don't make such statements as I made litely. Which means I
-->>think so. But most of my ideas would be very limited, or totally useless,
-->>on the HP48. I'm only getting about 100 nodes per second on the HP48.
-->>And I'll *never* be able to program other machines anywhere near as good
-->>as someone like Mr. Hyatt. So I'm going to look into some other options.
-->>
-->>Well, I could say more, but I think I have pretty much told where I'm
-->>stand. Maybe, for now, we should just wait and see how good my HP48 chess
-->>program is going to be...? I am a very *slow* programmer, so it's going
-->>to take a bit of time. It's a pretty sure bet that it will never beat
-->>Kasparov! :)
-->>
-->>But hey, just for fun, why don't some of you "experts" give me some
-->>guesses as to what kind of playing strength you think I should be able
-->>the get out of the wimpy HP48. (Please!)
-->>
-->
-->That is what the DB-team currently is facing: all things are very
-->well handled by there programm; tactics (huge depth), openingsbook (special
-->guy in team to do that), but what if Kasparov doesn't make a tactical error,
-->nor an openingsbook error?
-->
-->It is hard to beat a computer because of tactics.
-->
-->When computers play, then a programm that gets more ply will always have
-->a chance to win, even if it has no knowledge.
-->
-->For that reason depth is important. I guess you need at least > 10 ply
-->to overcome the most simplest tactics (including forced variations
-->from the viewpoint of humans) that show up every game.
-->
-->For that reason 100 nodes a second will be a problem.
-->I get 6000 nodes a second on a P100, which is also a problem
-->(8 ply average in middlegame with 90 seconds a move). Only getting 8 ply
-->is simply not enough. I must get > 10 ply. So i'm working on that, i guess
-->you should to. May be a new HP?
-->
-->I mean a DEC Alpha you can also call a calculation machine?
-->
-->After analysing a lot of positions i figured out that 12 ply (in middlegame,
-->and checks not included) will in most games give you enough tactics to
-->play most games to prevent from walking into a tactical joke.
-->
-->So assuming smart ideas are important, then knowledge is important.
-->
-->For that reason i tried to implement knowledge, which will occupy me the
-->rest of my life i guess (but every year i live i guess my programm will
-->get better then other programms, as knowledge becomes more important
-->because computers are again faster! I guess a hundred others also thought
-->this...:) ).
-->
-->Now assuming you don't have to worry about depth, then you have another
-->problem: knowledge consumes time and space.
-->
-->As i'm not a bad player (please don't compare me with the profs!) i want
-->of course believe in knowledge. For that reason i'm putting knowledge
-->in my programm. I assume that chessprogramms, besides getting as much
-->plies as possible, need some basic knowledge. It is clear that currently
-->no programm does have this knowledge. However the more knowledge you put
-->in, the more CPU-time it eats. You forgot however that knowledge also
-->occupies memoryspace: You need advanced code. In order to store that you
-->need hashtables and things like that. I have 16 mb of memory, from which
-->14.5 mb are used for hashtables. The executable itself eats about 1 megabyte
-->(i need also space to generate semi-legal moves fast and space for things
-->like killer-tables etc).
-->
-->For a 1 minute calculation 16 mb is enough. For a 2 minute calculation
-->it is NOT enough. I could do much better with 32 MB or more. With a 15 minutes
-->calculation ALL that 14 mb is entirely filled. about 8 mb of that 14.5 mb
-->is used for transpositiontables. The rest is purely used for knowledge.
-->
-->I mean: i need the memory of a supercomputer or workstation to store knowledge
-->generated by a programm that is run on a slow pentium 100!
-->
-->Have you thought of that: the huge trade-offs of knowledge?
-->Do you know the difference between bad and good bishops, bishop pair and
-->bishop knight?
-->
-->>: Bob
-->>:
-->>:
-->>: --
-->>: (205) 934-2213 115A Campbell Hall, UAB Station
-->>: (205) 934-5473 FAX Birmingham, AL 35294-1170
-->>
-->>Thanks Bob! (Okay, my wrist has been slapped!)
-->>
-->>And Now that I have made a fool out of myself, I think I will
-->>shut up for a bit (a day..., a week..., a month..., a year...,
-->>aw hell, I'll just go hide under a rock!)
-->>
-->>dan
You want a position where null-move fails: here's a "beaut":
<sorry, can't find it from home, will look when I get to my office
this morning>
This position is a mate in 2. Takes a *ten* ply search with null
move turned on with both Crafty and Ferret. Turn null off and it's
instant.
Rest assured that there are *plenty* of positions where null-move
search fails. Far more than most would suspect.
Vincent Diepeveen
>I did not really expect anybody to believe me. But I had hoped for more
>positive responses. Seems like anytime someone that is not a well
>established chess programmer says anything about having some ideas, that
>only negative vibes are given in response...
In this point i agree.
Few time ago i was shouting about sorting and ordering moves
should give the superprogramms much larger depths then they currently
get.
It seems that i was correct. It appears that most commercial programms
and the stronger amateur programms have put a lot of work in move ordering,
and i'm not only talking about hashtablemove, killermove, but a lot more,
where the supercomputers only do the already published things... ...which
gives a bad move ordering.
Also i told that getting 15+ to 20 ply should be no problem for
programms that can evaluate many million positions a second.
This also seems correct. In example calculations i used branching factor 4
with recursive nullmove r=2, extensions for check, singular extensions.
and hashtables.
Even my own young programm currently has got branching factor 3.76 above
10 ply (including first 10 ply). The number of alphabetacalls up to 10
(including 10) is less then 2 million (about 1 to 1.4 million for 10 ply).
If i consider this to be overhead, then branching factor is even much better,
about 3.2, so guys...
I have also a testprogramm, which i have no problems to mail around.
It only evaluates material.
It searches from opening about 18 ply. no hashtable,
just nullmove and killermoves... ^8
As soon as guys read well, then they say: OHHHHHHHHHHH, but your programm
only evaluates material!!!!!!!!!!!!!!!!
So: Bishop = Knight = 3, Pawn = 1, King = OO, Rook = 4.5, Queen = 10.
I suspect however that for EVERY evaluation, no matter how good it is,
of the position searching a certain depth there is a move ordering that
gives you a minimal alphabeta-tree!
Anyone disagree that it is possible NOT to get 20 ply?
If you don't, then i'll make the steps in the right deductive order for
you:
a) assumption: For every evaluationfunction f on a certain
depth d there is a minimal alphabetatreetree
b) for a 'stupid programm' only evaluating material it is possible to
get 20 ply. f = (sum material(side) - sum material(other side))
d = 20
c) It is possible to get 20 ply with every programm if you have an excellent
ordering for 20 ply.
[]
Vincent Diepeveen
vdie...@cs.ruu.nl
Robert Hyatt
-->>positive responses. Seems like anytime someone that is not a well
-->>established chess programmer says anything about having some ideas, that
-->>only negative vibes are given in response...
-->
-->In this point i agree.
-->Few time ago i was shouting about sorting and ordering moves
-->should give the superprogramms much larger depths then they currently
-->get.
-->
-->It seems that i was correct. It appears that most commercial programms
-->and the stronger amateur programms have put a lot of work in move ordering,
-->and i'm not only talking about hashtablemove, killermove, but a lot more,
-->where the supercomputers only do the already published things... ...which
-->gives a bad move ordering.
-->
-->Also i told that getting 15+ to 20 ply should be no problem for
-->programms that can evaluate many million positions a second.
-->This also seems correct. In example calculations i used branching factor 4
-->with recursive nullmove r=2, extensions for check, singular extensions.
-->and hashtables.
-->
-->Even my own young programm currently has got branching factor 3.76 above
-->10 ply (including first 10 ply). The number of alphabetacalls up to 10
-->(including 10) is less then 2 million (about 1 to 1.4 million for 10 ply).
-->If i consider this to be overhead, then branching factor is even much better,
-->about 3.2, so guys...
-->
-->I have also a testprogramm, which i have no problems to mail around.
-->It only evaluates material.
-->
-->It searches from opening about 18 ply. no hashtable,
-->just nullmove and killermoves... ^8
-->
-->As soon as guys read well, then they say: OHHHHHHHHHHH, but your programm
-->only evaluates material!!!!!!!!!!!!!!!!
-->So: Bishop = Knight = 3, Pawn = 1, King = OO, Rook = 4.5, Queen = 10.
-->
-->I suspect however that for EVERY evaluation, no matter how good it is,
-->of the position searching a certain depth there is a move ordering that
-->gives you a minimal alphabeta-tree!
-->
-->Anyone disagree that it is possible NOT to get 20 ply?
-->
Yes. First, getting 14 (if you can do that in real positions) is
*not* "close to 20". you are 6 short, and at a very optimistic branching
factor of 3, this leaves you needing a factor of 3^6=729. Not much way
to wave your hands and magically order the tree to make that go away.
In Crafty, I can reach 10 in a reasonable amount of time from the opening
position, but this is an artificial position where the q-search is very
small compared with positions that arise 10 moves down the game tree.
I haven't seen *any* program search 14 plies exhaustive in the middlegame
*including* deep blue, deep thought and cray blitz. In fact, I haven't
seen any that get a *real* 10 ply search in the middlegame, without some
selective pruning or heavy use of null-move, which reduces the effective
search depth.
We all are practitioners of null-move searching, but, from experience,
it is *not* free. If I compare search depths between Crafty and Cray Blitz,
the comparison is very good, because CB used R=1, non-recursive, for a very
conservative null-move search, while Crafty uses the traditional R=2
recursive form. however, for the same depth, Cray Blitz will win nearly
every game, because it doesn't make as many tactical mistakes. Luckily,
R=2 lets crafty search deeper than Cray Blitz in the same time, so it's an
ofsetting thing. I like R=2, because I search one ply deeper positionally,
although I make more positional/tactical mistakes due to null move pruning.
The extra ply seems worth it, although when I see some of the problems it
causes (classic position is BK at g8, BP's at h7 g6 f7, WB at f7, and the
WQ on the a6 diagonal so it can reach a6 and threaten mate at g7. null
move pruning will make this take at least a couple of extra plies to see,
because it won't realize that after Qh6, that playing a null may cut the
depth to 0 and it will overlook the mate threat. All of us see this
problem, once you play enough games that you start getting attacked. If
you take a problematic position, turn null move off, it will immediately spot
the threat and take action, not letting the null move blind it.
-->If you don't, then i'll make the steps in the right deductive order for
-->you:
-->
-->a) assumption: For every evaluationfunction f on a certain
--> depth d there is a minimal alphabetatreetree
True, Knuth/Moore proved this in their now-famous paper 20+ years
ago. The evaluation function has nothing to do with it however, For
the *same* tree, the search space is constant, regardless of the evaluation
you use, unless you somehow let the evaluation control the shape of the
tree by extending when eval >x or when eval < y for example. Otherwise,
everything's a constant. You may get two different paths, with two different
scores, but with exactly the same number of nodes, exception above noted
however.
-->b) for a 'stupid programm' only evaluating material it is possible to
--> get 20 ply. f = (sum material(side) - sum material(other side))
--> d = 20
I don't agree with this. there's been *plenty* of material-only tactical
searchers, *exactly none* have reached 20 plies, on some pretty fast
machines. See below for specific mathematical refutation.
-->c) It is possible to get 20 ply with every programm if you have an excellent
--> ordering for 20 ply.
I certainly don't agree with this. do the alpha/beta math: Rough approximation
20 plies, tree size=2*38^10 (2 times 38 to the 10th power where 38 is the
typical branching factor.) This is straight from Knuth/Moore and is directly
provable. Null move reduces this because it prunes away parts of the tree
without knowing that it is safe to do so. Many claim a factor of 20x when
using R=2 recursive null move, so lets take that. That gives
2*38^10 / 20 = 38^10/10. Personally, I don't have a clue of how to search
38^10 nodes. 38^4 is 2 million, 38^8 is 4 trillion. we are to 16 plies
now and Deep Blue might reach 4 trillion in an hour or two if it's lucky.
Then you get to multiply by 1444 again to get those last two 38's in there,
and that's not reachable, I don't care what kind of ordering you do. Good
ordering can take you very close to optimal alpha/beta search space, but it
*can't* take you below it. It's a clear lower bound to the total search
space, and there are two ways to solve this problem: (a) search faster or
(b) forware prune to reduce the "38" to a smaller number. Ordering won't
cut it.
D Kirkland
:
: I suspect however that for EVERY evaluation, no matter how good it is,
: of the position searching a certain depth there is a move ordering that
: gives you a minimal alphabeta-tree!
:
: Anyone disagree that it is possible NOT to get 20 ply?
Well, you could take some 'average' number of moves and use it to
calculate how many moves would have to be made with perfect move
ordering...
But then, have you ever seen a program with perfect move ordering?
I think not! So 'real world' move ordering would be quite a bit
greater than any such calculation.
dan
D Kirkland
:
: Maybe you are reading between the lines here. in your original and follow
: up post, you made two points:
:
: 1. you have some ideas that are somehow different than what is regarded
: ideas are always welcome. While everyone is skeptical of such comments, since
: the highway of computer chess is littered with litterally hundreds of such
: corpses, no one will put you down for having new ideas.
Yes, I said something like this.
: 2. your second point went overboard, in that you directly lambasted many
: programmers for doing this "all wrong" and not spending enough time trying
: to emulate human thought. This was what I took issue with. Have you read
: DeGroot's "Thought and Choice in Chess"? He spent a heck of a lot of time
: trying to figure out how GM's play and analyze. Not much resulted from
: this as the problem is very much non-trivial.
I *never* said *anything* like this!
As I pointed out in my last post, this is not even close to anything
that I said. What's up Bob? It's not like you to accuse someone of
saying something they did *not* say, but I clearly never said anything
of this sort. And this thread is just not that old. It's not very
hard to scan back and see exactly what I did say.
: I simply suggest the following: if you have ideas you want to share, or
: want me or others to try, feel free to suggest. If you want to keep them
: to yourself to avoid giving away some competitive edge in the future, feel
: free to do so. However, don't infer that a lot of work has gone "down the
: drain". Either *everyone's* stupid as all get out, or else...
:
: I only took issue with "you guys are going about this the wrong way."
: A statement like that takes more than "I have an idea" to support it. It
: takes empirical data.
Again, this is wrong! I DID *NOT* SAY THIS! You should get your facts
straight before accusing someone of something. Because it's just *not*
very nice to make false accusations!
dan
D Kirkland
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:
: What? No computer! Are you saying you programmed your calculator to send
: this USENET message? Now I'm impressed! Seriously, enough of this
: "I've-got-a-secret-and-I'm-not-going-to-tell-you" nonsense. Put up or
: shut up.
Well, it's easier to connect to the net from the HP48 than it is to
write a good chess program.
And about the "Put up or shut up." ...?
Kiss off! I will do what I damn well feel like doing!
dan
Johanes Suhardjo
|> Null move screws up a lot. It tends to cause you to overlook some mate
|> threats, which is invariably fatal.
|>
|> It also screws up if you use it too aggressively in endings.
I also observe that null move screws up in end game test positions.
I put in
if (end_game) don't do recursive_null
in my program.
The problem is the program becomes so complicated, there are a lot of
if (conditionA) do this
[else] if (conditionB) don't do that
Any comment/suggestion?
Johanes Suhardjo (joh...@farida.cc.nd.edu)
--
The older a man gets, the farther he had to walk to school as a boy.
Hyborean
Bruce Moreland
bruce
In article <4cvisv$d...@news.cc.utah.edu>, dbk...@cc.utah.edu says...
--
Robert Hyatt
Vincent Diepeveen <vdie...@cs.ruu.nl> wrote:
-->In <4de5bl$p...@news.microsoft.com> brucemo (Bruce Moreland) writes:
-->
-->>Even with perfect move ordering you still have to search a lot of nodes.
-->
-->I'll write something about how to make the move ordering better, especially
-->on massive parallel systems where it is hard to use a huge shared hashtable,
-->or on a h8 singlechip, where it is simply too expensive to put enough
-->memory for hashtable on.
-->
-->Until then we can compare only results and thoughts. Here few of my thoughts,
-->talking to the 'supercomputer' guys that loose from very slow computers
-->like pentium:
-->
-->The current version of my programm needs 233824 nodes for 9 ply.
-->(a node is a call to the alfabeta() function; for example first ply in
-->opening takes 21 calls. 1 call on depth=1 and 20 on depth=0).
All this says is that you are heavily forward-pruning, whether you realize it
or not. Full depth-first alpha/beta to depth=9 can't possibly be done in only
200K nodes. first two plies have w=20, next two have maybe 30, last 5 are
up into the normal 38 range. How do you take (say) 32 (average w for first
nine plies) to the 4.5 power, and get 200K? 32^4 is about a million, you are
missing another .5, plus the multiplier 2. more later.
-->
-->When i compare this with programms running on a supercomputer, then
-->even these 233824 are much less. However, when getting > 10 ply
-->branching factor of my 2 year old programm, branching factor becomes about
-->3.2 to 3.4 . We must not forget however that branching factor on these
-->depths is much better, because of the small hashtables i have (about
-->few megabytes), so loading factor is much much > 1.
3.2 is impossible in middlegame. The only way to reach this is to either
not search every branch to depth=d. Knuth/Moore proved this years ago, and
it's not something that a clever algorithm can get around.
-->
-->So for 20 ply: 3.4 ^ 20 = 4.261655e+10. That is only about 10 seconds for
-->the deep blue programm.
-->
-->Of course i cannot compare it to DeepBlue, because i use recursive nullmove
-->R=2.
So do I.
-->
-->However, when i turn nullmove off even i'm sure i need also less evaluations
-->then supercomputer programms.
-->
-->Why?
-->My programm has 'extensive' pawnknowledge (currently i'm busy to write
-->knowledge for endgames) and is using attacktables for its
-->evaluations, so my programm already sees very early for example that a
-->certain position is very good. So when both programms for a certain endpoint
-->on ply p need n evaluations, then on depth p+1, my programm needs
-->to search only 1 more evaluation, before giving a cutoff. However, the programm
-->that doesn't see that you must do that certain moves, because it lacks
-->the knowledge, needs more then only 1 additional evaluation, as it
-->went searching into the wrong path. It needs to search much much more.
This is *not* alpha/beta. Alpha/Beta *never* cuts off on the way down the
tree, only on the way back. There's no way you can do what you are saying
here and still call it alpha/beta. This is effectively reducing the "d"
exponent in 2*w^d which means you are doing forward-pruning and are going to
have some severe tactical oversights.
-->
-->Have you guys ever tested programms like Genius positionally?
-->I mean: finding simple tactics is not something that gives you the strength
-->of a programm. Genius has very good pawnstructureknowledge. Did you guys ever
-->investigated the importance of a pawnstructure? Do you REALISE the importance
-->of pawnstructure?
Yes, did you? I'll bet that Crafty has a better understanding of "weak pawns"
than any commercial program available. Where do you get off asking a question
like this? Everyone's *not* a dummy.
-->
-->Did someone noticed that in the weak/backward pawn
-->evaluation of gnuchess there are huge bugs? I mean it is nice to test things
-->like nullmove, but if there is a bug in weak/backward pawn evaluation,
-->then why implementing nullmove. It takes the wrong position anyway. Even if it
-->gets another 2 ply. How well did gnuchess score in Paderborn?
-->I was told that a lot of gnuchess derivates joined, is that correct?
-->
-->Haven't seen a single msg last 2 years concerning simple tests of
-->positional knowledge.
-->
-->The most positional test i know is BK, that are only 24 positions, half
-->of them tactically, and all what is required is a '!' move.
-->
-->However evalution of a programm should be tested on simple positions
-->where it must immediately prefer a certain position.
-->
-->For example: there is a position in BK where the move that must be played
-->is f4! Now move instead of f4 the stupid move e4xf5. How many programms
-->want to take on back f5 with blacks g-pawn? I mean no matter
-->whether capturing with g6xf5 is the best move: human players FIRST look
-->at g6xf5, because that pawnstructure is preferred, and because they don't want
-->to loose so your programm should prefer the pawnstructure that arises
-->after g6xf5. Genius for example immediately prefers g6xf5.
-->
-->Programms should prefer that on ply 1.
-->
-->Now remove the bishop on d7 and d3. Does it still want to capture with the
-->g6xf5 pawn?
What's the point of this? good progams have good pawn structure evaluation,
bad programs don't. You need to play Crafty, Genius, Ferret, Wchess, and
the like, and beat 'em regularly. Then you can say they are inferior. The
proof is in the playing, not in the "crowing".
-->
-->Also quiescencesearch: how big is your overhead in q-search?
-->I guess that mine is less, and that the overhead in q-search of
-->certain commercial programms is much less, giving a lineair speed up.
I "guess" that you don't have a clue what you are talking about here. Why
bother posting "I guess" topics.
-->
-->That can give your programm another ply. A good q-search estimation
-->even more. Do you only use captures in q-search? Stupid. What if
-->there are a lot of threats in a position? When to extend? I guess that
-->there is a lot to do about q-search. I only count the number of
-->nodes processed in the alfabeta. So in fact q-search is overhead in my
-->programm. I forward prune in q-search. If i remove this forward pruning,
-->then of course the overhead of the q-search becomes bigger. On the other
-->hand: branching factor becomes less. There is a lot to get out of this
-->phenomena: getting a better q-score will save the right move in positions
-->where score < alfa. However, when you forward prune, then it might
-->be the case that other moves are saved in hashtable, because score is
-->< alfa (so >= beta 1 ply later) anyway. Even if it is possible to capture
-->a queen.
Aha, yet another oddity. Why are you the only person on the planet that
doesn't count qsearch nodes? How about doing things like everyone else,
then reporting back with better data. Don't post such idle speculation and
outright incorrect data, it only leads to confusion. Also, why assume most
of us only follow captures? I do captures, checks, passed pawn pushes, and
even tried the null-move threat extensions for a while before rejecting it
as no good. I'm *not* the only one doing non-captures.
-->
-->How do you evaluate? I use attacktables and loop over all pieces. Most
-->programms use these loops over pieces. Loops are slow, there is much
-->to optimize here also in my programm.
-->
-->Do you know that
-->
--> a = 0;
--> do {
--> ..
--> } while( ++a < n );
-->
-->is much faster then
-->
--> for( a = 0 ; a < n ; a++ ) {
--> ..
--> }
It's not. either you have a sorry compiler or you misunderstand optimization.
Those two pieces of code are identical, and a good compiler will produce exactly
the same code for both with optimizations enabled. I just tried it on my Sun
and got the same instructions.
-->
-->This can be optimized even more, although you do exactly the same.
-->
-->How fast do you generate list of moves? I'm sure that move generation
-->can be done at least 2 times faster then GNUchess does. It is for sure
-->that commercial programms also
-->do it the same way i do (and they in machine language, where i use C),
-->also i'm sure you don't need 2 arrays of 32 k for that.
-->
-->I haven't looked to bitboards as my pentium is only 32 bits (and floating
-->point which is 80 bits is simply too slow). However i looked after the
-->source of Crafty. First i must give mr. Hyatt a big compliment. Never i have
-->seen such a nice programming style, and everything commented in a
-->chessprogramm.
-->
-->Crafty can run much faster on Pentium: bitboards are consequently
-->used. However i guess that a combined approach would give Crafty more.
-->For move generation, don't use bitboards. For evaluation it might sometimes
-->give you a speedup.
-->Crafty contains complete knowledge, but not much more then all necessary
-->phenomena's. Its routine that sets all parameters is very poor.
-->
-->>>But then, have you ever seen a program with perfect move ordering?
-->
-->So this guy admits that it can be done better!
No, just that it can't be done "perfectly". If you could, why do the search at
all? Just order the moves using your "perfect" strategy and then play the first
one since it's *always* the best one. Talk about searching very few nodes. How
about *one*?
-->
-->>>I think not! So 'real world' move ordering would be quite a bit
-->>>greater than any such calculation.
-->
-->For example?
-->
-->How do you order moves when score < alfa?
-->
-->Do you simply take the move in the hashtable first, or do you use attacktables
-->in this case?
-->
-->What does score < alfa stored in hashtable say you?
I take the hash move. It was the best move the last time this node was
searched, when score was < alpha (then), so what's to indicate that it won't
be the best move again? Costs absolutely nothing, no move generation, or
anything. Also, I assume you mean score < alpha && table_depth >= depth?
If so, I don't search *any* moves. The last time I reached this position,
every move failed low and I returned alpha as the score. I'll do exactly
the same here too. I won't search anything, I won't generate anything, as
long as the depth of the table position is enough to satisfy "depth".
-->
-->Vincent.
-->vdie...@cs.ruu.nl
-->--
--> +--------------------------------------+
--> || email : vdie...@cs.ruu.nl ||
--> || Vincent Diepeveen ||
--> +======================================+
I too am impressed with Genius. However, Richard's success is *not* related
to his move ordering. He (a) evaluates quite well. Crafty will one day
evaluate "better" because it has a better data structure for evaluation, namely
bitboards; (b) is very clever in his selective part of the search, and this is
the main reason for his success. I suspect that he does *less* move ordering
than most of us, to keep program size down, fit into cache better, and search
faster overall. We'll never know since he reveals little, however making such
broad comparisons won't tell us much.
Crafty's designed around 64bit machines. If you think it plays o.k. chess on
the PC at 8K nodes per second, remember that it's also played on a Cray T90
at 5 million nodes per second. I have not played lots of games because it
has to be done manually, but Crafty did go 4-0 against Genius running on a
133mhz pentium, when crafty used the Cray. yes, I know, the speed difference
makes this meaningless, and doesn't say much about how the program does on
other machines. Therefore, it's all moot. You seem to have this opinion that
"us supercomputer guys" can't get this right. To this, I will respond with two
comments: (1) 90% of what's done in computer chess is a direct result of
"us supercomputer guys". Iterative deepening, out-of-check extensions,
killer-moves, history-moves, singular extensions, etc. We just don't have
commercial interests driving what we do. We don't spend days hacking our
opening book to beat program "x" and move up the Swedish Rating List. We
simply search for better algorithms, re-test old ideas, and invent new ones
to make things faster or better. Heck, some of "us" even publish everything
we try and make source code available so that you can see what we do, try it
yourself and make your own decision. :) I don't think you'll find a smidgeon of
difference in the coding skills of the "supercomputer guys" and the "commercial
chess programmers". Ditto for chess-playing skill, and ditto for getting
advice from GM's. (2) regardless of all this, you still overlook the simple
fact that Deep Thought II was nearly unbeatable. Hsu reported that he won
well over 90% of the games he played against Fritz in his lab. That's good
performance results. When dealing with special-purpose hardware you *do* have
to make concessions that you would not were you using a general purpose
machine. That *does not* mean the program is in some way "worse" by doing
this. We long ago figured out how to test compromises to make sure that the
extra nodes searched because something was removed is more than offset by the
speed gained. That's not difficult at all.
David Hunt
>
snip-snip
> 3.2 is impossible in middlegame. The only way to reach this is to either
> not search every branch to depth=d. Knuth/Moore proved this years ago, and
> it's not something that a clever algorithm can get around.
>
snip-snip
> What's the point of this? good progams have good pawn structure evaluation,
> bad programs don't. You need to play Crafty, Genius, Ferret, Wchess, and
> the like, and beat 'em regularly. Then you can say they are inferior. The
> proof is in the playing, not in the "crowing".
>
>
snip-snip
> I "guess" that you don't have a clue what you are talking about here. Why
> bother posting "I guess" topics.
>
snip-snip
> Aha, yet another oddity. Why are you the only person on the planet that
> doesn't count qsearch nodes? How about doing things like everyone else,
> then reporting back with better data. Don't post such idle speculation and
> outright incorrect data, it only leads to confusion. Also, why assume most
> of us only follow captures? I do captures, checks, passed pawn pushes, and
> even tried the null-move threat extensions for a while before rejecting it
> as no good. I'm *not* the only one doing non-captures.
>
snip-snip
> Robert Hyatt Computer and Information Sciences
> hy...@cis.uab.edu University of Alabama at Birmingham
> (205) 934-2213 115A Campbell Hall, UAB Station
> (205) 934-5473 FAX Birmingham, AL 35294-1170
When the classicists say 'it's impossible' and 'you know nothing'
you can be sure that the breakthrough in their branch of knowledge
is about to take place.
Only the classicists will never know it.
Good luck to all those who claim there is another way forward.
Chris Whittington
Gary M. Watson
>hy...@willis.cis.uab.edu (Robert Hyatt) wrote:
>>
>snip-snip
>
>> not search every branch to depth=d. Knuth/Moore proved this years ago, and
>> it's not something that a clever algorithm can get around.
>>
>
>> What's the point of this? good progams have good pawn structure evaluation,
>> bad programs don't. You need to play Crafty, Genius, Ferret, Wchess, and
>> the like, and beat 'em regularly. Then you can say they are inferior. The
>> proof is in the playing, not in the "crowing".
>
>> doesn't count qsearch nodes? How about doing things like everyone else,
>> then reporting back with better data. Don't post such idle speculation and
>> outright incorrect data, it only leads to confusion. Also, why assume most
>> of us only follow captures? I do captures, checks, passed pawn pushes, and
>> even tried the null-move threat extensions for a while before rejecting it
>> as no good. I'm *not* the only one doing non-captures.
>>
>you can be sure that the breakthrough in their branch of knowledge
>is about to take place.
What are you talking about? Bob was refuting specific "ideas" the
other guy had as being non-useful for very specific reasons. Are
you making the argument that debate is of no value in science?
Who is the Luddite here?
>Only the classicists will never know it.
What a load of crap. Dr. Hyatt has been on the cutting edge of
computer chess for two decades. What makes you think he doesn't
attentively follow every development _that_shows_itself_to_be_worth_it_?
>Good luck to all those who claim there is another way forward.
Yeah, provided they actually have another way forward and
not merely a claim. I claim, for example, to be the Supreme
Commander of the Earth, yet people seem to hesitate to send
me their wallets like I ask... :-)
Vincent Diepeveen
>Even with perfect move ordering you still have to search a lot of nodes.
I'll write something about how to make the move ordering better, especially
on massive parallel systems where it is hard to use a huge shared hashtable,
or on a h8 singlechip, where it is simply too expensive to put enough
memory for hashtable on.
Until then we can compare only results and thoughts. Here few of my thoughts,
talking to the 'supercomputer' guys that loose from very slow computers
like pentium:
The current version of my programm needs 233824 nodes for 9 ply.
(a node is a call to the alfabeta() function; for example first ply in
opening takes 21 calls. 1 call on depth=1 and 20 on depth=0).
When i compare this with programms running on a supercomputer, then
even these 233824 are much less. However, when getting > 10 ply
branching factor of my 2 year old programm, branching factor becomes about
3.2 to 3.4 . We must not forget however that branching factor on these
depths is much better, because of the small hashtables i have (about
few megabytes), so loading factor is much much > 1.
So for 20 ply: 3.4 ^ 20 = 4.261655e+10. That is only about 10 seconds for
the deep blue programm.
Of course i cannot compare it to DeepBlue, because i use recursive nullmove
R=2.
However, when i turn nullmove off even i'm sure i need also less evaluations
then supercomputer programms.
Why?
My programm has 'extensive' pawnknowledge (currently i'm busy to write
knowledge for endgames) and is using attacktables for its
evaluations, so my programm already sees very early for example that a
certain position is very good. So when both programms for a certain endpoint
on ply p need n evaluations, then on depth p+1, my programm needs
to search only 1 more evaluation, before giving a cutoff. However, the programm
that doesn't see that you must do that certain moves, because it lacks
the knowledge, needs more then only 1 additional evaluation, as it
went searching into the wrong path. It needs to search much much more.
Have you guys ever tested programms like Genius positionally?
I mean: finding simple tactics is not something that gives you the strength
of a programm. Genius has very good pawnstructureknowledge. Did you guys ever
investigated the importance of a pawnstructure? Do you REALISE the importance
of pawnstructure?
Did someone noticed that in the weak/backward pawn
evaluation of gnuchess there are huge bugs? I mean it is nice to test things
like nullmove, but if there is a bug in weak/backward pawn evaluation,
then why implementing nullmove. It takes the wrong position anyway. Even if it
gets another 2 ply. How well did gnuchess score in Paderborn?
I was told that a lot of gnuchess derivates joined, is that correct?
Haven't seen a single msg last 2 years concerning simple tests of
positional knowledge.
The most positional test i know is BK, that are only 24 positions, half
of them tactically, and all what is required is a '!' move.
However evalution of a programm should be tested on simple positions
where it must immediately prefer a certain position.
For example: there is a position in BK where the move that must be played
is f4! Now move instead of f4 the stupid move e4xf5. How many programms
want to take on back f5 with blacks g-pawn? I mean no matter
whether capturing with g6xf5 is the best move: human players FIRST look
at g6xf5, because that pawnstructure is preferred, and because they don't want
to loose so your programm should prefer the pawnstructure that arises
after g6xf5. Genius for example immediately prefers g6xf5.
Programms should prefer that on ply 1.
Now remove the bishop on d7 and d3. Does it still want to capture with the
g6xf5 pawn?
Also quiescencesearch: how big is your overhead in q-search?
I guess that mine is less, and that the overhead in q-search of
certain commercial programms is much less, giving a lineair speed up.
That can give your programm another ply. A good q-search estimation
even more. Do you only use captures in q-search? Stupid. What if
there are a lot of threats in a position? When to extend? I guess that
there is a lot to do about q-search. I only count the number of
nodes processed in the alfabeta. So in fact q-search is overhead in my
programm. I forward prune in q-search. If i remove this forward pruning,
then of course the overhead of the q-search becomes bigger. On the other
hand: branching factor becomes less. There is a lot to get out of this
phenomena: getting a better q-score will save the right move in positions
where score < alfa. However, when you forward prune, then it might
be the case that other moves are saved in hashtable, because score is
< alfa (so >= beta 1 ply later) anyway. Even if it is possible to capture
a queen.
How do you evaluate? I use attacktables and loop over all pieces. Most
programms use these loops over pieces. Loops are slow, there is much
to optimize here also in my programm.
Do you know that
a = 0;
do {
..
} while( ++a < n );
is much faster then
for( a = 0 ; a < n ; a++ ) {
..
}
This can be optimized even more, although you do exactly the same.
How fast do you generate list of moves? I'm sure that move generation
can be done at least 2 times faster then GNUchess does. It is for sure
that commercial programms also
do it the same way i do (and they in machine language, where i use C),
also i'm sure you don't need 2 arrays of 32 k for that.
I haven't looked to bitboards as my pentium is only 32 bits (and floating
point which is 80 bits is simply too slow). However i looked after the
source of Crafty. First i must give mr. Hyatt a big compliment. Never i have
seen such a nice programming style, and everything commented in a
chessprogramm.
Crafty can run much faster on Pentium: bitboards are consequently
used. However i guess that a combined approach would give Crafty more.
For move generation, don't use bitboards. For evaluation it might sometimes
give you a speedup.
Crafty contains complete knowledge, but not much more then all necessary
phenomena's. Its routine that sets all parameters is very poor.
>>But then, have you ever seen a program with perfect move ordering?
So this guy admits that it can be done better!
>>I think not! So 'real world' move ordering would be quite a bit
>>greater than any such calculation.
For example?
How do you order moves when score < alfa?
Do you simply take the move in the hashtable first, or do you use attacktables
in this case?
What does score < alfa stored in hashtable say you?
Vincent.
Vincent Diepeveen
>All this says is that you are heavily forward-pruning, whether you realize it
>or not. Full depth-first alpha/beta to depth=9 can't possibly be done in only
>200K nodes. first two plies have w=20, next two have maybe 30, last 5 are
>up into the normal 38 range. How do you take (say) 32 (average w for first
>nine plies) to the 4.5 power, and get 200K? 32^4 is about a million, you are
>missing another .5, plus the multiplier 2. more later.
No one on the world has proved, or will prove,
what the minimum amount of evaluations is when using
nullmove, so this is crap.
>3.2 is impossible in middlegame. The only way to reach this is to either
>not search every branch to depth=d. Knuth/Moore proved this years ago, and
>it's not something that a clever algorithm can get around.
See my previous comment.
>-->So for 20 ply: 3.4 ^ 20 = 4.261655e+10. That is only about 10 seconds for
>-->the deep blue programm.
>-->
>-->Of course i cannot compare it to DeepBlue, because i use recursive nullmove
>-->R=2.
>So do I.
How much do you get from your nullmove?
It seems that there is yet a lot to learn about nullmove.
>This is *not* alpha/beta. Alpha/Beta *never* cuts off on the way down the
>tree, only on the way back. There's no way you can do what you are saying
>here and still call it alpha/beta. This is effectively reducing the "d"
>exponent in 2*w^d which means you are doing forward-pruning and are going to
>have some severe tactical oversights.
I was not clear, that is true: i was talking about the effect of the last
additional ply on depth p compared to another ply on depth p+1. It explains a little
why knowledge could do the job.
>Yes, did you? I'll bet that Crafty has a better understanding of "weak pawns"
>than any commercial program available. Where do you get off asking a question
>like this? Everyone's *not* a dummy.
Don't make me laugh: crafty's source is ftp-able, so i know exactly that crafty
doesn't know much about it.
Do you know that parameter representation is also a form of knowledge?
There is also another point: where WE try to recognise weak pawns etc. DURING
search, most commercial programms try that BEFORE search. Which is better, i guess
during search, however the knowledge BEFORE search is there.
>What's the point of this? good progams have good pawn structure evaluation,
>bad programs don't. You need to play Crafty, Genius, Ferret, Wchess, and
>the like, and beat 'em regularly. Then you can say they are inferior. The
>proof is in the playing, not in the "crowing".
I'm quit good in reading C-code. I know what GNU-chess and Crafty are lacking:
in-depth knowledge. I'm trying to implement it in my own programm, but you must
give me somewhat credit: i didn't have 20 years the time to implement it in a programm,
i only did have 2 years.
Besides, what's wrong with comment? You put a lot of effort in your programm,
no doubt. It is clear to see when reading the code (even the c-code, not to mention
the Cray code). However, why are small computers beating you?
Can you analyze lost IMPORTANT games against commercial programms: why did you loose
them? That will make the great audience understand it; i mean i shouted here and there
that the difference between my and commercial programms is not that big, but WHY
do they finally win the important games? I know for example that during testing
results are quite different from the games played in tournament. When talking
to programmers, they claim that they win with 75% to 80% of the world top programms
on the same hardware, same amount of hashtables.
However when they play tournaments things are totally different. Why?
It is the same hardware!
>-->Also quiescencesearch: how big is your overhead in q-search?
>-->I guess that mine is less, and that the overhead in q-search of
>-->certain commercial programms is much less, giving a lineair speed up.
>I "guess" that you don't have a clue what you are talking about here. Why
>bother posting "I guess" topics.
It is just a thought. The more i compare my programm to very strong programms,
the more i get the idea that the only important thing left for my programm is getting
another few ply. Supercomputer already get these plies for many years, but didn't
profit last few years from it.
Why making a Deep Blue programm? It lost the important game even from a so called
dummy Fritz3. Of course, in testing it always win from Fritz3, that is with every
programm the case!
However when fritz3 gets few plies extra then it solves quite
difficult positional problems. Can i put few simple tactics on Deep Blue?
Cray Blitz?
I mean: lets compare the speed difference: Fritz3 about 40000 nps on a Pentium 90.
Deep Blue about 5 x 10^9 (or something). So that is about 125,000 times faster
(i'm not very good in math i'm just studying computer science, but 125,000 seems
to me a huge difference).
Fritz3/Mchess pro finds a lot of difficult positions in about few hours.
So say 10 hours = 10 x 3600 = 36000 seconds. So Deep Blue should find these problems
within a flash of a second am i true?
>-->That can give your programm another ply. A good q-search estimation
>-->even more. Do you only use captures in q-search? Stupid. What if
>-->there are a lot of threats in a position? When to extend? I guess that
>-->there is a lot to do about q-search. I only count the number of
>-->nodes processed in the alfabeta. So in fact q-search is overhead in my
>-->programm. I forward prune in q-search. If i remove this forward pruning,
>-->then of course the overhead of the q-search becomes bigger. On the other
>-->hand: branching factor becomes less. There is a lot to get out of this
>-->phenomena: getting a better q-score will save the right move in positions
>-->where score < alfa. However, when you forward prune, then it might
>-->be the case that other moves are saved in hashtable, because score is
>-->< alfa (so >= beta 1 ply later) anyway. Even if it is possible to capture
>-->a queen.
>Aha, yet another oddity. Why are you the only person on the planet that
>doesn't count qsearch nodes?
Then you can see the branching factor within the alfabeta search, remember?
If you get a better branching factor, then you can improve your programm.
All what counts for strong positional play is the depth within alfabeta, and
NOT the depth within q-search.
> How about doing things like everyone else,
>then reporting back with better data. Don't post such idle speculation and
>outright incorrect data, it only leads to confusion.
Don't YOU find it strange that a better estimation of the q-search gives you
less nodes in alfabeta? I mean: on the 1 hand you want to DECREASE the q-search
as much as possible, on the other hand you want a good estimation for a quiescent
position. That is a contradiction.
> Also, why assume most
>of us only follow captures?
I'm talking about programms in general.
In my msg i was only having few thoughts: how can medium size computers win
from supercomputers. This means that there is a lot to make better in these
chessprogramms. Of course also in my own chessprogramm.
I am however surprised that even a reasonable new programm like mine, using
the same phenomena's: hashtables, nullmove r=2, killermoves can also get
reasonable results. I'd expect that it would take me years before i can even
close to results that are comparable to supercomputer programms, or even
better. I mean, to know the REAL number of nodes my programm uses, simply
add 30% to the ab-nodes. This still is a lot better then crafty.
(we must not forget: i say crafty, but i only say crafty because Hyatt was
so friendly to PUBLISH results of his programm, where others don't).
>-->How do you evaluate? I use attacktables and loop over all pieces. Most
>-->programms use these loops over pieces. Loops are slow, there is much
>-->to optimize here also in my programm.
>-->
>-->Do you know that
>-->
>--> a = 0;
>--> do {
>--> ..
>--> } while( ++a < n );
>-->
>-->is much faster then
>-->
>--> for( a = 0 ; a < n ; a++ ) {
>--> ..
>--> }
>It's not. either you have a sorry compiler or you misunderstand optimization.
May be it is not true for the Cray, it surely is for the Pentium.
c-compiler can better optimize it.
>Those two pieces of code are identical, and a good compiler will produce exactly
>the same code for both with optimizations enabled. I just tried it on my Sun
>and got the same instructions.
There are no perfect compilers.
Add few lines of code and you know.
Don't use a sun, use a pentium.
How many chessfans use a sun?
>I too am impressed with Genius. However, Richard's success is *not* related
>to his move ordering. He (a) evaluates quite well. Crafty will one day
>evaluate "better" because it has a better data structure for evaluation, namely
>bitboards; (b) is very clever in his selective part of the search, and this is
>the main reason for his success. I suspect that he does *less* move ordering
>than most of us,
Definitely, he doesn't search that deep.
However you now admit that he EVALUATES better, why talking few lines before about
that your (weak)pawn-evaluation is better, if he evaluates better? You don't
know whether this comes from pawn evaluation.
> to keep program size down, fit into cache better, and search
>faster overall. We'll never know since he reveals little, however making such
>broad comparisons won't tell us much.
We can compare results on championships.
>Crafty's designed around 64bit machines.
That is a huge advantage over 32 bits Pentium machines.
It gives you a huge advantage over programms like Genius, let's not forget that.
> If you think it plays o.k. chess on
>the PC at 8K nodes per second, remember that it's also played on a Cray T90
>at 5 million nodes per second. I have not played lots of games because it
>has to be done manually, but Crafty did go 4-0 against Genius running on a
>133mhz pentium, when crafty used the Cray.
Here it is: in testing games ALL programmers, that have put a lot of effort in
their programm, claim to win from Genius. (even my own modest programm sometimes)
In fact, they do; why should you lie? However, why do you loose in serious events from
it? Can you give examples why?
> yes, I know, the speed difference
>makes this meaningless, and doesn't say much about how the program does on
>other machines. Therefore, it's all moot. You seem to have this opinion that
>"us supercomputer guys" can't get this right. To this, I will respond with two
>comments: (1) 90% of what's done in computer chess is a direct result of
>"us supercomputer guys".
> Iterative deepening, out-of-check extensions,
>killer-moves, history-moves, singular extensions, etc. We just don't have
That is true: i admire you for that. However i get not paid to publish these
things. I have several improvements used to order moves better, but i guess
i will only publish one general aspect of it. I get not PAID for publishing it!
>commercial interests driving what we do. We don't spend days hacking our
>opening book to beat program "x" and move up the Swedish Rating List.
> We simply search for better algorithms, re-test old ideas, and invent new ones
>to make things faster or better.
We must not forget that because of this "i don't need a strong programm" lemma
takes care that a lot of things invented in computerchess is wrongly tested.
I mean: for a programm with a branching factor of 11, every modification will make
it perform better.
> Heck, some of "us" even publish everything
>we try and make source code available so that you can see what we do, try it
>yourself and make your own decision. :) I don't think you'll find a smidgeon of
>difference in the coding skills of the "supercomputer guys" and the "commercial
>chess programmers".
What are skills in this respect?
> Ditto for chess-playing skill, and ditto for getting
>advice from GM's. (2) regardless of all this, you still overlook the simple
>fact that Deep Thought II was nearly unbeatable. Hsu reported that he won
>well over 90% of the games he played against Fritz in his lab.
> That's good
>performance results.
But testing games are not important games!
They are important to make your programm better, but that single game in
Hong Kong was the game that was important!
> When dealing with special-purpose hardware you *do* have
>to make concessions that you would not were you using a general purpose
>machine. That *does not* mean the program is in some way "worse" by doing
>this. We long ago figured out how to test compromises to make sure that the
>extra nodes searched because something was removed is more than offset by the
>speed gained. That's not difficult at all.
That is true, everything can be compared, even a programm using nullmove and
a programm not using nullmove. Simply play games!
Vincent Diepeveen
D Kirkland
:
: So this guy admits that it can be done better!
You missed my point! If a program (any program!) had perfect move
ordering, then there would be no need for a search at all! But as
everybody is doing some sort of search...
: >>I think not! So 'real world' move ordering would be quite a bit
: >>greater than any such calculation.
:
: For example?
For example?
Well, maybe I am wrong! Maybe you have 'perfect' move ordering.
And maybe you could just use that and forget the search!
dan
John Sargeant
In article <8218259...@cpsoft.demon.co.uk>, David Hunt
<da...@cpsoft.demon.co.uk> writes:
|>
|> When the classicists say 'it's impossible' and 'you know nothing'
|> you can be sure that the breakthrough in their branch of knowledge
|> is about to take place.
Either that or it's impossible and you know nothing. I suggest you
attempt to understand Bob Hyatt's explanations - especially where he uses
the word "proved" - rather than just throwing vague insults around.
|>
|> Only the classicists will never know it.
|>
|> Good luck to all those who claim there is another way forward.
|>
Indeed. And may such claims be investigated in an open-minded manner.
But just claiming something doesn't make it true.
|> Chris Whittington
|>
John
Kerrigan42
I've spent months writing my own program and I don't need you assuming
everything I've done is wrong. I think I speak for every chess programmer
here when I say *shut the fuck up!*
-Tom
Vincent Diepeveen
>I'm surprised I don't speak for you, Joe. Vincent implies that without his
>"extensive pawnknowledge" our
>search trees can't possibly be as small as his. In fact, Stobor finishes 9
>ply at the initial position in around
>90,000 non-quiescent nodes (40% Vincent's figure). Then he assumes we have
>no clue about evaluation
Some knowledge that i implement in my programm doesn't make any difference
for branching factor.
Other knowledge gives it a much better branching factor,
where other knowledge let it think forever.
>functions ("Do you REALISE the importance of pawnstructure?"). In fact,
>Stobor solves his idiot Bratko-
I mean, i discovered that when running a lot of tests on genius i noticed
that it was having more knowledge about pawnstructure then
Chessmaster 4000 (=the king 1.0),Kallisto,Mchesspro,Hiarcs,Nightmare,Arthur,
FritzX(all versions),ZarkovX(all versions),Socrates 3.0,
did i forget any programm?
Haven't you ever asked why this programm was at the top of the rating list
for many years?
I mean: it doesn't search deep, even missing combinations at depths
every 'fullwidth with nullmove' programm finds it. There must be
a reason why! May be that pawnstructure gives it some credits.
No i didn't run only 1 test. I ran a lot.
It doesn't say of course that it DOES have the knowledge of that
pawnstructure: probably parameters are more important in Genius if
i may guess, but the fact is that it does play the right move. That gives it
credits.
I assume that extensive pawnknowledge can do the same. Also when i play
chess, or analyze with a GM, these guys think pawnstructure to be
very important.
Haven't seen a single msg so far about that except these 2, and about
20 or something hatemails. On the other hand i have seen thousands
of tests(and results) concerning for example the 300 win at chess
positions.
>Kopec test at ply 1 without any special tuning. Then he "guesses" his
>quiescence searches are smaller than
>ours. I "guess" he's wrong, and I'm prepared to put money on that guess.
>Then he has the nerve to tell us
>how to write our loops.
Not at all. Just remove all your loops!
I first speeded up my programm only by switching from Borland-C to Watcom-C
Then i removed a lot of stupid things like:
for( i = 0 ; i < 64 ; i++ )
if( board[i] == king )
...
Faster is:
do {
if( *ip == king )
...
while( ++ip < n );
I mean: the code is doing exactly the same. Only rewriting it is
in fact wasting time, but it is NECESSARY!
I get bored of that speeding up things, but it pays!
Compilers simply suck (of course my code also, i know).
>Yes, Diep placed 8th at the Dutch Open. Notice that Nightmare is 9th, with
>the same number of points. I
>can't say I'm amazed.
Well, not bad after 2 years i guess.
Year before i only scored 3 out of 11, last champ i scored 6 out of
eleven. That is 100% better!
>Perhaps Vincent doesn't intend any insult.
Not at all.
I don't have comment on your programm, we ALL know that only getting
a programm follow the rules of chess is a great problem.
Could you tell more about your programm?
For example: my first move generator only generated 500 positions a second
on a 386, now on a p100 i generate about 100 times more per second,
if you allow me to gamble (1 million moves a second).
> Maybe this post is the reult of
>a language barrier.
Partly. Because of English i spended 1 year extra in grammar school.
Problem is i should have written everywhere the word 'i think
may be that possibly it could be the case that if under certain circumstances
if i run a stupid programm called Diep and compare it to other gambled
results (i must gamble them as no one publishes ANYthing), where i even
manage to loose from in Blitz by giving away pieces that every year i
work on it( haven't worked months on my programm, but 2 years)
surprisingly results happen in some random tests not randomly taken not
from your game position but taken deep in the night (after figuring out
that Diep has problems with it) while not remembering all positions
i have concluded very suddenly, of course deep in the night, next.
Most important thing is: what do you think?
Have you run tests with it?
What are your conclusions.
Only Hyatt wants to post them. I admire him for posting everything.
>If this is the
>case, Vincent, I don't reccomend visiting the United States because you'll
>get beat up pretty bad.
Did i ANYWHERE tell you that my programm could beat you?
You did the same thing i did: you read something and assumed another
1000 things. I guess that only saying things in this area is stupid.
Bye the way could you publish more about your programm?
Didn't even hear from it until now.
Another thing that most guys forget is that most guys trying to make
a programm even don't wanna put msg's here because of these 'get the
hell out' msg's. They simply fear it. When they DO have a strong programm
they don't NEED it anymore to discuss their programm.
Is that a subgoal you are after?
In fact they laugh about these msg's we are writing.
Vincent Diepeveen
vdie...@cs.ruu.nl
>-Tom
P.S.
I intend to crush your programm, if you pay me a ticket
to the USA (i'm living in Holland) and ship me a fast computer.
Diep will play ICS, but problem is: this hardware sucks, and about 1 minute
out of 2 is lag, also openingsbook sucks: i must make a handmade book:
the book that currently is running with Diep is about 8 mb.
My quota is 7.5 mb over here.
Do you have the same problems?
Still i'm gonna play ICS with Diep.
What's your programm's name on ICS. Let's play a 90 mins/60 moves match!
Robert Hyatt
Vincent Diepeveen <vdie...@cs.ruu.nl> wrote:
-->In <4dnron$b...@newsbf02.news.aol.com> kerri...@aol.com (Kerrigan42) writes:
-->
-->>I'm surprised I don't speak for you, Joe. Vincent implies that without his
-->>"extensive pawnknowledge" our
-->>search trees can't possibly be as small as his. In fact, Stobor finishes 9
-->>ply at the initial position in around
-->>90,000 non-quiescent nodes (40% Vincent's figure). Then he assumes we have
-->>no clue about evaluation
-->
-->Some knowledge that i implement in my programm doesn't make any difference
-->for branching factor.
-->
-->Other knowledge gives it a much better branching factor,
-->where other knowledge let it think forever.
Don't see where knowledge has anything to do with the branching factor
whatsoever. The branching factor for full-width search programs is fixed
by what's happening at the root position, since evaluation does *not*
alter the number of legal moves at each position. Maybe you are using
the wrong term. Maybe "effective branching factor" is what you mean?
-->
-->>functions ("Do you REALISE the importance of pawnstructure?"). In fact,
-->>Stobor solves his idiot Bratko-
-->
-->I mean, i discovered that when running a lot of tests on genius i noticed
-->that it was having more knowledge about pawnstructure then
-->
-->Chessmaster 4000 (=the king 1.0),Kallisto,Mchesspro,Hiarcs,Nightmare,Arthur,
-->FritzX(all versions),ZarkovX(all versions),Socrates 3.0,
-->did i forget any programm?
I doubt that mephisto has more pawn structure knowledge than MchessPro. Of
course, we'll never know, but this is painting with an awfully large brush,
when you make statements about programs that we can't possibly verify...
-->
-->Haven't you ever asked why this programm was at the top of the rating list
-->for many years?
-->
-->I mean: it doesn't search deep, even missing combinations at depths
-->every 'fullwidth with nullmove' programm finds it. There must be
-->a reason why! May be that pawnstructure gives it some credits.
Don't know what you mean about not searching deep. The versions I have are
most impressive in the depths they reach and the lengths of the PV's they
produce.
-->
-->No i didn't run only 1 test. I ran a lot.
-->It doesn't say of course that it DOES have the knowledge of that
-->pawnstructure: probably parameters are more important in Genius if
-->i may guess, but the fact is that it does play the right move. That gives it
-->credits.
-->
-->I assume that extensive pawnknowledge can do the same. Also when i play
-->chess, or analyze with a GM, these guys think pawnstructure to be
-->very important.
Here's a classic test case to feed any of these programs, and I'll bet that
every one of them (excepting Crafty) will reach the wrong conclusion:
WP: b5,d5
BP b7,c7
rooks still on the board. I haven't seent a program yet that understands
that the c7 pawn is backward or isolated, you pick the term. Why? it's
not defended by a pawn. If you push it one square, it disappears.
It's on an open file with rooks still on so it's even weaker. I spent a
lot of time talking to GM/IM/Master players about such positions and came
up with many such positions.
WP: b5,d5
BP b7,c7,d7
c7 is *still* isolated, because when you push it, after c6 bc bc dc dc you
still end up with an isolated pawn with rooks on making the pawn easy to attack
with none of my pawns blocking my rooks from the front.
WP: b5
BP b7,c7
Same theme again. isolated, although most programs say hey, a healthy pawn
duo on the 2nd rank. A GM says hey, a weak pawn at c7, let's jump on it
before he can support the push/trade with pieces.
-->
-->Haven't seen a single msg so far about that except these 2, and about
-->20 or something hatemails. On the other hand i have seen thousands
-->of tests(and results) concerning for example the 300 win at chess
-->positions.
-->
-->>Kopec test at ply 1 without any special tuning. Then he "guesses" his
-->>quiescence searches are smaller than
-->>ours. I "guess" he's wrong, and I'm prepared to put money on that guess.
-->>Then he has the nerve to tell us
-->>how to write our loops.
-->
-->Not at all. Just remove all your loops!
-->I first speeded up my programm only by switching from Borland-C to Watcom-C
-->Then i removed a lot of stupid things like:
-->
-->for( i = 0 ; i < 64 ; i++ )
--> if( board[i] == king )
--> ...
-->
-->Faster is:
-->
--> do {
--> if( *ip == king )
--> ...
--> while( ++ip < n );
This is *not* faster for good compilers. What are you saving? In C
array[i] is exactly like saying *(array+i). Now if your compiler doesn't
understand the strength reduction optimization, it might (on a PC) have to
do a shift to scale the pointer correctly if you use [i], but I ran this
on my sun both ways with no difference at all in execution time. Ditto
on my PC running Linux using GCC.
-->
-->I mean: the code is doing exactly the same. Only rewriting it is
-->in fact wasting time, but it is NECESSARY!
-->
-->I get bored of that speeding up things, but it pays!
-->Compilers simply suck (of course my code also, i know).
Not *all* compilers suck, just the (apparently) ones you are using...
-->
-->>Yes, Diep placed 8th at the Dutch Open. Notice that Nightmare is 9th, with
-->>the same number of points. I
-->>can't say I'm amazed.
-->
-->Well, not bad after 2 years i guess.
-->Year before i only scored 3 out of 11, last champ i scored 6 out of
-->eleven. That is 100% better!
-->
-->>Perhaps Vincent doesn't intend any insult.
-->
-->Not at all.
-->
-->I don't have comment on your programm, we ALL know that only getting
-->a programm follow the rules of chess is a great problem.
I agree, and I avoid any negative comments about any program I see since
even the worst represent lots of blood, sweat and tears.
-->
-->Could you tell more about your programm?
-->
-->For example: my first move generator only generated 500 positions a second
-->on a 386, now on a p100 i generate about 100 times more per second,
-->if you allow me to gamble (1 million moves a second).
Not sure what you mean about gambling, but on a P75 notebook, crafty can
generate about 600K moves per second. It can generate/make about 120K
moves per sec on this machine.
-->
-->> Maybe this post is the reult of
-->>a language barrier.
-->
-->Partly. Because of English i spended 1 year extra in grammar school.
-->
-->Problem is i should have written everywhere the word 'i think
-->may be that possibly it could be the case that if under certain circumstances
-->if i run a stupid programm called Diep and compare it to other gambled
-->results (i must gamble them as no one publishes ANYthing), where i even
-->manage to loose from in Blitz by giving away pieces that every year i
-->work on it( haven't worked months on my programm, but 2 years)
-->surprisingly results happen in some random tests not randomly taken not
-->from your game position but taken deep in the night (after figuring out
-->that Diep has problems with it) while not remembering all positions
-->i have concluded very suddenly, of course deep in the night, next.
-->
-->Most important thing is: what do you think?
-->Have you run tests with it?
-->What are your conclusions.
-->Only Hyatt wants to post them. I admire him for posting everything.
-->
-->>If this is the
-->>case, Vincent, I don't reccomend visiting the United States because you'll
-->>get beat up pretty bad.
-->
-->Did i ANYWHERE tell you that my programm could beat you?
-->
-->You did the same thing i did: you read something and assumed another
-->1000 things. I guess that only saying things in this area is stupid.
-->
-->Bye the way could you publish more about your programm?
-->Didn't even hear from it until now.
-->
-->Another thing that most guys forget is that most guys trying to make
-->a programm even don't wanna put msg's here because of these 'get the
-->hell out' msg's. They simply fear it. When they DO have a strong programm
-->they don't NEED it anymore to discuss their programm.
-->
-->Is that a subgoal you are after?
-->
-->In fact they laugh about these msg's we are writing.
-->
-->Vincent Diepeveen
-->vdie...@cs.ruu.nl
-->>-Tom
-->
-->P.S.
-->I intend to crush your programm, if you pay me a ticket
-->to the USA (i'm living in Holland) and ship me a fast computer.
-->
-->Diep will play ICS, but problem is: this hardware sucks, and about 1 minute
-->out of 2 is lag, also openingsbook sucks: i must make a handmade book:
-->the book that currently is running with Diep is about 8 mb.
-->My quota is 7.5 mb over here.
-->
-->Do you have the same problems?
-->
-->Still i'm gonna play ICS with Diep.
-->What's your programm's name on ICS. Let's play a 90 mins/60 moves match!
-->
-->
I know you are talking to Tom here, but I welcome programs playing Crafty
as I get much out of looking at the games. Feel free. Once you get connected
up, I'll tell you how to match crafty at any time control you want.
--
D Kirkland
[Everything deleted..., as it should be!]
And some of you guys thought *I* was clueless!
dan
Kerrigan42
Yes, Diep placed 8th at the Dutch Open. Notice that Nightmare is 9th, with
the same number of points. I
can't say I'm amazed.
Perhaps Vincent doesn't intend any insult. Maybe this post is the reult of
a language barrier. If this is the
case, Vincent, I don't reccomend visiting the United States because you'll
get beat up pretty bad.
-Tom
Bruce Moreland
be settled at the chessboard.
bruce
In article <4dl4kq$6...@newsbf02.news.aol.com>, kerri...@aol.com says...
--
Bruce Moreland
I think it's great that all of these programs exist. I'm glad people are
getting ideas and trying them out in open competition. I don't know of any
of these programs that is not improving. Everyone who has a program should
be invited to compete with it, and should not be crapped on because they
scored Nth at a tournament, where N is not equal to one.
Competition is great, and so is the competitive spirit. But loss of a few
games doesn't make the programmer of the losing program stupid, less worth
listening to, or less worth getting to know.
bruce
In article <4dnron$b...@newsbf02.news.aol.com>, kerri...@aol.com says...
>[snip]
>
>Yes, Diep placed 8th at the Dutch Open. Notice that Nightmare is 9th, with
>the same number of points. I
>can't say I'm amazed.
>
>[snip]
Kerrigan42
listen to Vincent because of his place
at the Dutch Open. This makes no sense to me. If he placed 1st, then I
would consider listening to what he
has to say about loops, but he sure didn't.
If I insulted Nightmare, it wasn't intended. Gellner is a terrific guy and
Nightmare plays legal chess. At
least Gellner isn't posting about how we should write our loops or why
multiprocessor programs suck.
(Take a hint, Vincent!)
Cheers,
Tom
Joe Stella
kerri...@aol.com (Kerrigan42) writes:
>I agree with you, Bruce, but one of Joe's earlier posts said we should
>listen to Vincent because of his place
>at the Dutch Open. This makes no sense to me. If he placed 1st, then I
>would consider listening to what he
>has to say about loops, but he sure didn't.
I don't want to get into a long discussion about this, so I will just
try one more time to clarify what I was saying. My point is that
Vincent was not just shooting his mouth off; he has a program that
plays fairly strong chess considering that he has been working on
it for 2 years in his spare time, not 2 decades full time like
some other people have.
His English is also not so good, as he has said himself, so sometimes
you have to give him the benefit of the doubt when he says things that
don't seem right. As I have said in a previous post, I have corresponded
with him for a long time and I don't really think he means to say that
everyone is wrong except him.
OK, I hope that clears things up. Like I said, I don't want to get into
a long discussion about this.
Joe S.
ke...@t1sys.cfer.com
>-->for( i = 0 ; i < 64 ; i++ )
>--> if( board[i] == king )
>--> ...
>-->
>-->Faster is:
>-->
>--> do {
>--> if( *ip == king )
>--> ...
>--> while( ++ip < n );
>
>This is *not* faster for good compilers. What are you saving? In C
>array[i] is exactly like saying *(array+i). Now if your compiler doesn't
>understand the strength reduction optimization, it might (on a PC) have to
>do a shift to scale the pointer correctly if you use [i], but I ran this
>on my sun both ways with no difference at all in execution time. Ditto
>on my PC running Linux using GCC.
Enough discussion has gone on about fc for loops that I thought I'd add my
2 cents worth:
Even in theory, there are many instances where a for loop cannot be optimized
as well as a do while, (although not necessarily the ones given here). The
reason for this is frequently related to the final argument of the for. A smart
human can increment the loop variable at the most efficient time, code
motion optimizations which would allow the the compiler to do the same
thing are NEVER as smart as we can be as humans, this can often lead to
wasted cycles because of register loading and unloading. I would add that the
cases that cause it to be less efficient are relatively rare and SHOULD
only happen when things happen like an address of the loop variable being
taken, or certain break/goto conditions. Of course, the for loop is very
powerful and can be abused (used where a while or do while would make more
sense) and in these cases inneficiency can be the result. Some purists
have argued that for is not needed, and it is true that there are no cases
where a for is faster than a while or do while.
Looking at the Crafty code has led me to this observation about its
level of optimization: It has been written with speed clearly in mind,
and the types of minor tweaking that might be done would impact readability
and maintainability. They are the kinds of optimizations that I discourage
in ALMOST every project I ever work on. For example: I noticed several
cases where the evil goto command could have improved performance.
Mr Hyatt seems to have followed good coding practice rather than worked
purely for speed. (If I'm mistaken and you are interested in these kinds
of "evil" speed improvements (maybe just in some key routines) let me know
and I'll find some examples for you.
Kevin Barnes
kba...@t1sys.cfer.com
Robert Hyatt
-->In <4dosjv$8...@pelham.cis.uab.edu>, hy...@willis.cis.uab.edu (Robert Hyatt) writes:
-->>-->for( i = 0 ; i < 64 ; i++ )
-->>--> ...
-->>-->
-->>-->Faster is:
-->>-->
-->>--> if( *ip == king )
-->>--> ...
-->>--> while( ++ip < n );
-->>
-->>This is *not* faster for good compilers. What are you saving? In C
-->>array[i] is exactly like saying *(array+i). Now if your compiler doesn't
-->>understand the strength reduction optimization, it might (on a PC) have to
-->>do a shift to scale the pointer correctly if you use [i], but I ran this
-->>on my sun both ways with no difference at all in execution time. Ditto
-->>on my PC running Linux using GCC.
-->
-->Enough discussion has gone on about fc for loops that I thought I'd add my
-->2 cents worth:
-->
-->Even in theory, there are many instances where a for loop cannot be optimized
-->as well as a do while, (although not necessarily the ones given here). The
-->reason for this is frequently related to the final argument of the for. A smart
-->human can increment the loop variable at the most efficient time, code
-->motion optimizations which would allow the the compiler to do the same
-->thing are NEVER as smart as we can be as humans, this can often lead to
-->wasted cycles because of register loading and unloading. I would add that the
-->cases that cause it to be less efficient are relatively rare and SHOULD
-->only happen when things happen like an address of the loop variable being
-->taken, or certain break/goto conditions. Of course, the for loop is very
-->powerful and can be abused (used where a while or do while would make more
-->sense) and in these cases inneficiency can be the result. Some purists
-->have argued that for is not needed, and it is true that there are no cases
-->where a for is faster than a while or do while.
-->
-->Looking at the Crafty code has led me to this observation about its
-->level of optimization: It has been written with speed clearly in mind,
-->and the types of minor tweaking that might be done would impact readability
-->and maintainability. They are the kinds of optimizations that I discourage
-->in ALMOST every project I ever work on. For example: I noticed several
-->cases where the evil goto command could have improved performance.
-->
-->Mr Hyatt seems to have followed good coding practice rather than worked
-->purely for speed. (If I'm mistaken and you are interested in these kinds
-->of "evil" speed improvements (maybe just in some key routines) let me know
-->and I'll find some examples for you.
-->
-->Kevin Barnes
-->kba...@t1sys.cfer.com
-->
I'm doing a little "evil" optimization now, but never at the expense of
readability *or* (even more importantly) modifiability. Ideas are welcome.
In fact, crafty does have exactly one goto in it now. :) Speed is important,
but I'd also like to be able to look at some of this code in 6 months and
understand what the hell it's doing. I have some Cray Blitz code, both
Fortran *and* assembly, that defy modification without a lot of time
figuring out what it does, and how it does that. I *hope* Crafty is not
nearly so obtuse, but I also pay attention to speed, particularly at the
current stage where I'm going over the search engine line by line right
now cleaning it up.
Make any suggestions you want. I spent several years working on compilers
and optimizers, and always found that I could hand-code something that was
faster. however, except for playing with pointers, where they auto-
increment by 4's (or 8's) rather than a for loop going by 1's and then
having to be scaled to multiples of 4, compilers don't do terrible if
you give them something reasonable to work with.
BTW, the for/while loop above generates exactly the same code on a Cray since
all memory references are for words, *not* bytes.
Robert Hyatt
-->In <4dpjqc$t...@news.microsoft.com>, brucemo (Bruce Moreland) writes:
-->>Competition is great, and so is the competitive spirit. But loss of a few
-->>games doesn't make the programmer of the losing program stupid, less worth
-->>listening to, or less worth getting to know.
-->
-->Yes!
You can probably better judge the character of a chess programmer by how
graciously he loses, rather than by how often his program wins. If I won
every game, I wouldn't be doing this now. There would be no challenge.
ke...@t1sys.cfer.com
>Competition is great, and so is the competitive spirit. But loss of a few
Yes!
Kevin Barnes
kba...@t1sys.cfer.com
Don Fong
>for( i = 0 ; i < 64 ; i++ )
>
>Faster is:
>
> do {
> if( *ip == king )
> while( ++ip < n );
my 2c: on some architectures (also compiler dependent) the following
construct is slightly better:
for (i = 64; --i >= 0;) {
/* loop body */
}
also, on x86 machines i think you might be able to use a rep string
instruction, depending on what the loop is trying to do.
obchess: someone try this in a real chess program and tell us if
it makes any observable difference.
--
--- don fong ``i still want the peace dividend''
--
Knut-Haavard Aksnes
Robert> Make any suggestions you want. I spent several years
Robert> working on compilers and optimizers, and always found that
Robert> I could hand-code something that was faster. however,
Robert> except for playing with pointers, where they auto-
Robert> increment by 4's (or 8's) rather than a for loop going by
Robert> 1's and then having to be scaled to multiples of 4,
Robert> compilers don't do terrible if you give them something
Robert> reasonable to work with.
Using gcc this pointer kind of pointer optimalizations should be done
by -fstrength-reduce.
--
-------------------------------------------------------------------------------
Name: Knut-Håvard Aksnes (ECMA 94) or Knut-Haavard Aksnes (ASCII)
Ericsson signature: HI/ETO/X/I KNA Phone: +47 37 05 14 81
Email: eto...@etn.ericsson.se (internet) ETO.ETOKNA (memo)
Don Fong
Robert Hyatt <hy...@willis.cis.uab.edu> wrote:
>I'm doing a little "evil" optimization now, but never at the expense of
>readability *or* (even more importantly) modifiability. Ideas are welcome.
for (i = 64; --i >= 0;) [A]
is sometimes a little faster than
for (i = 0; i < 64; i++) [B]
without being too evil. also, depending on what exactly is in the
loop body, this is an "optimization" that the compiler might never
be able to figure out, because it would have to know that the
result doesn't depend on the order of processing the cases.
(of course sometimes it DOES - but i assume that in most cases
under consideration here, it doesn't matter whether you go from top
to bottom or bottom to top.)
and if you come up with a really evil but efficient construct, you can
always hide it with a macro, eg
# define BOARDLOOP(i) for (i = 0; !(i&64); i++) /* (:-) */
this might not be a bad idea anyway (i mean the idea of a macro,
not the specific definition above (:-)), if you haven't done it already.
to let you globally change a commonly used looping construct.
Q: does anyone know of an architecture/compiler where [A] would be
LESS efficient than [B]?
David Franklin
: In article <4e66gk$e...@pelham.cis.uab.edu>,
: Robert Hyatt <hy...@willis.cis.uab.edu> wrote:
: >I'm doing a little "evil" optimization now, but never at the expense of
: >readability *or* (even more importantly) modifiability. Ideas are welcome.
:
: for (i = 64; --i >= 0;) [A]
:
: is sometimes a little faster than
: for (i = 0; i < 64; i++) [B]
:
: without being too evil.
:
: Q: does anyone know of an architecture/compiler where [A] would be
: LESS efficient than [B]?
Without being the memory access guru, [B] will probably be slower than [A]
on quite a few architectures if the result is that memory accesses procede
backwards in memory (e.g. if you're doing a[i]), because it will muck up
their speculative prefetching mechanism.
Dave
David Franklin
: I'm doing a little "evil" optimization now, but never at the expense of
: readability *or* (even more importantly) modifiability. Ideas are welcome.
: In fact, crafty does have exactly one goto in it now. :) Speed is important,
: but I'd also like to be able to look at some of this code in 6 months and
: understand what the hell it's doing.
Dunno' if it's at all relevant given how much you use 64 bits as a base size,
but if you're working with 'chars' (or less so, shorts, etc.), you can see
if it's possible to process a word at a time. (e.g. searching
char *a[] for a non-zero element; search ((int *)a)[] for a non-zero element,
then you have to search a char at a time from there). Don't know much about
chess programming - I've got big wins in my own area of work like this.
Dave