Ferret info
Dann Corbit
This is a multi-part message in MIME format.
------=_NextPart_000_0001_01BCCAAB.D7D04420
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Where can I find information about ferret? I did a web search and all I
found were some games from 1995.
--
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software? Algorithms? Pubs? http://www.infoseek.com
------=_NextPart_000_0001_01BCCAAB.D7D04420
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1008.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><FONT color=3D#000000 face=3DArial size=3D2> Where can I find =
information=20
about ferret? I did a web search and all I found were some games =
from=20
1995.</FONT><FONT color=3D#000000 face=3DArial size=3D2><BR>-- <BR>C-FAQ =
ftp sites: <A=20
href=3D"ftp://ftp.eskimo.com">ftp://ftp.eskimo.com</A>=20
ftp://rtfm.mit.edu<BR>Hypertext C-FAQ:=20
http://www.eskimo.com/~scs/C-faq/top.html<BR>C-FAQ Book: ISBN=20
0-201-84519-9.<BR>Want Software? Algorithms? Pubs? <A=20
href=3D"http://www.infoseek.com">http://www.infoseek.com=20
</A></FONT></P></BODY></HTML>
------=_NextPart_000_0001_01BCCAAB.D7D04420--
brucemo
Robert Hyatt wrote:
> Dann Corbit (dco...@solutionsiq.com) wrote:
> : Where can I find information about ferret? I did a web search and all I
> : found were some games from 1995.
> not a lot of info. Written by Bruce Moreland, (mouse on ICC and most
> chess servers). finger ferret on ICC for some info, ask bruce for
> more...
That would be me. Please send email or ask here, if you think others might
be interested in the topic.
bruce
Robert Hyatt
Dann Corbit (dco...@solutionsiq.com) wrote:
: Where can I find information about ferret? I did a web search and all I
: found were some games from 1995.
: --
MLC
Post it here, if you don't mind, I am interested in hearing about Ferret.
brucemo <bru...@seanet.com> wrote in article <342CA4...@seanet.com>...
> Robert Hyatt wrote:
>
> > Dann Corbit (dco...@solutionsiq.com) wrote:
>
> > : Where can I find information about ferret? I did a web search and
all I
> > : found were some games from 1995.
>
> > not a lot of info. Written by Bruce Moreland, (mouse on ICC and most
> > chess servers). finger ferret on ICC for some info, ask bruce for
> > more...
>
Dann Corbit
brucemo wrote in article <342CA4...@seanet.com>...
>Robert Hyatt wrote:
>
>> Dann Corbit (dco...@solutionsiq.com) wrote:
>
>> : Where can I find information about ferret? I did a web search and all
I
>> : found were some games from 1995.
>
>> not a lot of info. Written by Bruce Moreland, (mouse on ICC and most
>> chess servers). finger ferret on ICC for some info, ask bruce for
>> more...
>
>That would be me. Please send email or ask here, if you think others might
>be interested in the topic.
Of course, I would be very interested. I have read a few things {newsgroup
postings here and chess newsletters on the WWW} that suggest that ferret is
an extremely strong program.
1. Is it commercial?
2. Are binaries available?
3. Do you discuss the algorithms you use?
4. Etc.
brucemo
Dann Corbit wrote:
> Of course, I would be very interested. I have read a few things {newsgroup
> postings here and chess newsletters on the WWW} that suggest that ferret is
> an extremely strong program.
> 1. Is it commercial?
> 2. Are binaries available?
> 3. Do you discuss the algorithms you use?
> 4. Etc.
Ferret is an extremely strong program, but aren't they all these days.
1) It is not commercial. It will be commercial eventually.
2) Binaries are not available. It plays on ICC, occasionally on fics and
chess.net.
3) Yes:
Ferret is a conventional null-move program (R=2, described by Donninger).
Other than null move, I do little pruning and extension tricks that cost a
little here, and save a little there (ideas from Hyatt, a single-response
extension that I deduced from an ad for a commerical program, and a few ideas
that may even be original, if this is still possible). I use a recapture
extension stolen from Hans Berliner via Bob Hyatt.
It's 32-bit, written in C, compiled with MSVC 5.0, and running on anything
that runs Windows '95 or Windows NT.
Quiescent search is constrained by a static exchange evaluator. This is
stolen from Cray Blitz or Belle, can't remember which.
The evaluation is done at the tips, and it has as much stuff in it as I can
include without slowing it down much. It doesn't compute mobility, but it
does try to understand when a piece is good or bad. It uses asymmetrical king
safety routines. Stuff is stolen from Chess 4.5 and GnuChess and everyone
else.
Move generation is done via a move table, a refinement of the technique used
in GnuChess.
It has all of the standard stuff including a hash table (two tables, one is
replace always, and one is replace if deeper or left over from a previous
search, this is stolen from Ken Thompson), a pawn hash table, a king safety
hash table (these last two are stolen from Cray Blitz description), killer
moves (don't know who invented this), history heuristic (Schaeffer), etc.
It has endgame tables that I built myself from a description by David Levy.
I've certainly left some people out. I've gotten ideas from Deep Thought but
offhand I can't remember which ones. I have also gotten a lot of help from
various amateur programmers, and the odd hint from a professional.
Node rate on a P6/200 is between 75K and 225K, >350K in weird cases.
Node rate on a 533mhz Alpha is maybe 150K to 400K, >600K in weird cases.
bruce
Robert Hyatt
brucemo (bru...@seanet.com) wrote:
: Dann Corbit wrote:
: > Of course, I would be very interested. I have read a few things {newsgroup
: > postings here and chess newsletters on the WWW} that suggest that ferret is
: > an extremely strong program.
: > 1. Is it commercial?
: > 2. Are binaries available?
: > 3. Do you discuss the algorithms you use?
: > 4. Etc.
: Ferret is an extremely strong program, but aren't they all these days.
: 1) It is not commercial. It will be commercial eventually.
: 2) Binaries are not available. It plays on ICC, occasionally on fics and
: chess.net.
: 3) Yes:
: Ferret is a conventional null-move program (R=2, described by Donninger).
: Other than null move, I do little pruning and extension tricks that cost a
: little here, and save a little there (ideas from Hyatt, a single-response
: extension that I deduced from an ad for a commerical program, and a few ideas
: that may even be original, if this is still possible). I use a recapture
: extension stolen from Hans Berliner via Bob Hyatt.
: It's 32-bit, written in C, compiled with MSVC 5.0, and running on anything
: that runs Windows '95 or Windows NT.
: Quiescent search is constrained by a static exchange evaluator. This is
: stolen from Cray Blitz or Belle, can't remember which.
Cray Blitz. Belle used the MVV/LVA hardware trick, but didn't throw any
captures at all out...
: The evaluation is done at the tips, and it has as much stuff in it as I can
: include without slowing it down much. It doesn't compute mobility, but it
: does try to understand when a piece is good or bad. It uses asymmetrical king
: safety routines. Stuff is stolen from Chess 4.5 and GnuChess and everyone
: else.
: Move generation is done via a move table, a refinement of the technique used
: in GnuChess.
: It has all of the standard stuff including a hash table (two tables, one is
: replace always, and one is replace if deeper or left over from a previous
: search, this is stolen from Ken Thompson), a pawn hash table, a king safety
: hash table (these last two are stolen from Cray Blitz description), killer
: moves (don't know who invented this), history heuristic (Schaeffer), etc.
Me either for the killer idea. I got it from chess 4.x in the book
Chess Skill in Man and Machine most of us read many times. :)
: It has endgame tables that I built myself from a description by David Levy.
brucemo
Carl Tillotson wrote:
> There appears to be a lot of so called "stolen" code there :-)
>
> Surely you didn't steal it, just re-engineered for a better use :-)
Certainly. I read the literature and I use what I find out.
Everyone who describes their program would mention the same stuff, I
just mentioned where I learned it from :-)
bruce
Rolf Tueschen
brucemo <bru...@seanet.com> wrote:
>Ferret is an extremely strong program, but aren't they all these days.
>1) It is not commercial. It will be commercial eventually.
>2) Binaries are not available. It plays on ICC, occasionally on fics and
>chess.net.
>3) Yes:
Bruce, excuse me. It's sunday morning and all the bells ring for a new
Pope's day.
As you know me so often swollen these days....
But now I read that you had stolen most of the feautures of FERRET.
Your description sounds for me swollen ears like a spare-part surgery
seminary. And not enough, you forgot mostly the origin of your robbery.
You dont know about correct accountancy? :)
At least I do understand now why you act clumsyly in front of all the
benefactors... (the proxy story finally is also solved for me.)
Your Pope in Office, Rolf97
>Ferret is a conventional program, ideas stolen from Hyatt,
>and a few ideas that may even be original, if this is still possible.
>I use a recapture extension stolen from Hans Berliner via Bob Hyatt.
>Quiescent search is constrained by a static exchange evaluator. This is
>stolen from Cray Blitz or Belle, can't remember which. It doesn't compute
>mobility, but it does try to understand when a piece is good or bad.
>It uses asymmetrical king safety routines.
>Stuff is stolen from Chess 4.5 and GnuChess and everyone
>else. Move generation is done via a move table, a refinement
>of the technique used in GnuChess.
>It has all of the standard stuff including a hash table (two tables, one is
>replace always, and one is replace if deeper or left over from a previous
>search, this is stolen from Ken Thompson), a pawn hash table, a king safety
>hash table (these last two are stolen from Cray Blitz description), killer
>moves (don't know who invented this), history heuristic (Schaeffer), etc.
>It has endgame tables that I built myself from a description by David Levy.
>I've certainly left some people out.
>I've gotten ideas from Deep Thought but offhand I can't remember
>which ones. I have also gotten a lot of help from
>various amateur programmers, and the odd hint from a professional.
[By our FBI correspondant in Seattle and Southern Canada.
The original data is kept under the law of SPQNF, that means a 60 y.
long secret storage in the cellars of the Capitol.
J.E. Hoover IV, Jun.]
{The whole article was written in crypto high dubbed "D" and hidden by
secret unreadable pure uric acid. All by the 68th amendment.}
>bruce
Robert Hyatt
Rolf Tueschen (TUESCHEN.MEDIZ...@t-online.de) wrote:
: brucemo <bru...@seanet.com> wrote:
: >Ferret is an extremely strong program, but aren't they all these days.
: >1) It is not commercial. It will be commercial eventually.
: >2) Binaries are not available. It plays on ICC, occasionally on fics and
: >chess.net.
: >3) Yes:
: Bruce, excuse me. It's sunday morning and all the bells ring for a new
: Pope's day.
: As you know me so often swollen these days....
: But now I read that you had stolen most of the feautures of FERRET.
: Your description sounds for me swollen ears like a spare-part surgery
: seminary. And not enough, you forgot mostly the origin of your robbery.
: You dont know about correct accountancy? :)
: At least I do understand now why you act clumsyly in front of all the
: benefactors... (the proxy story finally is also solved for me.)
<sigh> Let me give you a shocking piece of information. *every* commercial
program now being sold is about 75% "stolen" from chess 4.x... does that
change anything? Greenblatt first reported the use of hash tables. Slate
first reported the iterated search, killer moves and bitmaps. Thompson first
reported on endgame databases. Blitz was the first program I know of that
could evaluate pawn races without a search. etc. Your comment to Bruce is
not only out of place, but ignorant...
BTW, he doesn't "steal" from me... I "give" to him... and he returns the
favor many times over...
Carl Tillotson
<lots snipped>
Bruce,
There appears to be a lot of so called "stolen" code there :-)
Surely you didn't steal it, just re-engineered for a better use :-)
Carl Tillotson
=============
Lancashire Chess Association Homepage
http://www.netcomuk.co.uk/~lca/index.htm
For the latest news, reviews and events happening on the
Lancashire Chess scene, visit the Lancashire Chess Association
homepage.
Rolf Tueschen
hy...@crafty.cis.uab.edu (Robert Hyatt) wrote:
>: >3) Yes:
Yeah, taken literally, your suckin', very refreshin' holiness... :)
Pope Ignor, The Tarantula Teutonica Teuschikowskikussikusa
Vincent Diepeveen
>Rolf Tueschen (TUESCHEN.MEDIZ...@t-online.de) wrote:
>: brucemo <bru...@seanet.com> wrote:
>
>
>: >Ferret is an extremely strong program, but aren't they all these days.
>
>: >1) It is not commercial. It will be commercial eventually.
>
>: >2) Binaries are not available. It plays on ICC, occasionally on fics and
>: >chess.net.
>
>: >3) Yes:
>
>: Bruce, excuse me. It's sunday morning and all the bells ring for a new
>: Pope's day.
>
>: As you know me so often swollen these days....
>
>: But now I read that you had stolen most of the feautures of FERRET.
>: Your description sounds for me swollen ears like a spare-part surgery
>: seminary. And not enough, you forgot mostly the origin of your robbery.
>: You dont know about correct accountancy? :)
>
>: At least I do understand now why you act clumsyly in front of all the
>: benefactors... (the proxy story finally is also solved for me.)
>
><sigh> Let me give you a shocking piece of information. *every* commercial
>program now being sold is about 75% "stolen" from chess 4.x... does that
>change anything? Greenblatt first reported the use of hash tables. Slate
>first reported the iterated search, killer moves and bitmaps. Thompson first
>reported on endgame databases. Blitz was the first program I know of that
>could evaluate pawn races without a search. etc. Your comment to Bruce is
>not only out of place, but ignorant...
>
>BTW, he doesn't "steal" from me... I "give" to him... and he returns the
>favor many times over...
>
>
I see a lot of new names in the WMCCC list. Of course not everyone might
have internet access, and not everyone plays in tournaments i have heard
of.
I wonder however how many of these programs should have the lable crafty?
A first indication usually is the interface. If it looks like it, then
it is definitely not the same. If every byte on the screen matches, then
their is a chance, in DCCC such a mistake (same interface, same terrible
tactics against Diep of that program - the tactical horizon effect the
opponent of Diep had, appeared to be the same Crafty had at that time)
has been made, i was told.
So in WMCCC i'm going hunting for crafty clones!
In my prayer i ask to play against a crafty clone every round, no matter
its hardware, and i keep hoping
not to play against Hiarcs (why do i keep thinking Mark already has
at least that professional title?) too much
(the chessbase company may also
join with Hiarcs instead of Fritz i'm told, this is the only reason i
am afraid for Fritz - it might be Hiarcs. It probably will be hiarcs,
as this program plays supurb compared to (with all respect by the way
for the programmer Morsch) Fritz original engine).
Playing 2 times against Hiarcs would be too much for Diep.
It would however be unfair if a program joins 2 times, and besides that
there are a lot of participants which can not join because of this. Therefore
we should check carefully how many Crafty clones join this time.
Vincent
--
+----------------------------------------------------+
| Vincent Diepeveen email: vdie...@cs.ruu.nl |
| http://www.students.cs.ruu.nl/~vdiepeve/ |
+----------------------------------------------------+
Robert Hyatt
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
: >Dann Corbit wrote:
: >
: >> Of course, I would be very interested. I have read a few things {newsgroup
: >> postings here and chess newsletters on the WWW} that suggest that ferret is
: >> an extremely strong program.
: >> 1. Is it commercial?
: >> 2. Are binaries available?
: >> 3. Do you discuss the algorithms you use?
: >> 4. Etc.
: >
: >Ferret is an extremely strong program, but aren't they all these days.
: >1) It is not commercial. It will be commercial eventually.
: >2) Binaries are not available. It plays on ICC, occasionally on fics and
: >chess.net.
: >3) Yes:
: >Ferret is a conventional null-move program (R=2, described by Donninger).
: >Other than null move, I do little pruning and extension tricks that cost a
: >little here, and save a little there (ideas from Hyatt, a single-response
: >extension that I deduced from an ad for a commerical program, and a few ideas
: >that may even be original, if this is still possible). I use a recapture
: >extension stolen from Hans Berliner via Bob Hyatt.
: >
: >It's 32-bit, written in C, compiled with MSVC 5.0, and running on anything
: >that runs Windows '95 or Windows NT.
: I use Watcom 10.0 Quite old nowadays.
: How much better optimizes this new Microsoft
: compiler compared to watcom?
much better, from tests I've seen with Crafty.
: >Quiescent search is constrained by a static exchange evaluator. This is
: >stolen from Cray Blitz or Belle, can't remember which.
: Do you extend some extra checks in ab-search in order to prevent
: Ferret from not seeing mate in xx?
we both extend on checks and one-reply...
: >The evaluation is done at the tips, and it has as much stuff in it as I can
: >include without slowing it down much.
: How do you evaluate with a static exchange evaluator?
: I wouldn't know how to evaluate without making the i win a piece move in
: the quiescent search. How do you catch this problem?
we both use this info to choose which captures are worth following, and to
order the captures from best-to-worst. We still do a traditional capture
quiescence search.
: > It doesn't compute mobility, but it
: >does try to understand when a piece is good or bad. It uses asymmetrical king
: >safety routines. Stuff is stolen from Chess 4.5 and GnuChess and everyone
: >else.
: >Move generation is done via a move table, a refinement of the technique used
: >in GnuChess.
: Same in Diep. It uses precalculated move tables.
: >It has all of the standard stuff including a hash table (two tables, one is
: >replace always, and one is replace if deeper or left over from a previous
: >search, this is stolen from Ken Thompson), a pawn hash table, a king safety
: >hash table (these last two are stolen from Cray Blitz description), killer
: >moves (don't know who invented this), history heuristic (Schaeffer), etc.
: >
: >It has endgame tables that I built myself from a description by David Levy.
: What tables does Ferret support?
about 17 gigabytes worth, all 3-4 piece, plus KRP vs KR and supported files,
plus K+minor+pawn vs K+minor, plus the promotion cases. Bruce has calculated
a *bunch* of these..
: >I've certainly left some people out. I've gotten ideas from Deep Thought but
: >offhand I can't remember which ones. I have also gotten a lot of help from
: >various amateur programmers, and the odd hint from a professional.
: >
: >Node rate on a P6/200 is between 75K and 225K, >350K in weird cases.
: >
: >Node rate on a 533mhz Alpha is maybe 150K to 400K, >600K in weird cases.
: Just 2 times out of a 533 alpha machine versus a P6/200?
: Now you are trying to get us underestimate you!
: Are you sure you just get 2x speed up?
: I thought an alpha gives more for a megaherz than an intel processor gives you!
this sounds about right... remember Ferret isn't doing much in the way of 64bit
stuff. So part of the performance increase is lost. All he is taking advantage
of is the faster clock, but he loses some of that due to accessing/needing less than
64 bits per memory cycle.
: Don't you profit also from the bigger L2 cache and L1 cache?
L1 is not bigger when you count the L2 cache on the P6 runs at processor clock
speed, while the L2 cache on the alpha doesn't... The P6 compares pretty well
if you compare 32 bit operations vs 32 bit operations. The alpha eats it at
64 bit operations however...
brucemo
Robert Hyatt wrote:
> I would hope "zero". But if someone takes the bitmap code and does their
> own thing to it, I have no problem with those being entered. I'd bet there
> are *many* programs that can be directly traced back to gnuchess. last
> year's event was a big mistake, because I believe Gunda-1 was probably a
> nearly "stock" crafty clone. I'd suspect this year that won't happen,
> but you never know...
There was a huge communication problem. Accepting the entry was a way to get
past this. I doubt that it will happen again.
bruce
Robert Hyatt
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
: >Rolf Tueschen (TUESCHEN.MEDIZ...@t-online.de) wrote:
: >: brucemo <bru...@seanet.com> wrote:
: >
: >
: >: >Ferret is an extremely strong program, but aren't they all these days.
: >
: >: >1) It is not commercial. It will be commercial eventually.
: >
: >: >2) Binaries are not available. It plays on ICC, occasionally on fics and
: >: >chess.net.
: >
: >: >3) Yes:
: >
: >: Bruce, excuse me. It's sunday morning and all the bells ring for a new
: >: Pope's day.
: >
: >: As you know me so often swollen these days....
: >
: >: But now I read that you had stolen most of the feautures of FERRET.
: >: Your description sounds for me swollen ears like a spare-part surgery
: >: seminary. And not enough, you forgot mostly the origin of your robbery.
: >: You dont know about correct accountancy? :)
: >
: >: At least I do understand now why you act clumsyly in front of all the
: >: benefactors... (the proxy story finally is also solved for me.)
: >
: ><sigh> Let me give you a shocking piece of information. *every* commercial
: >program now being sold is about 75% "stolen" from chess 4.x... does that
: >change anything? Greenblatt first reported the use of hash tables. Slate
: >first reported the iterated search, killer moves and bitmaps. Thompson first
: >reported on endgame databases. Blitz was the first program I know of that
: >could evaluate pawn races without a search. etc. Your comment to Bruce is
: >not only out of place, but ignorant...
: >
: >BTW, he doesn't "steal" from me... I "give" to him... and he returns the
: >favor many times over...
: >
: >
: I see a lot of new names in the WMCCC list. Of course not everyone might
: have internet access, and not everyone plays in tournaments i have heard
: of.
: I wonder however how many of these programs should have the lable crafty?
I would hope "zero". But if someone takes the bitmap code and does their
own thing to it, I have no problem with those being entered. I'd bet there
are *many* programs that can be directly traced back to gnuchess. last
year's event was a big mistake, because I believe Gunda-1 was probably a
nearly "stock" crafty clone. I'd suspect this year that won't happen,
but you never know...
: A first indication usually is the interface. If it looks like it, then
: it is definitely not the same. If every byte on the screen matches, then
: their is a chance, in DCCC such a mistake (same interface, same terrible
: tactics against Diep of that program - the tactical horizon effect the
: opponent of Diep had, appeared to be the same Crafty had at that time)
: has been made, i was told.
Probably wasn't crafty... It doesn't do "terrible tactics."
: So in WMCCC i'm going hunting for crafty clones!
: In my prayer i ask to play against a crafty clone every round, no matter
: its hardware, and i keep hoping
: not to play against Hiarcs (why do i keep thinking Mark already has
: at least that professional title?) too much
: (the chessbase company may also
: join with Hiarcs instead of Fritz i'm told, this is the only reason i
: am afraid for Fritz - it might be Hiarcs. It probably will be hiarcs,
: as this program plays supurb compared to (with all respect by the way
: for the programmer Morsch) Fritz original engine).
I'll bet you get your wish to play against Crafty. Let's see then whether
you might reconsider that or not. Meanwhile I'm always available on ICC,
FICS and chess.net... try your luck at any time. Crafty never hides...
And if you want to play Crafty every round, I assume that means you
think you can win more tha 3/4 of them to have a chance in the
tournament? Pick a day and time and time-control. I'd like to watch you
back that up on ICC or somewhere... Sounds like a brash statement. To
paraphrase a few famous movie actors, "don't let your mouth write a check
your chess program can't cash." Or, perhaps, it should be "don't let your
mouth write a check your program can't cache." :)
: Playing 2 times against Hiarcs would be too much for Diep.
I look forward to playing him. Crafty's done quite well against both
Hiarcs and Fritz. I'd be willing to play anyone over there. That's
why we are going.
: It would however be unfair if a program joins 2 times, and besides that
: there are a lot of participants which can not join because of this. Therefore
: we should check carefully how many Crafty clones join this time.
I hope only *one*. That is *my* preference also.
: Vincent
Ren Wu
On Sat, 27 Sep 1997 20:14:24 -0700, brucemo <bru...@seanet.com>
wrote:
-snip
>Ferret is an extremely strong program, but aren't they all these days.
>
-snip
Oh deal, bruce, You said far too much about your program!
In fact, it looks like you are describing my program! Except mine
doesn't use static evaluator in capture search and not using endgame
databeses. Mine is also a little weak of course, for now :)
One day I will put the endgame stuff in, I happen to be very good at
this area.
What I am not sure is the static evaluator, Would you give me the
difinate answer that in ferret using it is better than not?
Ren.
- remove one loop if you reply by email
Robert Hyatt
Ren Wu (re...@loop.loop.com) wrote:
: On Sat, 27 Sep 1997 20:14:24 -0700, brucemo <bru...@seanet.com>
: wrote:
: -snip
: -snip
I can answer for Crafty...
I use this to order the capture moves, particularly useful in the
quiescence search, because if a capture is unsafe according to the
SEE algorithm, you can avoid searching that capture at all. If
you don't do this, you must be using some sort of "MVV/LVA" type
of capture ordering idea, which doesn't let you throw out losers
for one thing, but it also doesn't give you quite as good move
ordering as using a SEE procedure...
But we are only talking about speed here, when you get to the
bottom. Because MVV/LVA searches more nodes to arrive at the
same result, while SEE searches fewer nodes, but it is a little
more expensive.
in the case of Crafty, using SEE to order the captures and get rid
of obviously bad captures resulted in a savings of over 50%... that
is I was getting to the same depth just a little over 2x faster than
I was without SEE.
brucemo
Vincent Diepeveen wrote:
> I wonder however how many of these programs should have the lable crafty?
I don't think you are suggesting that mine is a Crafty clone, but in case
you are, it isn't. I use techniques from everyone, but I write the code
myself.
Personally I expect you will find zero Crafty clones at Paris, although you
will see many programs have benefited from techniques invented and/or
popularized by Hyatt and others.
bruce
brucemo
Ren Wu wrote:
> What I am not sure is the static evaluator, Would you give me the
> difinate answer that in ferret using it is better than not?
There was a massive argument about this a couple of years ago.
The two competing paradigms were, static exchange evaluator (SEE)
and most-valuable-victim/least-valuable-attacker (MVV/LVA).
I had SEE in mine at the time. I tried MVV/LVA in response to that
thread, and determined that SEE worked better for me. I got to
depth D in like half as many nodes, and overhead from the SEE
function was not very high, so it was a big win.
It is a little tricky to write a good SEE. The way I did it, you
have to be able to access the pieces in the right order, and you
have to be able to quickly determine if a piece attacks a square.
You have to make sense out of the possible capture and recapture
sequences that you encounter.
Some people who were arguing about MVV/LVA mentioned that their
programs were optimized to make MVV/LVA very efficient. Mine
isn't, because I don't use it. So perhaps for them, this is
faster.
bruce
brucemo
> : I use Watcom 10.0 Quite old nowadays.
> : How much better optimizes this new Microsoft
> : compiler compared to watcom?
>
> much better, from tests I've seen with Crafty.
I've never used Watcom. I didn't consider spending hundreds of dollars just to see if
another compiler is worth a few percent. Most of the time I was using MSVC I got it a
a deep employee discount, and I've continued using it since I left Microsoft.
[Answers from Bob snipped]
> : What tables does Ferret support?
>
> about 17 gigabytes worth, all 3-4 piece, plus KRP vs KR and supported files,
> plus K+minor+pawn vs K+minor, plus the promotion cases. Bruce has calculated
> a *bunch* of these..
I've got every 5-man table that I thought might have practical use, but I'm not sure
yet if I will use them in Paris. I don't know if they increase strength or decrease
it, the way I use them.
> : >Node rate on a P6/200 is between 75K and 225K, >350K in weird cases.
> : >
> : >Node rate on a 533mhz Alpha is maybe 150K to 400K, >600K in weird cases.
>
> : Just 2 times out of a 533 alpha machine versus a P6/200?
>
> : Now you are trying to get us underestimate you!
> : Are you sure you just get 2x speed up?
> : I thought an alpha gives more for a megaherz than an intel processor gives you!
Actually it is more like 1.8x. I'm not trying to get anyone to develop any sort of
opinion, merely answering a request for a description.
Ferret is a 32-bit application. It does use some 64-bit data structures, which can be
contained in a register now. 32-bit code also seems to go pretty fast on an Alpha, but
if you mis-align stuff, you are cooked.
The reason I got an alpha is that I was watching "Data" on ICC. That was a 500mhz
Alpha. I was impressed by how fast it was going, so I decided to try it out, and mine
went faster, too.
I have never assumed that nps on P6/200, divided by two hundred, would equal nps on
Alpha, divided by 533. I tried for a while to squeeze performance out of it, and
that's the best I could do, but I haven't tried to calculate some theoretical optimum
to see how well I could have done.
> this sounds about right... remember Ferret isn't doing much in the way of 64bit
> stuff. So part of the performance increase is lost. All he is taking advantage
> of is the faster clock, but he loses some of that due to accessing/needing less than
> 64 bits per memory cycle.
You have lots more bitmaps than I do, but I don't think I'm suffering because I use
32-bit stuff elsewhere.
bruce
Vincent Diepeveen
>Dann Corbit wrote:
>
>> Of course, I would be very interested. I have read a few things {newsgroup
>> postings here and chess newsletters on the WWW} that suggest that ferret is
>> an extremely strong program.
>> 1. Is it commercial?
>> 2. Are binaries available?
>> 3. Do you discuss the algorithms you use?
>> 4. Etc.
>
>Ferret is an extremely strong program, but aren't they all these days.
>1) It is not commercial. It will be commercial eventually.
>2) Binaries are not available. It plays on ICC, occasionally on fics and
>chess.net.
>3) Yes:
>Ferret is a conventional null-move program (R=2, described by Donninger).
>Other than null move, I do little pruning and extension tricks that cost a
>little here, and save a little there (ideas from Hyatt, a single-response
>extension that I deduced from an ad for a commerical program, and a few ideas
>that may even be original, if this is still possible). I use a recapture
>extension stolen from Hans Berliner via Bob Hyatt.
>
>It's 32-bit, written in C, compiled with MSVC 5.0, and running on anything
>that runs Windows '95 or Windows NT.
I use Watcom 10.0 Quite old nowadays.
How much better optimizes this new Microsoft
compiler compared to watcom?
>Quiescent search is constrained by a static exchange evaluator. This is
>stolen from Cray Blitz or Belle, can't remember which.
Do you extend some extra checks in ab-search in order to prevent
Ferret from not seeing mate in xx?
>The evaluation is done at the tips, and it has as much stuff in it as I can
>include without slowing it down much.
How do you evaluate with a static exchange evaluator?
I wouldn't know how to evaluate without making the i win a piece move in
the quiescent search. How do you catch this problem?
> It doesn't compute mobility, but it
>does try to understand when a piece is good or bad. It uses asymmetrical king
>safety routines. Stuff is stolen from Chess 4.5 and GnuChess and everyone
>else.
>Move generation is done via a move table, a refinement of the technique used
>in GnuChess.
Same in Diep. It uses precalculated move tables.
>It has all of the standard stuff including a hash table (two tables, one is
>replace always, and one is replace if deeper or left over from a previous
>search, this is stolen from Ken Thompson), a pawn hash table, a king safety
>hash table (these last two are stolen from Cray Blitz description), killer
>moves (don't know who invented this), history heuristic (Schaeffer), etc.
>
>It has endgame tables that I built myself from a description by David Levy.
What tables does Ferret support?
>I've certainly left some people out. I've gotten ideas from Deep Thought but
>offhand I can't remember which ones. I have also gotten a lot of help from
>various amateur programmers, and the odd hint from a professional.
>
>Node rate on a P6/200 is between 75K and 225K, >350K in weird cases.
>
>Node rate on a 533mhz Alpha is maybe 150K to 400K, >600K in weird cases.
Just 2 times out of a 533 alpha machine versus a P6/200?
Now you are trying to get us underestimate you!
Are you sure you just get 2x speed up?
I thought an alpha gives more for a megaherz than an intel processor gives you!
Don't you profit also from the bigger L2 cache and L1 cache?
Vincent
>bruce
Robert Hyatt
brucemo (bru...@seanet.com) wrote:
: Vincent Diepeveen wrote:
: > I wonder however how many of these programs should have the lable crafty?
: I don't think you are suggesting that mine is a Crafty clone, but in case
: you are, it isn't. I use techniques from everyone, but I write the code
: myself.
: Personally I expect you will find zero Crafty clones at Paris, although you
: will see many programs have benefited from techniques invented and/or
: popularized by Hyatt and others.
: bruce
Actually, Ferret was playing chess long before Crafty was an "idea"... I
met bruce via ICS (which became ICC) after I started playing Crafty there.
Ferret was already very well established and playing extremely well...
Robert Hyatt
brucemo (bru...@seanet.com) wrote:
: You have lots more bitmaps than I do, but I don't think I'm suffering because I use
: 32-bit stuff elsewhere.
Hope I didn't imply "suffering"... but the issue in the alpha is that
*everything* pumped to/from memory is 64 bits wide. If you use less
than that, you are simply pumping data that is not needed. I have a lot
of 32 bit stuff myself. But I take a hit (currently) on all the 64 bit
stuff I do because it now takes two loads/stores to do anything. On
the alpha, it all turns into a single load/store. The best performance
is when *everything* needs 64 bits of data. Which fits some applications.
Perhaps not chess, but some. But the main point is, the more 64 bit words
you use, the better the alpha performs. Just like the Cray...
Rolf Tueschen
hy...@crafty.cis.uab.edu (Robert Hyatt) wrote:
>The best performance is when *everything* needs 64 bits of data.
Sorry, but for the monster event in May DB vs GK I needed a lot more
data...
So, I cannot support this new theory.
Pope of Bits (no Shits)
brucemo
I can't argue facts with you, because I don't have any. But I can speculate a bit, and
perhaps you can tell me if I am wrong.
With my compiler, when I do "sizeof(int)", sizeof(unsigned), and "sizeof(char *)" on
the Alpha, in all cases this returns 4.
But when this stuff is brought into memory, it goes into 64-bit registers immediately
(a signed value can be grabbed with one instruction, while it's a little more
complicated to get an unsigned value, although the compiler seems to be good at it).
Once it is in a 64-bit register, and the compiler understands what it is doing, I don't
think it matters much that the original thing was 32-bits.
Yeah, it's true that there are bits I could be grabbing from memory at the same time,
and using. I have bitmaps, which I use less than your bitmaps, and I grab these all at
once. But in many many other cases, a 32-bit value will do fine. I'm sure this is the
case in Crafty, as well.
If you have a big array of ints, which in this particular case don't *have* to be 64
bits, doesn't it make sense to have them stored as 32-bit values? The array takes less
space in memory, not that I care about how much memory I use, what I care about is the
cache footprint of that array is small, so I tend to get more hits on the array, and to
displace less other stuff from the cache.
I could go through my code, looking for safe places to change "int" to "__int64" and
"unsigned" to "unsigned __int64", and I think I may be able to do this with some
pointers, as well, but I haven't done this because I didn't think this made any sense.
I'll let the compiler do what it feel comfortable doing.
If I am fetching an int, I would rather have it fetch an adjacent int, which I am not
using now, but which contains useful stuff that I might use at some other time, than
have it fetch a zero, which I have no intention of using ever, especially when the
processor will create this zero in the top 32-bits of my int, by sign extending when it
does the 32-bit load, all in one instruction.
Does this sound right?
bruce
Ren Wu
On Mon, 29 Sep 1997 15:01:33 -0700, brucemo <bru...@seanet.com>
wrote:
>Ren Wu wrote:
>
>> What I am not sure is the static evaluator, Would you give me the
>> difinate answer that in ferret using it is better than not?
>
>There was a massive argument about this a couple of years ago.
>
>The two competing paradigms were, static exchange evaluator (SEE)
>and most-valuable-victim/least-valuable-attacker (MVV/LVA).
I think I read some of the posts. But at that time, the two parties
are all bitmap based program, so I didn't pay much attension, big
mistake again.
>I had SEE in mine at the time. I tried MVV/LVA in response to that
>thread, and determined that SEE worked better for me. I got to
>depth D in like half as many nodes, and overhead from the SEE
>function was not very high, so it was a big win.
This is a real surprise! Especially when I know that we have pretty
much same program structure. If my program can reduce half nodes, I
will be very happy.
>It is a little tricky to write a good SEE. The way I did it, you
>have to be able to access the pieces in the right order, and you
>have to be able to quickly determine if a piece attacks a square.
>You have to make sense out of the possible capture and recapture
>sequences that you encounter.
Thanks for the tips. Yes, I have to think hard before I start.
>Some people who were arguing about MVV/LVA mentioned that their
>programs were optimized to make MVV/LVA very efficient. Mine
>isn't, because I don't use it. So perhaps for them, this is
>faster.
I used MVV/LVA for a long time and I think mine is quite fast. But if
both you and Bob can get 2x speed up here, I am pretty sure SEE is
better, at least I know I HAVE to try it.
>bruce
Thanks.
Ren Wu
On 29 Sep 1997 19:47:49 GMT, hy...@crafty.cis.uab.edu (Robert Hyatt)
wrote:
>Ren Wu (re...@loop.loop.com) wrote:
>: What I am not sure is the static evaluator, Would you give me the
>: difinate answer that in ferret using it is better than not?
>
>
>I can answer for Crafty...
>
>I use this to order the capture moves, particularly useful in the
>quiescence search, because if a capture is unsafe according to the
>SEE algorithm, you can avoid searching that capture at all. If
>you don't do this, you must be using some sort of "MVV/LVA" type
>of capture ordering idea, which doesn't let you throw out losers
>for one thing, but it also doesn't give you quite as good move
>ordering as using a SEE procedure...
>
>But we are only talking about speed here, when you get to the
>bottom. Because MVV/LVA searches more nodes to arrive at the
>same result, while SEE searches fewer nodes, but it is a little
>more expensive.
>
>in the case of Crafty, using SEE to order the captures and get rid
>of obviously bad captures resulted in a savings of over 50%... that
>is I was getting to the same depth just a little over 2x faster than
>I was without SEE.
Thanks, Bob. I can understand that Crafty will benefit from SEE a lot.
but 2x speed up is still singficant. Now I think this is something I
have to put into my program.
Robert Hyatt
brucemo (bru...@seanet.com) wrote:
Yes. But in such cases, I lose also. Because every memory reference is for
8 bytes on the alpha. And if I do that very often, I throw out 1/2 of the
available memory bandwidth. In my case, it still happens a lot. But all the
64bit stuff runs 2x faster on the alpha than the P6 because of memory traffic
capabilities. I only wish I could do more using 64 bits, because that
machine pumps 64 bit values very quickly. *exactly* as fast as it pumps
32 bit values, in fact. Which is a problem for 32 bit values...
: If you have a big array of ints, which in this particular case don't *have* to be 64
: bits, doesn't it make sense to have them stored as 32-bit values? The array takes less
: space in memory, not that I care about how much memory I use, what I care about is the
: cache footprint of that array is small, so I tend to get more hits on the array, and to
: displace less other stuff from the cache.
Don't do that. An array of characters is even better, just so long as you tend
to use all the adjacent entries close temporally... Because you can get 8
bytes in one reference, and waste a few instructions to break it up into
chunks, which is far faster than 8 separate loads... If you use a random
byte here and there, it doesn't matter, because you load 64 bits either
way and only use 8... but *if* you can load 64 bits and use them then this
becomes a win...
: I could go through my code, looking for safe places to change "int" to "__int64" and
: "unsigned" to "unsigned __int64", and I think I may be able to do this with some
: pointers, as well, but I haven't done this because I didn't think this made any sense.
: I'll let the compiler do what it feel comfortable doing.
: If I am fetching an int, I would rather have it fetch an adjacent int, which I am not
: using now, but which contains useful stuff that I might use at some other time, than
: have it fetch a zero, which I have no intention of using ever, especially when the
: processor will create this zero in the top 32-bits of my int, by sign extending when it
: does the 32-bit load, all in one instruction.
: Does this sound right?
yes. In fact, part of the fun on that machine is grouping things into 64
bit quantities, just like I have grouped things into 32 bit quantities on
the P6...
John Stanback
brucemo wrote:
>
> Ren Wu wrote:
>
> > What I am not sure is the static evaluator, Would you give me the
> > difinate answer that in ferret using it is better than not?
>
>
> The two competing paradigms were, static exchange evaluator (SEE)
> and most-valuable-victim/least-valuable-attacker (MVV/LVA).
>
> thread, and determined that SEE worked better for me. I got to
> depth D in like half as many nodes, and overhead from the SEE
> function was not very high, so it was a big win.
>
As I recall, the SEE discussion involved 2 somewhat separate search
techniques: using a static exchange evaluator to help order the moves in
the Qsearch and using a static exchange evaluator to PRUNE moves in the
Qsearch. I doubt that you can get a factor of 2 decrease in tree size
unless you use SEE to prune moves. Occasionally this pruning will fail
(even with perfect swapoff analysis on the capture square), causing the
search to take a ply or two longer to find something.
Since I'm kind of risk-averse with regards to pruning, I implemented a
very limited form of SEE pruning in the Qsearch, but got about 12%
reduction in tree size with maybe a 2% slowdown and virtually no
incorrect pruning decisions.
John
Robert Hyatt
John Stanback (j...@verinet.com) wrote:
: brucemo wrote:
: >
: > Ren Wu wrote:
: >
: > > What I am not sure is the static evaluator, Would you give me the
: > > difinate answer that in ferret using it is better than not?
: >
: > There was a massive argument about this a couple of years ago.
: >
: > The two competing paradigms were, static exchange evaluator (SEE)
: > and most-valuable-victim/least-valuable-attacker (MVV/LVA).
: >
: > I had SEE in mine at the time. I tried MVV/LVA in response to that
: > thread, and determined that SEE worked better for me. I got to
: > depth D in like half as many nodes, and overhead from the SEE
: > function was not very high, so it was a big win.
: >
: As I recall, the SEE discussion involved 2 somewhat separate search
: techniques: using a static exchange evaluator to help order the moves in
: the Qsearch and using a static exchange evaluator to PRUNE moves in the
: Qsearch. I doubt that you can get a factor of 2 decrease in tree size
: unless you use SEE to prune moves. Occasionally this pruning will fail
: (even with perfect swapoff analysis on the capture square), causing the
: search to take a ply or two longer to find something.
yes. SEE reduced the tree size about 10% over mvv/lva. If you can keep the
cost of the SEE code down, that may barely break even. But if you use SEE
to toss out obvious losers (QxP where P is defended by P for example, where
SEE says -8.000) then you can reduce tree size by 50% more...
: Since I'm kind of risk-averse with regards to pruning, I implemented a
: very limited form of SEE pruning in the Qsearch, but got about 12%
: reduction in tree size with maybe a 2% slowdown and virtually no
: incorrect pruning decisions.
:
I've never seen any sort of problem that I've tracked back to SEE pruning in
the q-search... I've done this on Cray Blitz as well..
: John
Vincent Diepeveen
>Vincent Diepeveen wrote:
>
>> I wonder however how many of these programs should have the lable crafty?
>
>I don't think you are suggesting that mine is a Crafty clone, but in case
>you are, it isn't. I use techniques from everyone, but I write the code
>myself.
You would be the last one Bruce!
>Personally I expect you will find zero Crafty clones at Paris, although you
>will see many programs have benefited from techniques invented and/or
>popularized by Hyatt and others.
BTW, how much systemtime does Ferrets evaluation eat?
I was in fact as Bob pointed out referring to for example the behaviour
of Gunda-1 or something in Jakarta, and to some other program(s),
but it could be of course the case that they tried to change something,
and simply failed in this.
A good thing is of course that they choose Crafty instead of Gnuchess.
It clearly indicates that Crafty plays way better than Gnuchess!
Vincent Diepeveen
Diep works with Winboard. I got it to work yesterday evening
(tomorrow 2AM is a better word). So with the old tournament book we
might already play this evening, that's after i copied some software
to connect to internet.
I have internet access tonight i hope. I sent money to an internet company,
xs4all, and i hope that this evening i will be able to play on ICC.
If not then it can be only a matter of a few days.
I do not know however how to prevent lag from home, but i guess i
can ask it while playing!
>: Playing 2 times against Hiarcs would be too much for Diep.
>I look forward to playing him. Crafty's done quite well against both
>Hiarcs and Fritz. I'd be willing to play anyone over there. That's
>why we are going.
Perhaps on internet, perhaps on a 486, but at a K6 crafty against Hiarcs?
Mark may make a big statement about the chances of crafty against his i think!
I've seen % of 85% and higher from Hiarcs at that hardware.
>: It would however be unfair if a program joins 2 times, and besides that
>: there are a lot of participants which can not join because of this. Therefore
>: we should check carefully how many Crafty clones join this time.
>
>I hope only *one*. That is *my* preference also.
For some reason i hope to play few :)
On the other hand, this means that i will not become worldchampion!
>: Vincent
brucemo
John Stanback wrote:
> As I recall, the SEE discussion involved 2 somewhat separate search
> techniques: using a static exchange evaluator to help order the moves in
> the Qsearch and using a static exchange evaluator to PRUNE moves in the
> Qsearch. I doubt that you can get a factor of 2 decrease in tree size
> unless you use SEE to prune moves. Occasionally this pruning will fail
> (even with perfect swapoff analysis on the capture square), causing the
> search to take a ply or two longer to find something.
Cool. Yes, I prune like crazy in mine.
bruce
Robert Hyatt
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
get timestamp. then lag won't be a problem as it will correct for
transmission delays from your machine to the server.
: >: Playing 2 times against Hiarcs would be too much for Diep.
: >I look forward to playing him. Crafty's done quite well against both
: >Hiarcs and Fritz. I'd be willing to play anyone over there. That's
: >why we are going.
: Perhaps on internet, perhaps on a 486, but at a K6 crafty against Hiarcs?
yes.
: Mark may make a big statement about the chances of crafty against his i think!
Mark can make any sort of statement he wants. As can anyone else. We'll know
a lot more in 30 days or so than any "statements" will prove, right?
: I've seen % of 85% and higher from Hiarcs at that hardware.
85% and up against who? Diep? If I'm losing almost 9 of every 10 against
any program, I don't need to be working on a chess program at all, because
something is grossly wrong.
I'm glad you like Hiarcs. I'm also glad you don't think much of Crafty. I
had that same problem with Cray Blitz, but it managed to litter the ground
with the corpses of those that thought it couldn't play chess. Crafty's
quite capable of doing the same... It does this regularly, in fact. I only
know of two programs that it has recurring problems with... Ferret and WchessX.
Both of those are *very* strong.
Once upon a time you were claiming to be the best in the world at long time
controls. That seems to have been dispelled. Speculation usually gives way
to execution. You can prove your supremecy over Crafty whenever you want. Just
let me know when and the time control..
: >: It would however be unfair if a program joins 2 times, and besides that
: >: there are a lot of participants which can not join because of this. Therefore
: >: we should check carefully how many Crafty clones join this time.
: >
: >I hope only *one*. That is *my* preference also.
: For some reason i hope to play few :)
: On the other hand, this means that i will not become worldchampion!
I sense you believe in some sort of supremacy over Crafty? I don't make
such claims, I simply offer challenges. Feel free to accept mine at any
time you choose. If you win enough, I'll believe. Until then, I choose
to wait and watch.
brucemo
Vincent Diepeveen wrote:
> BTW, how much systemtime does Ferrets evaluation eat?
Good question. I looked through some old profile reports and the answer is
15-40%. That's so vague it might not provide a good answer though. I
don't have a better one.
> A good thing is of course that they choose Crafty instead of Gnuchess.
> It clearly indicates that Crafty plays way better than Gnuchess!
Crafty is easily strong enough to be commercial. It plays strong and
interesting chess.
bruce
Vincent Diepeveen
Against programs like Fritz, Genius and Kallisto.
Not at all against Diep. The more time Diep gets the better it plays.
>I'm glad you like Hiarcs. I'm also glad you don't think much of Crafty. I
>had that same problem with Cray Blitz, but it managed to litter the ground
>with the corpses of those that thought it couldn't play chess. Crafty's
>quite capable of doing the same... It does this regularly, in fact. I only
>know of two programs that it has recurring problems with... Ferret and WchessX.
>Both of those are *very* strong.
So you loose from the deep searchers, which have probably the same
plan, but only a ply more deeper calculated?
>Once upon a time you were claiming to be the best in the world at long time
>controls.
It is even better right now. It even at tournament level (1 minute a move
at a K6-233)
scores 50% against Rebel,Hiarcs and Genius5.
So the big progress in Diep is that it plays more carefully, preventing
rude king attacks and preventing opponents from promoting pawns.
Some versions of Diep have problems with the deep searchers if they
search over 3 ply more deeper than Diep. The above programs clearly do
not search positionally more than 2 ply more than Diep.
Some versions which i command to do nothing, easily win from the
deep searchers (Kallisto,Fritz) but have problems with Rebel,Hiarcs and
Genius (which is even better in doing nothing than Kallisto is,
but at the right moment starts usually king attacks, but that can also
be derived sometimes from its newer book).
The strange thing is blitz at a K6, 10 minutes pppg (pro program pro game).
I thought Diep was always a bad blitz player,
but at blitz diep also gets 50% against Kallisto (the
new version of Diep and the new K2)!
That was the most surprising thing.
Of course this will be not enough to win worldtitle i guess. 50% is
nog enough to become world champion. You need i guess at least 9.5 points
to become world champion. That's far over 80%!
> That seems to have been dispelled. Speculation usually gives way
>to execution. You can prove your supremecy over Crafty whenever you want. Just
>let me know when and the time control..
>
>: >: It would however be unfair if a program joins 2 times, and besides that
>: >: there are a lot of participants which can not join because of this. Therefore
>: >: we should check carefully how many Crafty clones join this time.
>: >
>: >I hope only *one*. That is *my* preference also.
>
>: For some reason i hope to play few :)
>: On the other hand, this means that i will not become worldchampion!
>
>I sense you believe in some sort of supremacy over Crafty? I don't make
>such claims, I simply offer challenges. Feel free to accept mine at any
>time you choose. If you win enough, I'll believe. Until then, I choose
>to wait and watch.
>
challenge accepted. I hope that i can get timestamp to work tomorrow
morning. If so, then Friday evening (dutch time, so that is about
San Francisco time + 9 hours)
right now it's 14:14 over here. That's 2x7:2x7
Greetings, and hope to see you Friday night for me, and Friday evening
at yours!
I'll first try the blitz against Crafty, then will try longer timecontrols,
if Crafty doesn't get already crushed.
Robert Hyatt
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
: challenge accepted. I hope that i can get timestamp to work tomorrow
: morning. If so, then Friday evening (dutch time, so that is about
: San Francisco time + 9 hours)
: right now it's 14:14 over here. That's 2x7:2x7
: Greetings, and hope to see you Friday night for me, and Friday evening
: at yours!
: I'll first try the blitz against Crafty, then will try longer timecontrols,
: if Crafty doesn't get already crushed.
Nothing like a little confidence. :)
Jan-Frode Myklebust
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
:
: challenge accepted. I hope that i can get timestamp to work tomorrow
: morning. If so, then Friday evening (dutch time, so that is about
: San Francisco time + 9 hours)
:
: right now it's 14:14 over here. That's 2x7:2x7
:
: Greetings, and hope to see you Friday night for me, and Friday evening
: at yours!
:
: I'll first try the blitz against Crafty, then will try longer timecontrols,
: if Crafty doesn't get already crushed.
Is this happening? Could somebody please post time and server, icc?
janfrode