Unsubstantiated claim in the Diep homepage
brucemo
Here is a web page address:
http://www.students.cs.ruu.nl/~vdiepeve/homepage/about.html
Here is the first paragraph of that web page:
"Diep is without doubt the strongest chess analysis program
in the world at infinite level (few hours a move). The
longer you allow it to analyse the better the move it will
produce, something which is uncommon for most other
chessprograms, caused by the enormeous chessknowledge in
Diep, which is at the time still considerably growing every
month (and decreasing the Diep searchspeed)."
This program is for sale for fifty bucks.
Perhaps by including all of this information I will induce
people to send Mr. Diepeveen fifty bucks and order his
program. If so, great. Everyone who has written a
program should get the occasional check for fifty bucks.
However, that is not the intent of this post.
A claim has been made in the web page, the claim that one
program is better than all others. This is a serious claim,
and is more serious because the claim is accompanied by an
order form.
I have challenged this claim in this newsgroup, and so have
other folks. Up until now Mr. Diepeveen has not responsed
with anything concrete.
I would like to once again solicit proof of this claim from
Mr. Diepeveen.
Please show us why your program is stronger than any other,
Mr. Diepeveen.
I would expect that since you claim that your program is a
strong analysis program if you leave it running for a few
hours, that unless your claim is purely intuitive, you would
at least have some proof in your possession that Diep is
strong if given sufficient time to analyze.
I think that if I were making such a claim, I would have a
collection of positions of a complex positional nature (and
apparently some tactical positions, as the only positions
discussed in here have been tactical), that after a long
period of time, Diep solves.
If you have such a suite, please publish it here, along with
Diep's time to solve, principle variation, and score, as I
would like to begin to independently verify your claim.
If you have some other means of substantiating your claim,
please publish it.
If you do not wish to substantiate your claim, don't you
think it is wrong to make such a claim, especially in a web
page that is essentially an advertisement?
bruce
Peter W. Gillgasch
brucemo <bru...@nwlink.com> wrote:
> Here is a web page address:
>
> http://www.students.cs.ruu.nl/~vdiepeve/homepage/about.html
Checked this.
> Here is the first paragraph of that web page:
>
> "Diep is without doubt the strongest chess analysis program
> in the world at infinite level (few hours a move). The
> longer you allow it to analyse the better the move it will
> produce, something which is uncommon for most other
> chessprograms, caused by the enormeous chessknowledge in
> Diep, which is at the time still considerably growing every
> month (and decreasing the Diep searchspeed)."
I find the text at Vincent's home page quite interesting.
Basically it presents some technical information, but it also shows that
Vincent is a bit single minded (sorry Vincent, no flame intended) since
the content can be paraphrased and condensed in the following
statements:
1. Diep is competitive if it has significant time advantage over
commercial competition (or academic competition, for that matter).
2. Diep draws its playing strength from the evaluation.
My conclusion is that Diep is a design failure. I don't see the point
why it should be interesting to write a program that needs a significant
edge in time / machine power to be competitive. In other words, it is
not competitive at all.
Evaluation can help a lot, so can searching. We know that. The
interesting point in Vincent's home page is essentially his claim that
if we "swallow" his definition of being competitive (we get 3 minutes
per move, he gets 2 hours) that his evaluation his better than anything
that could be done by another program.
Note: I don't want to hear about Deep Blue in this thread. The guys are
playing at 3 minutes per move, they have worked hard in order to stretch
their 3 minutes to some days of our time, so leave 'em alone. The same
is true for software only guys who are investing into speed.
There is another issue raised in that page which I'd like to comment on,
and I want Vincent to answer on which information this claim is based:
"few years ago hardware was very slow compared to the current hardware.
Cheap hardware chess computers are even nowadays still very slow.
Hardware was in fact so terrible slow that even a class C player could
see combinations chessprograms didn't."
Personally I find this offensive. This claim is not backed up with any
data. Vincent could, for example, post some games of Diep (running on a
PPro 200) versus a machine like the Mephisto Berlin Pro 68020 programmed
by Richard Lang. I challenge him to show us positions in that games
where the Berlin unit has failed to see a tactical combination which a
class C player could have seen.
> This program is for sale for fifty bucks.
>
> Perhaps by including all of this information I will induce
> people to send Mr. Diepeveen fifty bucks and order his
> program. If so, great. Everyone who has written a
> program should get the occasional check for fifty bucks.
> However, that is not the intent of this post.
Too bad :) I was going to post my bank account number :)
[ snip ]
> If you have such a suite, please publish it here, along with
> Diep's time to solve, principle variation, and score, as I
> would like to begin to independently verify your claim.
>
> If you have some other means of substantiating your claim,
> please publish it.
I want to see that data as well.
> If you do not wish to substantiate your claim, don't you
> think it is wrong to make such a claim, especially in a web
> page that is essentially an advertisement?
This page is just another proof that most chess players cannot write
chess programs and stay objective. They fall in love with their program
and make claims which they cannot back up with hard data. I have seen
this before, but Vincent is adding insult to injury by making public
claims of superiority over the rest of the gang. If Diep is superior by
any definition of competitivness, fine, prove it, Bruce wants to listen,
so do I. The standings of the last ODCC are clearly showing that using
the common definition of competitivness Diep is absolutely at the low
end.
I think this whole issue is about the definition of playing strength
again... As I often said knowledge is just a piece of the puzzle,
everybody who denies this is no practioneer.
-- Peter
mclane
brucemo <bru...@nwlink.com> wrote:
>Here is a web page address:
>http://www.students.cs.ruu.nl/~vdiepeve/homepage/about.html
>Here is the first paragraph of that web page:
>"Diep is without doubt the strongest chess analysis program
>in the world at infinite level (few hours a move).
If Vincent say this, it should be true, or ?! :-)
>The
>longer you allow it to analyse the better the move it will
>produce, something which is uncommon for most other
>chessprograms, caused by the enormeous chessknowledge in
>Diep, which is at the time still considerably growing every
>month (and decreasing the Diep searchspeed)."
So Diep has knowledge ?! Unbelievable. I think other programs have
also knowledge.
And Diep get's stronger the deeper it searches ?!
Unbelievable. I think that is not very wise spoken.
>This program is for sale for fifty bucks.
>Perhaps by including all of this information I will induce
>people to send Mr. Diepeveen fifty bucks and order his
>program. If so, great. Everyone who has written a
>program should get the occasional check for fifty bucks.
>However, that is not the intent of this post.
Yes - we will all buy this program, put it on the autoplayer and let
it play against other programs.
AND THEN WE WILL PUBLISH THE GAMES HERE AND PROOF THAT DIEP IS NOT
THAT STRONG.
>A claim has been made in the web page, the claim that one
>program is better than all others. This is a serious claim,
>and is more serious because the claim is accompanied by an
>order form.
>I have challenged this claim in this newsgroup, and so have
>other folks. Up until now Mr. Diepeveen has not responsed
>with anything concrete.
>I would like to once again solicit proof of this claim from
>Mr. Diepeveen.
>Please show us why your program is stronger than any other,
>Mr. Diepeveen.
SHOW US VINCENT!
>I would expect that since you claim that your program is a
>strong analysis program if you leave it running for a few
>hours, that unless your claim is purely intuitive, you would
>at least have some proof in your possession that Diep is
>strong if given sufficient time to analyze.
>I think that if I were making such a claim, I would have a
>collection of positions of a complex positional nature (and
>apparently some tactical positions, as the only positions
>discussed in here have been tactical), that after a long
>period of time, Diep solves.
>If you have such a suite, please publish it here, along with
>Diep's time to solve, principle variation, and score, as I
>would like to begin to independently verify your claim.
>If you have some other means of substantiating your claim,
>please publish it.
>If you do not wish to substantiate your claim, don't you
>think it is wrong to make such a claim, especially in a web
>page that is essentially an advertisement?
>bruce
Has he ever proven something. No.
Tom C. Kerrigan
This is not *directly* related to the thread topic, but I think a few
people might find it interesting.
Vincent has recently claimed 700,000 non-quiescence-search nodes per
second on a p5/100 if he takes a lot of stuff out of his program. BTW, he
implies that this particular program has no move ordering.
I knew this claim was silly, but I had some time on my hands this
afternoon and wanted to see just how silly it was. I basically took
everything out of my program and the result searched a blazing 1,500
"Vincent" nodes per second on my p5/100. This is slower than Stobor *with*
an evaluation function, etc. because the capture search trees explode
without move ordering. After an hour or two of tinkering, I managed to get
a program that searched just over 15,000 "Vincent" nodes per second, and
then decided I had better things to do with my time.
Anyway, it seems that Vincent is a better programmer than I am by a factor
of around 500...
Vincent, can people look directly at you? Or are they blinded by the
light?
Cheers,
Tom
brucemo
Tom C. Kerrigan wrote:
>
> This is not *directly* related to the thread topic, but I think a few
> people might find it interesting.
There might be a place for a "pig pile on Mr. Diepeveen" thread, but I'd
rather it wasn't this thread. I want Mr. Diepeveen to substantiate his
claim that his program is by far the best at analysis.
bruce
Stefano Gemma
Tom C. Kerrigan <kerr...@merlin.pn.org> scritto nell'articolo
<5brf40$a...@merlin.pn.org>...
> This is not *directly* related to the thread topic, but I think a few
> people might find it interesting.
>
> second on a p5/100 if he takes a lot of stuff out of his program. BTW, he
> implies that this particular program has no move ordering.
The better i can do is 25,248,151 moves in 12 seconds on a P133, equal to
734,676 nodes/12 seconds (from the starting position at 8 plyes with
nega-max-like alg.). I evaluate any of those moves, counting only square
values and mobility and doing selection sort. I don't optimize the last
ply, because i generate, execute and roll-back any moves even at those ply.
So i reach "only" 61,223 nodes/second. Supposing to not execute moves at
the last ply, but just to evaluate them, maybe this value can be multiplyed
by a factor of 10? I think yes, for just a mathematical reason. Mine is an
assembly program, i have these routines:
Generate move : about 20 assembly istructions per moves (with a simple
evaluation)
Selection sort: a loop of about 10 istructions per move
Execute move : 21 istructions per move
RollBack move : 17 istructions per move (this routine undo moves)
AlfaBeta alg. : about 10 istructions per move
Supposing 1 cycle per istruction and 35 moves per node, the selection sort
takes about 10*(35/2)=175 cycles. If we execute all the moves at the last
ply:
Generate : 35*20 = 700 cycles
Selection: 35*175=6125 cycles
Execution: 35*21 = 735 cycles
RollBack : 35*17 = 595 cycles
AlfaBeta : 35*10 = 350 cycles
-----------------------------
8505 clock cycles per node
8505cycles/node * 734676nodes / 133000000cycles/second = 46 seconds
This confirm my 12 seconds, because i have done a lot of approximation and
i don't consider pruning. Supposing to not execute moves at the last ply,
we needs only:
Generate : 35*20 = 700 cycles
Selection: 0
Execution: 0
RollBack : 0
AlfaBeta : 10 = 10 cycles
-----------------------------
710 clock cycles per node
The program will get more than 10 times faster, so we could reach
61233*10=600,000 nodes/second on a P133. If the P100 were 100/133 times a
P133, on a P100 we could reach 600,000*100/133=451,000 nodes/second (of
course this is a lot approximated).
Sorry, this confirm the 700,000 nodes/second, with just some extra
optimization, or an algorithm better than mine.
[...]
> Anyway, it seems that Vincent is a better programmer than I am by a
factor
> of around 500...
No! This means only that an assembly program is better than a C program of
those factor ;-)
> Vincent, can people look directly at you? Or are they blinded by the
> light?
I don't know anything about him or about its program, but it could do what
he said that it do. Maybe it doesnt, but it could! ;-)
Ciao!
Stefano Gemma
Stefano Gemma <stefan...@spiderlink.it> scritto nell'articolo
<01bc0612$4d94b2e0$ea8b...@spy00a41.spiderlink.it>...[...]
> The better i can do is 25,248,151 moves in 12 seconds on a P133, equal to
> 734,676 nodes/12 seconds (from the starting position at 8 plyes with
> The program will get more than 10 times faster, so we could reach
> 61233*10=600,000 nodes/second on a P133. If the P100 were 100/133 times a
> P133, on a P100 we could reach 600,000*100/133=451,000 nodes/second (of
> course this is a lot approximated).
I should quote myself, because i've done a big mistake. :-(
After some tryes i've found this interesting result: without executing
moves at the last ply, my program don't get 10 times faster but only a 16%
faster. The mistake that i have done is simple: in the last ply i never
execute all the moves, because i compare the score of any executed move and
AlfaBeta can cut the tree and come back to the previous ply. So at the last
ply we execute only a little of the generated moves and we can optimize
only these little number of moves.
With this optimization, my program can analyze only 734676plyes in 10
seconds instead of 12 seconds (from starting position at 8 plyes). This
means "only" 73000 plyes/second. Of course this can be reached only with a
simple evaluation, adding a "true" evaluation will make this number get
down a lot.
> Sorry, this confirm the 700,000 nodes/second, with just some extra
> optimization, or an algorithm better than mine.
Who is this idiot? ;-) Sorry, but to confirm this number, we should run 10
times faster on P133.
> > Anyway, it seems that Vincent is a better programmer than I am by a
> factor
> > of around 500...
500 is too much, we need only a factor of 10. Maybe is it still possible?
Ciao!
Vincent Diepeveen
>Here is a web page address:
>
>http://www.students.cs.ruu.nl/~vdiepeve/homepage/about.html
>Here is the first paragraph of that web page:
>
>"Diep is without doubt the strongest chess analysis program
>in the world at infinite level (few hours a move). The
>longer you allow it to analyse the better the move it will
>produce, something which is uncommon for most other
>chessprograms, caused by the enormeous chessknowledge in
>Diep, which is at the time still considerably growing every
>month (and decreasing the Diep searchspeed)."
>
>This program is for sale for fifty bucks.
>
>Perhaps by including all of this information I will induce
>people to send Mr. Diepeveen fifty bucks and order his
>program. If so, great. Everyone who has written a
>program should get the occasional check for fifty bucks.
>However, that is not the intent of this post.
>
>A claim has been made in the web page, the claim that one
>program is better than all others. This is a serious claim,
>and is more serious because the claim is accompanied by an
>order form.
>
>I have challenged this claim in this newsgroup, and so have
>other folks. Up until now Mr. Diepeveen has not responsed
>with anything concrete.
Well, diep solves much more positions for example from the Nolot
positions, although this is just a tactical test.
Ain't that enough?
You can test it yourselve bye the way, and feel free to publish
results (as long as you publish also the version number and
hardware + hashtable size you ran).
>I would like to once again solicit proof of this claim from
>Mr. Diepeveen.
>
>Please show us why your program is stronger than any other,
>Mr. Diepeveen.
I don't claim that it is strong at tournament of course.
I only claim that after say about 15 minutes on a Pro with about 30
mb hash (or about 45 minutes on a P100-32), Diep solves more
positions than any other program.
Especially middlegame it comes up with very strong moves. I'm talking
of course about positions that were in games. Not about artificiel
positions like white to mate in 270. Diep is not made to find
a forced mate in 270.
I guess that my experiment with a 200,000 nps program convinced me that
searchdepth without much knowledge doesn't work.
As you probably will not know: i have
the deepest (brute force) searching draughtsprogram in the world,
called Napoleon. Still we lost games
with Napoleon, simply because we missed knowledge.
Napoleon typically searches 14-18 ply in middlegame (tournament), where
most draughtsprograms like Flits,Truus,Dios etc. search around 10-12 ply.
Especially in middlegame Napoleon has problems.
This is the game stage
where the chessprogram Diep has NO problems. The problem of Diep
is that it doesn't
search deeply (although deeper than most amateurs). At tournament level
3 minutes a move at the MMX200Mhz Diep searches around 9-11 ply, where
a program like Kallisto hits 11-13 ply, kallisto using much less time
average a move in the middlegame than Diep (which must usually
play the endgame very fast for this reason).
So when i say Diep doesn't search deeply then this is not always true.
It is only true when one compares with Rebel/Kallisto/Fritz/Nimzo and some
Still Diep at 9-11 ply usually is tactically not bad.
As i have so much information in the program needed for evaluation,
it was not hard to use this information in a smart way, so in my
q-search i do a lot more in a lot of nodes less than most other
programs.
I will this evening run the win at chess 300 test at the current
version of Diep. i will publish it tomorrow. I will not make the
announced compare with the nullmove turned off. After few positions
already i saw enough: nullmove gives so terribly much that testing
without nullmove simply takes me too much time.
Previous version solved 297 win at chess positions. If i remember well,
there were 3 positions where it needed between 3 and 10 minutes to
solve a position, and the rest of the 294 positions were solved within
that time. Most of these 294 positions were even solved within 10 seconds.
>I would expect that since you claim that your program is a
>strong analysis program if you leave it running for a few
>hours, that unless your claim is purely intuitive, you would
>at least have some proof in your possession that Diep is
>strong if given sufficient time to analyze.
This is true. I let it run usually for about half an hour.
As we both know, my time is limited, so i cannot test more than few
positions an evening.
>I think that if I were making such a claim, I would have a
>collection of positions of a complex positional nature (and
>apparently some tactical positions, as the only positions
>discussed in here have been tactical), that after a long
>period of time, Diep solves.
I will post some positions.
No better, i will put them on my homepage.
You are right. I should give some examples, instead of giving them
only to few programmers.
>If you have such a suite, please publish it here, along with
>Diep's time to solve, principle variation, and score, as I
>would like to begin to independently verify your claim.
I will try to capture the pictures. I don't know how much systemtime
a grabber takes. I will take examples from several tests
First a nolot position, then few other positions, from which few
out of my own correspondence games and/or national games i played.
I don't know how long it will take to grab and test these.
I have only few hourse, but about 2/3 positions a day should be possible.
>If you have some other means of substantiating your claim,
>please publish it.
Ok. Please look tomorrow 21/01/1997 after 14:00 at my homepage.
The first of the examples should be there. But for now, i first
need to pick up my new video card. Hope it works.. :)
>If you do not wish to substantiate your claim, don't you
>think it is wrong to make such a claim, especially in a web
>page that is essentially an advertisement?
You are right, i should give some examples in a way that everyone
can see it.
I hope that grabbing the graphics will not hurt the systemtime Diep gets
too much.
>bruce
Vincent
--
+----------------------------------------------------+
| Vincent Diepeveen email: vdie...@cs.ruu.nl |
| http://www.students.cs.ruu.nl/~vdiepeve/ |
+----------------------------------------------------+
Vincent Diepeveen
>This is not *directly* related to the thread topic, but I think a few
>people might find it interesting.
>
>Vincent has recently claimed 700,000 non-quiescence-search nodes per
It was an experiment just to see how fast a program can be, and
how speed changes when you search deeper.
Fact is that we (Bart Weststrate and i) used minimax in the beginning.
And a very very very very limited q-search. Just at maximum 1 recapture.
In C i got 350,000 nodes a second using watcom c 10.0
Bart looked to the code and thought it was easily to rewrite to assembler,
as there were a lot of silly things the compiler outputted.
Of course NO hashtable, no move ordering, no evaluation function, just
incremental piece-square tables and material.
This is quite easy. How many moves can you generate a second?
2 million on a P5/100?
Well at least that is the number of moves my generator can handle in C.
Fritz' generator is even faster (incremental).
Then i implemented alfabeta, and killermoves. Alphabeta by the way slows
down search speed considerably, so does a deeper search. Speed by then
was around 150,000 - 250,000 nodes a second in C.
Then i implemented hashtable. Not yet transposition, just 32 bits
tuples from which 16 bits hashing and 16 bits for best move.
This considerably slowed down search again. to about 115,000 up to 150,000
in complex middlegame. Why is that so hard to believe?
How many nodes a second do you search? What do you do in q-search?
I did very little in that program. At maximum 1 recapture. None preferably.
Later i changed this to 2 recaptures (or king capture). This worked
far better. Giving better scores, but considerably slowed down search.
Perhaps you should profile your q-search?
To go back to Diep: Diep spends 5-15% of all nodes in his q-search.
In Diep i count the number of nodes spent in q-search to the number of
nodes spent in alfabeta to get the number of total nodes. In the
experimental program i didn't do this. Eats too much system time, an doesn't
give you the real speed of your program. It just gives the speed of
your capturelist() function :)
>second on a p5/100 if he takes a lot of stuff out of his program. BTW, he
>implies that this particular program has no move ordering.
>I knew this claim was silly, but I had some time on my hands this
>afternoon and wanted to see just how silly it was. I basically took
>everything out of my program and the result searched a blazing 1,500
>"Vincent" nodes per second on my p5/100. This is slower than Stobor *with*
>an evaluation function, etc. because the capture search trees explode
>without move ordering. After an hour or two of tinkering, I managed to get
>a program that searched just over 15,000 "Vincent" nodes per second, and
>then decided I had better things to do with my time.
YOU MUST DEBUG YOUR Q-SEARCH AND PROFILE IT.
The line without q-search seems difficult for you, but
don't forget that you can also see this as: the experimental program
i used had as good as NO q-search.
>Anyway, it seems that Vincent is a better programmer than I am by a factor
>of around 500...
Should i tell you how many nodes this program gets on my PP200?
multiply it by 3... :)
1500 times better?
>Vincent, can people look directly at you? Or are they blinded by the
>light?
You are blinded by the word 'without q-search' i guess.
the program i published results from used as good as no q-search,
or at maximum 1 recapture. Are we on the same track again?
Simply test how many moves you can generate pro second. Perhaps this
gets you on the right track?
Of course if you say that the experimental program sucked,
you are entirely right.
Perhaps it serves you to see how system-time consuming your q-search is?
Perhaps i should have never told you, so that you never would be able to know
how wrong you currently handle your q-search?
This is the approach most programmers use, i don't.
I tell too much.
You search already a ply deeper?
Of course, a better q-search gives you a program which is superior in
tactical short term problems. In Diep i use a combination. In the
experimental program i saw that it positional insight was so bad
that it didn't need a good q-search anyway.
The program was meant to see how deep one can search with a super stupid
program. So stupid that its main worry is material, and piece-square
tables.
the experiment failed and succeeded.
a) it is possible to search deeply having a fast program.
b) the price you pay for this is too high.
if in the piece square tables for example you increase the bonus
for white Pd4,Pe3,Nf3, and black Pd5,Pe6,Pf6 then it will search
terribly deeply, best move 1.e3 or 1.d4 depending on the plydepth.
I think however that the price you pay in this case for the huge depth
is too high. A move like 1.e3 one should forbid to play!
Want to search even deeper?
Just increase the bonus for Pa3 and Pa6, and you will even search deeper!
Of course, one should use recursive nullmove and killermoves.
>Cheers,
>Tom
Marcel van Kervinck
Robert Hyatt (hy...@cis.uab.edu) wrote:
> If you don't execute moves at the last ply, then they can't be added to the
> node count. The current definition of a node is either the number of calls
> to Search()/Quiesce or the number of calls to MakeMove()... they should be
> exactly the same...
No need for that. It's very convenient to check for illegal moves
just after MakeMove and just before the recursive call. Further,
more important: consider the next trees searched in two succesive
iterations:
* *
/ \ / \
* * * *
| / \ / \
* * * * *
| / \
* * *
There are definitely 4+10=14 nodes searched here. And only 12 MakeMoves.
Seems you are not counting the root nodes as a nodes. Why's that?
Marcel
-- _ _
_| |_|_|
|_ |_ Marcel van Kervinck
|_| mar...@stack.nl
Ed Schröder
From: vdie...@cs.ruu.nl (Vincent Diepeveen)
>Please show us why your program is stronger than any other,
>Mr. Diepeveen.
: I don't claim that it is strong at tournament of course.
: I only claim that after say about 15 minutes on a Pro with about 30
: mb hash (or about 45 minutes on a P100-32), Diep solves more
: positions than any other program.
Let me summerize, if in the year 2000 we have the P8-800 Mhz which is
for example 5 times faster than the PP200 you would have the strongest
program at 40 in 2:00 in the middle game.
Huge claim...
- Ed -
: Especially middlegame it comes up with very strong moves. I'm talking
: of course about positions that were in games. Not about artificiel
: positions like white to mate in 270. Diep is not made to find
: a forced mate in 270.
: Vincent
Ed Schröder
From: vdie...@cs.ruu.nl (Vincent Diepeveen)
>Vincent has recently claimed 700,000 non-quiescence-search nodes per
: It was an experiment just to see how fast a program can be, and
: how speed changes when you search deeper.
: Fact is that we (Bart Weststrate and i) used minimax in the beginning.
: And a very very very very limited q-search. Just at maximum 1 :
recapture. In C i got 350,000 nodes a second using watcom c 10.0
I believe this is possible...
Just a bold chess program playing legal chess.
: Bart looked to the code and thought it was easily to rewrite to
: assembler, as there were a lot of silly things the compiler outputted.
: Of course NO hashtable, no move ordering, no evaluation function, just
: incremental piece-square tables and material.
[ snip ]
: This considerably slowed down search again. to about 115,000 up to
: 150,000 in complex middlegame. Why is that so hard to believe?
I believe you.
I have a copy of Eric van Riet Paap chess program "Turning Point".
Eric's program searches more than 200,000 nodes a second in the middle
game.
Including move ordening, hash table, null move, all kind of display on
the screen while thinking. This on a PP200.
- Ed -
: Vincent
Vincent Diepeveen
In <199701172325111208482@[194.121.104.138]> gil...@ilk.de (Peter W. Gillgasch) writes:
>brucemo <bru...@nwlink.com> wrote:
>
>> Here is a web page address:
>>
>> http://www.students.cs.ruu.nl/~vdiepeve/homepage/about.html
>
>Checked this.
>
>> Here is the first paragraph of that web page:
>>
>> "Diep is without doubt the strongest chess analysis program
>> in the world at infinite level (few hours a move). The
>> longer you allow it to analyse the better the move it will
>> produce, something which is uncommon for most other
>> chessprograms, caused by the enormeous chessknowledge in
>> Diep, which is at the time still considerably growing every
>> month (and decreasing the Diep searchspeed)."
>
>I find the text at Vincent's home page quite interesting.
>
>Basically it presents some technical information, but it also shows that
>Vincent is a bit single minded (sorry Vincent, no flame intended) since
>the content can be paraphrased and condensed in the following
>statements:
>
>1. Diep is competitive if it has significant time advantage over
> commercial competition (or academic competition, for that matter).
>
>2. Diep draws its playing strength from the evaluation.
>
>My conclusion is that Diep is a design failure. I don't see the point
>why it should be interesting to write a program that needs a significant
>edge in time / machine power to be competitive. In other words, it is
>not competitive at all.
Stop!
Why not giving me also 10 years to become stronger at
tournament level?
I think that a chess program first should SEE a move, then it is
a simplistic transformation of the search process and or program
speed to allow the program to see that move within tournament level.
Especially in my draughts program i have the problem in the other
way.
The draughtsprogram manages to search between 21 to 30 ply in middlegame
after an overnight thinking, but still doesn't see moves Tsjizow/Sijbrands
play. Don't mean combinations. knowledgebased moves. little more knowledge
could do the job, but i don't see how.
In the chessprogram, as i know a lot about chess, and little about draughts,
i didn't want to write the 30th fritz. Personally, without wanting to
insult anyone, a lot of chessprograms that are on the market, or made
by amateurs look, independant programmed from each other, a lot
like each other. They get a penalty for every free pawn, a bonus
for having the bishop pair. The better they play, the more the moves
they play and the faults they make look like each other.
Of course Diep also had this problem. This is what i wanted to prevent.
a program like the other 30. I try to make a program that in the first
place must have the right knowledge (as much as possible)
In the second place i also try to
search as deeply as possible.
At first this resulted in a poor search depth. Current version still
is slower than most other programs, but searches at a depth i am not
ashamed for.
>Evaluation can help a lot, so can searching. We know that. The
I want to go for the combination of the both.
>interesting point in Vincent's home page is essentially his claim that
>if we "swallow" his definition of being competitive (we get 3 minutes
>per move, he gets 2 hours) that his evaluation his better than anything
>that could be done by another program.
>Note: I don't want to hear about Deep Blue in this thread. The guys are
>playing at 3 minutes per move, they have worked hard in order to stretch
>their 3 minutes to some days of our time, so leave 'em alone. The same
>is true for software only guys who are investing into speed.
>There is another issue raised in that page which I'd like to comment on,
>and I want Vincent to answer on which information this claim is based:
>"few years ago hardware was very slow compared to the current hardware.
>Cheap hardware chess computers are even nowadays still very slow.
>Hardware was in fact so terrible slow that even a class C player could
>see combinations chessprograms didn't."
>Personally I find this offensive. This claim is not backed up with any
>data. Vincent could, for example, post some games of Diep (running on a
>PPro 200) versus a machine like the Mephisto Berlin Pro 68020 programmed
>by Richard Lang. I challenge him to show us positions in that games
>where the Berlin unit has failed to see a tactical combination which a
>class C player could have seen.
Well, the berlin pro i don't have, nor do i have any other hardware computers.
I sold mine as soon as i got a 386 computer. That was in 1988.
Something i call a slow hardware program, from which i think it a nobelprice
worth that the programmer in the first place managed to get a chessprogram
working in so little memory:
Thanks to Fernando Villegas Darrouy who played the game
White: Diep 1.57 at a 486
Black: Travel Master
Santiago de Chile, December 15, 1996
25 minutes, sudden death
c4 e5
Nc3 Nf6
Nf3 e4
Ng5 b5
d3 Bb7
Nxp NxN
pxN pxp
Qd4 Nc6
Qxp Bb4
h4! 0-0
Bg5 Be7
Nd5! BxB
pxB Qxp
Qd3 Qd8
e5 h6
Nf6! QxN
pxQ d6
Rxp! g6
Qh3 Re8
Rh8 mate.
The travel master is quite easily mated. Of course let's not forget
that the definition of C-class is hard to make, especially if you
play master class yourselve like i do.
What i try to make clear is that although currently the hardware has
become stronger commercial programmers still don't
caught the idea to implement knowledge.
>> This program is for sale for fifty bucks.
>> Perhaps by including all of this information I will induce
>> people to send Mr. Diepeveen fifty bucks and order his
>> program. If so, great. Everyone who has written a
>> program should get the occasional check for fifty bucks.
>> However, that is not the intent of this post.
>Too bad :) I was going to post my bank account number :)
Aren't there some games in the million base you could try to ask
money for? :)
>[ snip ]
>
>> If you have such a suite, please publish it here, along with
>> Diep's time to solve, principle variation, and score, as I
>> would like to begin to independently verify your claim.
>>
>> If you have some other means of substantiating your claim,
>> please publish it.
>
>I want to see that data as well.
I'll work on it, but it is for sure that before i have a reasonable
collection of positions this will take some time.
I however forget how suspicious most people are, and simply didn't
think of the idea to put it on my homepage (the homepage is quite new).
This will be corrected.
>> If you do not wish to substantiate your claim, don't you
>> think it is wrong to make such a claim, especially in a web
>> page that is essentially an advertisement?
>This page is just another proof that most chess players cannot write
>chess programs and stay objective. They fall in love with their program
>and make claims which they cannot back up with hard data.
I can make it hard, and i don't have any competition. No other efford
i have heard of uses the same way to approach chess.
> I have seen
>this before, but Vincent is adding insult to injury by making public
>claims of superiority over the rest of the gang.
Stop! i don't claim superiority at tournament level at the time.
Nor do i claim that diep has a good book, a good time division,
or any good working learning
functions (all my learning experiments failed i'm afraid), nor
do i claim that the current version is that well in endgame.
> If Diep is superior by
>any definition of competitivness, fine, prove it, Bruce wants to listen,
>so do I. The standings of the last ODCC are clearly showing that using
>the common definition of competitivness Diep is absolutely at the low
>end.
Ok. The slow hardware should be no problem. You ever played against
travelmaster with your program?
>I think this whole issue is about the definition of playing strength
>again... As I often said knowledge is just a piece of the puzzle,
>everybody who denies this is no practioneer.
For this reason i also try to search deeply, implement time division,
hashtables etc.
Knowledge is not holy, but not having knowledge and claiming to be
at the level of Kasparov is even worse.
I am still surprised that although there are some programmers having
a reasonable insight in the game, they didn't try to implement chessknowledge.
When i began programming chess,
I saw clearly that the programs were very strong at certain points,
but that they missed 3 key elements to reach the top.
a) chessknowledge
b) intelligence
c) strategic insight / horizon problem
Diep is exactly the same like other programs, in this respect
that my evaluation function, so the covering of point a) is larger,
and i try to make it larger and better, where most chessprogrammers
don't try to make it any larger, or lack the chessknowledge to do this.
i guess that the main problem programs have is the lack of
intelligence. I am prepared to state that i don't think
computers will ever have intelligence in the way a human has,
despite the effords of all the intelligent researchers.
I also have never seen evidence for this, something very different from
my claim, simply look at the move Diep produces. Take a paper how many
good moves it plays, compare it to other programs, and voila.
c, the horizon problem will remain as long as we don't have a database
so big to look up all chesspositions.
I wouldn't want to make a bet that the final result of the game is draw
however. In the game of draughts i am prepared to make such a bet.
1 queen up doesn't mean you win, even 1 queen against 3 queens is a draw.
Easy bet. I just am not able to prove it.
Chess is in this respect more complicated. Just 1 pawn left
is usually enough to win. Also zugzwang is hard. Within 20 years
we could know more... ...white begins and Diep wins? :)
>-- Peter
Tom C. Kerrigan
This is in response to Vincent's first post to this thread (or at least
the first one I got). I don't feel like quoting the entire mess.
Vincent: Looks to me like you defined your own competition and declared
yourself the winner. Well, turns out I'm taking the same approach to
computer chess. Surprise! Now you have some competition. Prove that you're
better than I am before you say you're the best. Or maybe your next post
should read, "I write the best program named Diep."
Cheers,
Tom
brucemo
Marcel van Kervinck wrote:
>
> Robert Hyatt (hy...@cis.uab.edu) wrote:
> > If you don't execute moves at the last ply, then they can't be added to the
> > node count. The current definition of a node is either the number of calls
> > to Search()/Quiesce or the number of calls to MakeMove()... they should be
> > exactly the same...
>
> No need for that. It's very convenient to check for illegal moves
> just after MakeMove and just before the recursive call. Further,
> more important: consider the next trees searched in two succesive
> iterations:
[diagram snipped to satisfy my provider's lust for new text]
> There are definitely 4+10=14 nodes searched here. And only 12 MakeMoves.
>
> Seems you are not counting the root nodes as a nodes. Why's that?
Bob made a mistake.
Also, I think you could probably count those failed check-test moves as nodes,
as long as if you WOULD have recursed into "search" if they hadn't left you in
check.
The reason is that I think it makes sense for you to be able to count anything
you would be able to count in a "natural" implementation, and this is one of
those things.
Another would be if you checked the hash table before you actually recursed
into "search". I think you should be able to give yourself credit for cutoffs
there, too.
I don't do either of these things in my program, though, one increment
statement is enough, I just want to get a vague clue how fast the thing is
going.
bruce
Marcel van Kervinck
Robert Hyatt (hy...@cis.uab.edu) wrote:
> It's better to get to the next ply, generate
> moves, capture the king, and realize that the previous move was illegal,
> because this doesn't happen often *except* if the king was in check at the
> beginning position of the last ply.
In my program, I make a move and I know instantly it leaves the
king in check, due to sufficiently updated attack tables.
move.b enemy+pieces+0(sp),d1 ;load king location in d1
tst.w friend+attack(sp,d1.w) ;any attack on that square?
bne.s .illegal ;if so, it's illegal
Hard to squeeze anything out by moving detection to the next
ply. Let's see what would happen in my program:
- some statistics are updated
- the transposition table is probed
- a test is made to see if we are in check (for the side to
move! not the side that just moved)
- if yes: we generate legal escapes. It might happen that
the needed king-capture does not appear in the generated
list, however, so have have to add some messy kludge here.
(Consider the King has just moved next to the other King, and
happens to sit on on a defended square. My generator won't
generate KxK, as that would be 'illegal', right?). But adding a
workaround here probably doesn't harm performance too much.
- if no: do a very quick evaluation. (material, known endgames,
bishop-pairs, full pawn-evaluation, king-shelter, weak/strong
knights, mobility, and all other trivial evaluation terms)
- if depth==0, and possibly cut by the alpha-beta-window,
complete a full evaluation (basicly by probing dynamicly computed
piece/square tables and evaluation of attacks on pieces)
- the scoring table is loaded with the hashtablemove, killermoves
and countermoves.
- finally the captures are generated.
Only after that we might know if the previous move was illegal.
I guess I'll keep the 3 instructions for a while to test legality.
> 1. checking for illegal movs is generally bad, because most moves are
> legal and the test is wasted.
I conclude that 'generally bad' just means 'bad in Crafty'.
> In Crafty, when in check, I have a
> special move generator that only generates legal moves (easy to do with
> bitmaps at hardly any cost)... If you are in check, it's probably good to
> not call search recursively before legality checking, because most moves will
> obviously be illegal and the cost is higher.
I do have a legal-move-only generator for getting out of check, as
explained above.
> : * *
> : / \ / \
> : * * * *
> : | / \ / \
> : * * * * *
> : | / \
> : * * *
> : There are definitely 4+10=14 nodes searched here. And only 12 MakeMoves.
> : Seems you are not counting the root nodes as a nodes. Why's that?
> Because those positions are not searched. The root position is given to the
> search routine with the instructions "find the best move". That position is
> *not* searched. The successor positions are searched...
> Remember the definition
> of a position that most everyone uses is a *new* position, which can only be
> created by making a move in an old position.
For some reason chess-people think it has something to do with the
laws of chess. Do you stop counting below a null move? Also, not only
the root gets searched twice. With your definition you probably
also don't count positions that are found in the transposition
table. 'Those aren't new positions'. And finally: what do you do
after a PVS-fail-high that causes a research? From the above we
conclude that you unmake and remake the same move, before you
call the search with an adjusted window. Doesn't seem practical.
But if you want to keep the call-search-for-any-non-root-position-count
and makemove-count equal, you have no option.
In short: counting makemoves is a poor way of counting nodes.
I don't know why your above definition makes any sense. We are
searching trees here. Graph-theory very clearly defines what is
a node and what isn't.
Regards,
Jouni Uski
>
> I will this evening run the win at chess 300 test at the current
> version of Diep. i will publish it tomorrow. I will not make the
> announced compare with the nullmove turned off. After few positions
> already i saw enough: nullmove gives so terribly much that testing
> without nullmove simply takes me too much time.
>
> Previous version solved 297 win at chess positions. If i remember well,
> there were 3 positions where it needed between 3 and 10 minutes to
> solve a position, and the rest of the 294 positions were solved within
> that time. Most of these 294 positions were even solved within 10 seconds.
>
What are the best results in WAC testsuite now? For comparison Mchess 6
solved 298 in my 486/80Mhz in 10 min time limit!!
Jouni
Robert Hyatt
Marcel van Kervinck (mar...@stack.nl) wrote:
: Robert Hyatt (hy...@cis.uab.edu) wrote:
: > If you don't execute moves at the last ply, then they can't be added to the
: > node count. The current definition of a node is either the number of calls
: > to Search()/Quiesce or the number of calls to MakeMove()... they should be
: > exactly the same...
: No need for that. It's very convenient to check for illegal moves
: just after MakeMove and just before the recursive call. Further,
: more important: consider the next trees searched in two succesive
: iterations:
1. checking for illegal movs is generally bad, because most moves are
legal and the test is wasted. It's better to get to the next ply, generate
moves, capture the king, and realize that the previous move was illegal,
because this doesn't happen often *except* if the king was in check at the
beginning position of the last ply. In Crafty, when in check, I have a
special move generator that only generates legal moves (easy to do with
bitmaps at hardly any cost)... If you are in check, it's probably good to
not call search recursively before legality checking, because most moves will
obviously be illegal and the cost is higher.
: * *
: / \ / \
: * * * *
: | / \ / \
: * * * * *
: | / \
: * * *
: There are definitely 4+10=14 nodes searched here. And only 12 MakeMoves.
: Seems you are not counting the root nodes as a nodes. Why's that?
Because those positions are not searched. The root position is given to the
search routine with the instructions "find the best move". That position is
*not* searched. The successor positions are searched... Remember the definition
of a position that most everyone uses is a *new* position, which can only be
created by making a move in an old position. In your example, the two nodes
at the top are the same position, and no move was made to reach them in the
current search... However, if you do a 10 ply search, you would only add
10 nodes total to the search, 1 for each iteration for the position you didn't
search in reality... more semantics than anything else, and counting the root
or not won't change anything by the time you get to 10M nodes... :)
Robert Hyatt
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
: >This is not *directly* related to the thread topic, but I think a few
: >people might find it interesting.
: >
: >Vincent has recently claimed 700,000 non-quiescence-search nodes per
: It was an experiment just to see how fast a program can be, and
: how speed changes when you search deeper.
: Fact is that we (Bart Weststrate and i) used minimax in the beginning.
: And a very very very very limited q-search. Just at maximum 1 recapture.
Do you really mean pure minimax or minimax+alpha/beta? pure minimax is
known to be very fast in nodes searched per second, because there is no
pruning at all... However, it's not useful for chess of course, because
the depth is a tad too low... :)
: In C i got 350,000 nodes a second using watcom c 10.0
: Bart looked to the code and thought it was easily to rewrite to assembler,
: as there were a lot of silly things the compiler outputted.
: Of course NO hashtable, no move ordering, no evaluation function, just
: incremental piece-square tables and material.
: This is quite easy. How many moves can you generate a second?
: 2 million on a P5/100?
: Well at least that is the number of moves my generator can handle in C.
: Fritz' generator is even faster (incremental).
: Then i implemented alfabeta, and killermoves. Alphabeta by the way slows
: down search speed considerably, so does a deeper search. Speed by then
: was around 150,000 - 250,000 nodes a second in C.
Sounds reasonable at this point...
: Then i implemented hashtable. Not yet transposition, just 32 bits
: tuples from which 16 bits hashing and 16 bits for best move.
: This considerably slowed down search again. to about 115,000 up to 150,000
: in complex middlegame. Why is that so hard to believe?
That's not a difficult to swallow number... 700,000 was...
: How many nodes a second do you search? What do you do in q-search?
: I did very little in that program. At maximum 1 recapture. None preferably.
: Later i changed this to 2 recaptures (or king capture). This worked
: far better. Giving better scores, but considerably slowed down search.
: Perhaps you should profile your q-search?
: To go back to Diep: Diep spends 5-15% of all nodes in his q-search.
: In Diep i count the number of nodes spent in q-search to the number of
: nodes spent in alfabeta to get the number of total nodes. In the
: experimental program i didn't do this. Eats too much system time, an doesn't
: give you the real speed of your program. It just gives the speed of
: your capturelist() function :)
Are you counting depth=0 nodes in the basic search or as q-search nodes. That
is at the last ply where you look at all nodes (depth=1) from each of these positions
you reach a node where you can stand pat or try a capture. These are technically
q-search nodes, and there is one of them (at least) for every move searched at
depth=1. This can't possibly be only 15% of the total search, because if you look
at a tree, the last full-width ply has a much larger percentage of the trees moves
than this.. typically at least 5x the number of nodes as at the previous ply...
This trips up comparisons from time to time... I like the definition "if, at the
current ply, I can stand pat or search deeper, whether I search a capture, a check,
or some other move, then this node is a quiescence node, because normal alpha/beta
doesn't tolerate standing pat in the base search..."
: >second on a p5/100 if he takes a lot of stuff out of his program. BTW, he
Robert Hyatt
Stefano Gemma (stefan...@spiderlink.it) wrote:
: Tom C. Kerrigan <kerr...@merlin.pn.org> scritto nell'articolo
: <5brf40$a...@merlin.pn.org>...
: > This is not *directly* related to the thread topic, but I think a few
: > people might find it interesting.
: >
: > Vincent has recently claimed 700,000 non-quiescence-search nodes per
: > implies that this particular program has no move ordering.
: The better i can do is 25,248,151 moves in 12 seconds on a P133, equal to
: 734,676 nodes/12 seconds (from the starting position at 8 plyes with
: nega-max-like alg.). I evaluate any of those moves, counting only square
: values and mobility and doing selection sort. I don't optimize the last
: ply, because i generate, execute and roll-back any moves even at those ply.
: So i reach "only" 61,223 nodes/second. Supposing to not execute moves at
: the last ply, but just to evaluate them, maybe this value can be multiplyed
: by a factor of 10? I think yes, for just a mathematical reason. Mine is an
: assembly program, i have these routines:
: Generate move : about 20 assembly istructions per moves (with a simple
: evaluation)
: Selection sort: a loop of about 10 istructions per move
: Execute move : 21 istructions per move
: RollBack move : 17 istructions per move (this routine undo moves)
: AlfaBeta alg. : about 10 istructions per move
: Supposing 1 cycle per istruction and 35 moves per node, the selection sort
: takes about 10*(35/2)=175 cycles. If we execute all the moves at the last
: ply:
: Generate : 35*20 = 700 cycles
: Selection: 35*175=6125 cycles
: Execution: 35*21 = 735 cycles
: RollBack : 35*17 = 595 cycles
: AlfaBeta : 35*10 = 350 cycles
: -----------------------------
: 8505 clock cycles per node
: 8505cycles/node * 734676nodes / 133000000cycles/second = 46 seconds
: This confirm my 12 seconds, because i have done a lot of approximation and
: i don't consider pruning. Supposing to not execute moves at the last ply,
: we needs only:
If you don't execute moves at the last ply, then they can't be added to the
node count. The current definition of a node is either the number of calls
to Search()/Quiesce or the number of calls to MakeMove()... they should be
exactly the same...
There are also some major omissions in the above if it is going to be a legitimate
chess player. It doesn't recognize repetitions, it doesn't include any hashing.
What about maintaining the PV? Checking the time every so often? And so forth.
Most of us are interested in the speed at which someone can play real chess. With
no hash table, your move ordering is going to be inferior, making your tree much
larger.
If you generate all moves first, which most programs do, and then get lots of
cutoffs from good move ordering, the above rate will shrink quickly, because you
invest the time to generate moves (slow) but then don't get to search them
(which is fast) therefore driving the time to generate a single move way up...
Robert Hyatt
: > It's better to get to the next ply, generate
: > moves, capture the king, and realize that the previous move was illegal,
: > because this doesn't happen often *except* if the king was in check at the
: > beginning position of the last ply.
: In my program, I make a move and I know instantly it leaves the
You are basically doing what I did early on in Crafty, which is incremental
updating for the attacked squares. In this case, what you are doing is
obviously the right thing. However, the incremental update might not be
best, as I certainly got faster when I canned it, because many times the
stuff that is updated isn't used....
: Only after that we might know if the previous move was illegal.
: I guess I'll keep the 3 instructions for a while to test legality.
: > 1. checking for illegal movs is generally bad, because most moves are
: > legal and the test is wasted.
: I conclude that 'generally bad' just means 'bad in Crafty'.
no... this applies to most any program... Cray Blitz was not a bitmapper
yet still used this optimization. *any* test takes time. And in 99.9% of
the positions it's wasted. Question is, do you save more in those .1% by
doing the test, or do you lose more in the 99.9% by doing the test. In both
of my cases, it was a win to defer the test. Not a huge win, mind you, but a
win...
: > In Crafty, when in check, I have a
: > special move generator that only generates legal moves (easy to do with
: > bitmaps at hardly any cost)... If you are in check, it's probably good to
: > not call search recursively before legality checking, because most moves will
: > obviously be illegal and the cost is higher.
: I do have a legal-move-only generator for getting out of check, as
: explained above.
: > : * *
: > : / \ / \
: > : * * * *
: > : | / \ / \
: > : * * * * *
: > : | / \
: > : * * *
: > : There are definitely 4+10=14 nodes searched here. And only 12 MakeMoves.
: > : Seems you are not counting the root nodes as a nodes. Why's that?
: > Because those positions are not searched. The root position is given to the
: > search routine with the instructions "find the best move". That position is
: > *not* searched. The successor positions are searched...
: > Remember the definition
: > of a position that most everyone uses is a *new* position, which can only be
: > created by making a move in an old position.
: For some reason chess-people think it has something to do with the
: laws of chess. Do you stop counting below a null move?
Nope. The null move is a move, and produces a new position, because a
different side is now on move.
: Also, not only
: the root gets searched twice. With your definition you probably
: also don't count positions that are found in the transposition
: table.
I make a move at ply=n, increment ply, call search, count the node, do a
LookUp() and if I hit, I return. It was counted, but the stuff that LookUp
saved isn't counted because I have no idea how much that saved...
: 'Those aren't new positions'. And finally: what do you do
: after a PVS-fail-high that causes a research? From the above we
: conclude that you unmake and remake the same move, before you
: call the search with an adjusted window.
No. When PVS fails high, I simply relax beta and call search again. It
will count the position a second time, even though there was no make/unmake
cycle... These additions are "noise" in the largeer scheme of counting all
the nodes searched. Fail highs are rare in the search overall... I even use
internal iterative deepening when a PV node has no hash move to try, and that
will also fudge the count a couple of moves since the same position is searched
several times, at successively deeper depths (within the tree) to get a better
move for searching to the real target depth.
: Doesn't seem practical.
: But if you want to keep the call-search-for-any-non-root-position-count
: and makemove-count equal, you have no option.
: In short: counting makemoves is a poor way of counting nodes.
: I don't know why your above definition makes any sense. We are
: searching trees here. Graph-theory very clearly defines what is
: a node and what isn't.
But graph theory doesn't have transpositions, researches, different trees
where the graph is mysteriously extended in places, and reduced in others
as the null move and other search strategies do. And it doesn't address
the issues of cyclic graphs which chess has, cycles that can appear and
vanish depending on what's in the hash table...
The idea is simply to produce a very accurate approxmiation of the size of
the tree searched. Not to produce an exact node count. The node count has
nothing to do with the goal of the program... just gives a close estimate of
the work done to make a move...
: Regards,
Joe Stella
hy...@cis.uab.edu (Robert Hyatt) wrote:
>Are you counting depth=0 nodes in the basic search or as q-search nodes. That
>is at the last ply where you look at all nodes (depth=1) from each of these positions
>you reach a node where you can stand pat or try a capture. These are technically
>q-search nodes, and there is one of them (at least) for every move searched at
>[...]
The depth=0 nodes seem to be a special case. That's why I count them separately,
as "leaf" nodes. In other words, I have:
1) Search calling search -> search_node
2) Search calling quies -> leaf_node
3) Quies calling quies -> quies_node
So total_nodes is the sum of the three.
I think this is useful for two reasons:
1) Comparing the leaf node number for ply n with the number for ply n+1 gives
you the best estimate of your program's branching factor (I am talking about
iterarive deepening here)
2) The ratio quies_node/leaf_node gives you the average size of your quies
search per node. In other words, I hand a position to my quies search and I
want to know, how many nodes does it take before this position is resolved and
the score is returned?
I haven't seen anyone else doing this and I wonder why -- It seemed natural enough
to me...
Joe Stella
jo...@ultranet.com
Tom C. Kerrigan
I don't have this post yet. Guess I'll have to make do with the quote...
> Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
> : This considerably slowed down search again. to about 115,000 up to 150,000
> : in complex middlegame. Why is that so hard to believe?
Because Schach 3, running entirely out of L1 cache, searches some 80k
"conventional" (I assume) nodes/sec. At least you're in the right ballpark
now, though. Sort of. It still sounds like you're claiming to count two
"conventional" nodes as one. Is it so hard to admit that you pulled 700k
out of your ass?
> : I did very little in that program. At maximum 1 recapture. None preferably.
What the hell kind of search is it when you only search one move? I search
captures that are deemed non-losing by my SEE. When I'm in check, I try
all responses. This is basically how everybody I've ever talked with does
it, too. Except you. I have no idea how you're doing it.
> : In Diep i count the number of nodes spent in q-search to the number of
> : nodes spent in alfabeta to get the number of total nodes. In the
> : experimental program i didn't do this. Eats too much system time, an doesn't
> : give you the real speed of your program. It just gives the speed of
> : your capturelist() function :)
Woah! The speed of your capturelist() function?? Please don't tell me you
count every move you generate as a "node"!
> : YOU MUST DEBUG YOUR Q-SEARCH AND PROFILE IT.
A lot of nerve you have, telling me where my bugs are.
My program agrees with a ton of other programs. Are you saying we all have
the same bug? Why do you assume that you're right and I'm wrong?
Arrogance, is my guess.
> : >Anyway, it seems that Vincent is a better programmer than I am by a factor
> : >of around 500...
> : Should i tell you how many nodes this program gets on my PP200?
> : multiply it by 3... :)
> : 1500 times better?
Oh, and I don't get to run on the faster machine? Sometimes being a
wise-ass backfires, doesn't it?
Cheers,
Tom
Peter W. Gillgasch
Vincent Diepeveen <vdie...@cs.ruu.nl> wrote:
> In <199701172325111208482@[194.121.104.138]> gil...@ilk.de (Peter W.
> Gillgasch) writes:
>
> >brucemo <bru...@nwlink.com> wrote:
> >
> >> Here is the first paragraph of that web page:
> >>
> >> "Diep is without doubt the strongest chess analysis program
> >> in the world at infinite level (few hours a move). The
> >> longer you allow it to analyse the better the move it will
> >> produce, something which is uncommon for most other
> >> chessprograms, caused by the enormeous chessknowledge in
> >> Diep, which is at the time still considerably growing every
> >> month (and decreasing the Diep searchspeed)."
[ snip ]
> >My conclusion is that Diep is a design failure. I don't see the point
> >why it should be interesting to write a program that needs a significant
> >edge in time / machine power to be competitive. In other words, it is
> >not competitive at all.
>
> Stop!
>
> Why not giving me also 10 years to become stronger at
> tournament level?
I am not trying to put your efforts down, but claiming *anything* based
on "I need more horsepower" is simply rubbish. Before you don't have
anything to report (and that means before you can safely enter a tourney
and have hopes for beig in the middle of the pack) it is better to claim
*nothing*... For example I could claim some weird stuff now (and I am
sure that I will pull it off) but until...
And if you need more than, say, 3 years to get up to a certain standard
you will probably never reach it because you are sitting in the wrong
train....
> I think that a chess program first should SEE a move, then it is
> a simplistic transformation of the search process and or program
> speed to allow the program to see that move within tournament level.
I don't think so, but since this is a religious issue I shut up :)
> Especially in my draughts program i have the problem in the other
> way.
>
> The draughtsprogram manages to search between 21 to 30 ply in middlegame
> after an overnight thinking, but still doesn't see moves Tsjizow/Sijbrands
> play. Don't mean combinations. knowledgebased moves. little more knowledge
> could do the job, but i don't see how.
>
> In the chessprogram, as i know a lot about chess, and little about draughts,
> i didn't want to write the 30th fritz.
There is no 2nd Fritz. Speedwise there is a big gap between the rest of
the pack and Fritz.
> Personally, without wanting to
> insult anyone, a lot of chessprograms that are on the market, or made
> by amateurs look, independant programmed from each other, a lot
> like each other. They get a penalty for every free pawn, a bonus
> for having the bishop pair. The better they play, the more the moves
> they play and the faults they make look like each other.
Right.
> Of course Diep also had this problem. This is what i wanted to prevent.
> a program like the other 30. I try to make a program that in the first
> place must have the right knowledge (as much as possible)
> In the second place i also try to search as deeply as possible.
>
> At first this resulted in a poor search depth. Current version still
> is slower than most other programs, but searches at a depth i am not
> ashamed for.
8 plies in a split second on low end hardware ?
> >Evaluation can help a lot, so can searching. We know that. The
>
> I want to go for the combination of the both.
So do I.
[ tactical mistakes a class 'C' player can spot ]
> Well, the berlin pro i don't have, nor do i have any other hardware computers.
> I sold mine as soon as i got a 386 computer. That was in 1988.
>
> Something i call a slow hardware program, from which i think it a nobelprice
> worth that the programmer in the first place managed to get a chessprogram
> working in so little memory:
Right. But this unit is really at the very low end. A comparision with
the Berlin would be interesting since this machine is rated above 2,200
ELO. Alternatively some Kittinger program may do.
> Thanks to Fernando Villegas Darrouy who played the game
[snip]
This game is not very interesting. Basically black is already dead after
5 moves...
> What i try to make clear is that although currently the hardware has
> become stronger commercial programmers still don't
> caught the idea to implement knowledge.
Hold it. There are about three "types" of programs out there:
(1) fast searchers (Fritz, WChess, maybe Nimzo). Those need a laundry
machine chip.
(2) positional tactictians (The King, Genius, Hiarcs, MChess etc). Those
need a "real" computer.
(3) positional couch potatoes (most academic programs). Those programs
are weak and/or need fat machines.
If you start with a (3) type programs you are stuck there. Nothing will
ever bring you to (1) or (2).
> >> Everyone who has written a
> >> program should get the occasional check for fifty bucks.
> >> However, that is not the intent of this post.
>
> >Too bad :) I was going to post my bank account number :)
>
> Aren't there some games in the million base you could try to ask
> money for? :)
Can I claim DarkThought's games ? Don't want to. DarkThought is an
entity of its own, unfortunately he cannot ask for money...
[ snip ]
> >I want to see that data as well.
>
> I'll work on it, but it is for sure that before i have a reasonable
> collection of positions this will take some time.
>
> I however forget how suspicious most people are, and simply didn't
> think of the idea to put it on my homepage (the homepage is quite new).
>
> This will be corrected.
I think I recall that I have read that stuff a couple of months ago
already.
> I can make it hard, and i don't have any competition. No other efford
> i have heard of uses the same way to approach chess.
Don't think so. I can't see any difference to some academic programs.
> > I have seen
> >this before, but Vincent is adding insult to injury by making public
> >claims of superiority over the rest of the gang.
>
> Stop! i don't claim superiority at tournament level at the time.
> Nor do i claim that diep has a good book, a good time division,
> or any good working learning
> functions (all my learning experiments failed i'm afraid), nor
> do i claim that the current version is that well in endgame.
Well you said that "without a doubt" you are the best at long time
controls, or no time controls at all... You claim superiority on the
knowledge axis. Still I don't see any basis for that claim. You did
claim that, right ? Where is the proof of the pudding ?
> > If Diep is superior by
> >any definition of competitivness, fine, prove it, Bruce wants to listen,
> >so do I. The standings of the last ODCC are clearly showing that using
> >the common definition of competitivness Diep is absolutely at the low
> >end.
>
> Ok. The slow hardware should be no problem. You ever played against
> travelmaster with your program?
Nope. Don't have the Travelmaster.
> >I think this whole issue is about the definition of playing strength
> >again... As I often said knowledge is just a piece of the puzzle,
> >everybody who denies this is no practioneer.
>
> For this reason i also try to search deeply, implement time division,
> hashtables etc.
>
> Knowledge is not holy, but not having knowledge and claiming to be
> at the level of Kasparov is even worse.
Right, but folks who select Kasparov as a target are megalomaniac doomed
to failure types anyway.
> I am still surprised that although there are some programmers having
> a reasonable insight in the game, they didn't try to implement chessknowledge.
Eh. I can show you some guys who try... Dozens of them. Your definition
of knowledge seems to be significantly "different" from mine...
> When i began programming chess,
> I saw clearly that the programs were very strong at certain points,
> but that they missed 3 key elements to reach the top.
> a) chessknowledge
Ok.
> b) intelligence
Big word meaning nothing.
> c) strategic insight / horizon problem
Strategic insight is chess knowledge. Horizon problems are speed
problems.
> Diep is exactly the same like other programs, in this respect
> that my evaluation function, so the covering of point a) is larger,
> and i try to make it larger and better, where most chessprogrammers
> don't try to make it any larger, or lack the chessknowledge to do this.
Maybe they lack the knowledge, true. But there are trade off decisions,
and maybe the "programmer types" prefer speed over knowledge because
they understand this effect better than the effect of knowledge. Speed
always helps. Knowledge can help. Sometimes.
> i guess that the main problem programs have is the lack of
> intelligence. I am prepared to state that i don't think
> computers will ever have intelligence in the way a human has,
> despite the effords of all the intelligent researchers.
Don't know. If this ever happens it will mean that our intelligence is
no real asset. Philosophical issue. Let's skip that.
> I also have never seen evidence for this, something very different from
> my claim, simply look at the move Diep produces. Take a paper how many
> good moves it plays, compare it to other programs, and voila.
Well, what is a "good" move ? My way of determining "goodness" is a
combination of gut feeling and computer assistance... Hence I prefer
test games between machines. No "voila" in your case, I am afraid.
> c, the horizon problem will remain as long as we don't have a database
> so big to look up all chesspositions.
Huh ? If you have this you don't need any knowledge :)
> I wouldn't want to make a bet that the final result of the game is draw
> however. In the game of draughts i am prepared to make such a bet.
> 1 queen up doesn't mean you win, even 1 queen against 3 queens is a draw.
> Easy bet. I just am not able to prove it.
> Chess is in this respect more complicated. Just 1 pawn left
> is usually enough to win. Also zugzwang is hard. Within 20 years
> we could know more... ...white begins and Diep wins? :)
Black wins. That's for sure 8^)
-- Peter
May God grant me the serenity to accept the things I cannot change,
courage to choke the living shit out of those who piss me off,
and wisdom to know where I should hide the bodies...
Stefano Gemma
Robert Hyatt <hy...@cis.uab.edu> scritto nell'articolo
<5c2kvf$g...@juniper.cis.uab.edu>...
> Stefano Gemma (stefan...@spiderlink.it) wrote:
> : Tom C. Kerrigan <kerr...@merlin.pn.org> scritto nell'articolo
> : <5brf40$a...@merlin.pn.org>...
>
to
> : 734,676 nodes/12 seconds (from the starting position at 8 plyes with
> : nega-max-like alg.). I evaluate any of those moves, counting only
square
> : values and mobility and doing selection sort. I don't optimize the last
> : ply, because i generate, execute and roll-back any moves even at those
ply.
> If you don't execute moves at the last ply, then they can't be added to
the
> node count. The current definition of a node is either the number of
calls
> to Search()/Quiesce or the number of calls to MakeMove()... they should
be
> exactly the same...
I don't use a recursive call to Search, as C programs does.
Here's my Search+AlfaBeta loop (i traduct only the most important remark).
The "...comment..." are set of istructions, deleted from listing for
clarity.
****************************************************************************
***********
;---------------------------------------------------------------------------
----
; livelli=numero di livelli (number of levels)
; edi punta alle mosse (pointer to moves list)
; esi punta ai nodi (pointer to nodes list)
; ebp contiene il valore progressivo attuale (actual value)
; ebx contiene il valore della mossa (move value)
;---------------------------------------------------------------------------
----
AlfaBeta proc near
...registers initialization...
jmp AlfaBetaInizia
AlfaBetaMatto:
...save move index...
; AnnullaMossa = RollBack = undo last executed move
call AnnullaMossa ; annulla l'ultima mossa giocata
AlfaBetaTaglia:
cmp esi, offset nodi ; verifica che questo non sia il primo nodo
je ritorna_errore ; ***debug***
...previous ply...
call AnnullaMossa ; annulla l'ultima mossa giocata
PullMossa ; search for the best generated move
jnz AlfaBetaEsegui ; se le mosse non sono finite, le esegue
AlfaBetaUp:
...load node value... ; carica il valore del nodo attuale
AlfaBetaConfronta:
...previous ply...
call AnnullaMossa ; undo move
...check alfabeta...
jle AlfaBetaTaglia ; pruning
...check nod evalue... ;
jle AlfaBetaPull
...store move and value... ; this is the better move for this node
AlfaBetaPull:
PullMossa ; cerca la mossa migliore
jz AlfaBetaUp ; le mosse sono finite
AlfaBetaEsegui:
call EseguiMossa ; effettua veramente la mossa, ora ebp
contiene il valore
...some check...
test eax, BIT_RE ; test if it capture the king
jne AlfaBetaMatto ; check for mate or steale mate
AlfaBetaDown:
...next ply...
AlfaBetaInizia:
;***************************************************************************
; as you can see, i count nodes before to generate any of the last ply
moves
;***************************************************************************
inc nodi_elaborati <-------- here's the nodes counter
call Genera ; generates and evaluates moves
jc AlfaBetaDown ; jump if mate
cmp livelli,1 ; at last ply, check value without execute
move
jne AlfaBetaNonUltimo
AlfaBetaUltimoLivello:
mov edi,[esi.nMaxGenId] ; this is the pointer to the best generated
move
test edi,edi
je AlfaBetaTaglia ; there are no legal moves
mov ebx,ebp ; load position value (before the move)
add ebx,[edi.mValore] ; add move's value
add ebx,[esi.nMobilità] ; add node's mobility value
jmp AlfaBetaConfronta ; go back one ply, with this value
AlfaBetaNonUltimo:
...load initial node value...
jmp AlfaBetaPull
finite:
test eax,eax ; carry=0
ret
ritorna:
ret
AlfaBeta endp
****************************************************************************
***********
Maybe it is not very clean... but it is assembly-night-written :-).
The important thing to see, is that i count nodes before to generate the
last ply moves. I think this the correct way to count nodes, because:
1) from ply 1 to last-1, i count only moves that are played
2) i don't count last ply moves at all (neither executed nor non-executed)
For example, supposing to generate 10 moves per node and execute only 4
(because of alfa-beta pruning), in a 3 plyes search:
nodes=0
first ply
nodes=nodes+1 -> ply 1 -> generate 10 moves -> execute better one (4 moves
in this example)
next ply or go back
nodes=nodes+1 -> ply 2 -> generate 10 moves -> execute better one (4 moves
in this example)
next ply or go to ply 1
nodes=nodes+1 -> ply 3 -> generate 10 moves -> evaluate better one
go to ply 2
My program, in this situation, will count 1+4+16 nodes.
From the starting position, without alfa-beta, my program counts:
when searching up to plyes 2: 21 plyes
when searching up to plyes 3: 421 plyes
when searching up to plyes 4: 9323 plyes
when searching up to plyes 5: 207065 plyes
when searching up to plyes 6: 5087330 plyes in 65 seconds
You can easly compare this counting, just by disabling alfa-beta (NB: for
now i don't executes en-passant and castling, so you must disable even this
moves).
From the starting position, with alfa-beta, my program counts:
when searching up to plyes 2: 21 plyes
when searching up to plyes 3: 81 plyes
when searching up to plyes 4: 700 plyes
when searching up to plyes 5: 4091 plyes
when searching up to plyes 6: 25734 plyes
when searching up to plyes 7: 141905 plyes
when searching up to plyes 8: 969893 plyes in 15 seconds
Now it reach about 65000plyes/second. It don't play en-passant and castling
(but it will do the next week-end) but it play all the other legal moves,
even promotion and underpromotion.
> There are also some major omissions in the above if it is going to be a
legitimate
> chess player. It doesn't recognize repetitions, it doesn't include any
hashing.
This thing will make it faster, but they are not essential to be a
legitimate chess player. I give you a game played by itself at a depth of 6
plyes (i don't have enough time to try at 8 ply). I report any moves with
the nodes counter:
e2-e4 (25734) , d7-d5 (50757)
e4-e5 (63487) , e7-e6 (67872)
d2-d4 (71575) , d8-h4 (192831)
f1-b5 (125475), c7-c6 (41238)
b5-a4 (105724), f8-b4 (108444)
c2-c3 (17530) , h4-e4 (65453)
e1-f1 (40309) , b4-a5 (196303)
a4-c2 (216657), e4-h4 (85231)
g2-g3 (303965), h4-e7 (77708)
d1-g4 (354302), f7-f5 (143438)
g4-h5 (139559), g7-g6 (48434)
h5-g5 (116479), b8-d7 (95345)
f1-e2 (179839), e7-g7 (134450)
g1-f3 (415843), a5-d8 (261691)
g5-f4 (96428) , b7-b6 (349971)
c2-d3 (485666), b6-b5 (301739)
f3-g5 (350927), d7-b6 (115287)
b1-d2 (503410), b6-c4 (128099)
d3-c4 (215030), b5-c4 (78808)
maybe d3-c4 it is the most interesting move: it change a bad bishop for a
good knight, in a closed position... but i never told it this rule! This is
just "mobility value" at work... or just luck :-). Of course, the other
white bishop it is very very bad.
b2-b4 (706746), h7-h6 (262551)
g5-f3 (112343), g6-g5 (325672)
f4-e3 (68490) , a8-b8 (229981)
c1-b2 (264825), g5-g4 (338556)
f3-h4 (135486), a7-a5 (210331)
a2-a4 (208658), d8-g5 (152606)
f2-f4 (58313) , g5-e7 (63738)
b2-a3 (169078), a5-b4 (72147)
a3-b4 (62908) , e7-b4 (39093)
a1-b1 (101121), g7-a7 (90025)
h4-g6 (97898) , h8-h7 (43087)
b1-b4 (108830), b8-b4 (36335)
c3-b4 (65154) , h7-g7 (113806)
g6-h4 (74743) , a7-a4 (115518)
e3-c3 (130528), g7-b7 (354445)
h1-a1 (308809), a4-b5 (38966)
h4-g2 (120021), h6-h5 (150344)
g2-e3 (108594), h5-h4 (369658)
g3-h4 (107970), e8-f8 (317289)
h4-h5 (204978), g8-h6 (296942)
e2-f2 (157143), h6-f7 (299452)
a1-a8 (213467), b7-b8 (61821)
a8-b8 (61207) , b5-b8 (22843)
f2-g3 (249599), f8-g7 (157205)
c3-a3 (245693), b8-b6 (127483)
a3-c3 (105473), g7-h6 (151087)
g3-h4 (99595) , c8-b7 (97400)
h2-h3 (89668) , g4-h3 (71051)
h4-h3 (63387) , h6-h5 (73878)
h3-g3 (101761), h5-g6 (110080)
g3-f2 (140507), g6-g7 (123588)
f2-g3 (143765), f7-h6 (142383)
g3-f2 (154868), h6-g4 (119539)
e3-g4 (12044) , f5-g4 (39261)
f2-g3 (53216) , b6-b5 (50304)
g3-g4 (37062) , b5-a4 (50996)
g4-g3 (67731) , a4-d1 (72426)
g3-f2 (46543) , d1-g4 (78886)
c3-g3 (31633) , g4-g3 (2134)
f2-g3 (2705) , c4-c3 (8677)
d2-b3 (14057) , c3-c2 (9885)
b3-c1 (24891) , b7-a6 (6561)
g3-f3 (5154) , g7-g6 (6331)
f3-g4 (6304) , a6-b5 (2808)
f4-f5 (4341) , g6-f7 (1966)
g4-g5 (5619) , e6-f5 (2546)
g5-f5 (2042) , f7-e7 (2750)
e5-e6 (4698) , b5-f1 (2774)
f5-e5 (2216) , f1-h3 (4076)
e5-f4 (1487) , h3-e6 (3746)
f4-e5 (2740) , e6-c8 (4109)
b4-b5 (2291) , c8-d7 (3901)
b5-c6 (2397) , d7-c6 (2225)
e5-f5 (1492) , e7-d6 (2832)
f5-f4 (4002) , c6-d7 (5200)
f4-f3 (5645) , d7-f5 (8503)
f3-f4 (3011) , f5-e4 (3820)
f4-g4 (3606) , e4-g6 (2993)
g4-f4 (2624)
Ok, and now a repetition check would help :-)
> What about maintaining the PV? Checking the time every so often? And so
forth.
What is the PV?
> Most of us are interested in the speed at which someone can play real
chess. With
> no hash table, your move ordering is going to be inferior, making your
tree much
> larger.
Ok, but we were talking about the max speed reacheable, with the simplest
program. Obviously a program that play so bad it is not very interesting,
but because of its speed it is a good point to start from. When i will add
some extra evaluation features - like not to move queen and king in the
opening ;-) - obviously the speed will decrease but it is better to start
from a good speed and then decrease it, than start from a slow program and
slow it down more ;-)
> If you generate all moves first, which most programs do, and then get
lots of
> cutoffs from good move ordering, the above rate will shrink quickly,
because you
> invest the time to generate moves (slow) but then don't get to search
them
> (which is fast) therefore driving the time to generate a single move way
up...
This is too many complex for my poor english ;-). I already generate all
moves first and evaluate them (the Genera procedure generates and evaluate
moves, but don't execute them), so i already get a lots of pruning from
good ordering. As you can see, the nodes counter (in the orrible game that
i've reported) get lower when there are good moves and bigger when the
position it is not easy... and in this case... it develope a piece, because
it don't know anything else to do :-)
Maybe this message is too long, do i need some pruning? :-)
Ciao!
Robert Hyatt
Joe Stella (no_jun...@here.com) wrote:
: hy...@cis.uab.edu (Robert Hyatt) wrote:
: >Are you counting depth=0 nodes in the basic search or as q-search nodes. That
: >is at the last ply where you look at all nodes (depth=1) from each of these positions
: >you reach a node where you can stand pat or try a capture. These are technically
: >q-search nodes, and there is one of them (at least) for every move searched at
: >[...]
: The depth=0 nodes seem to be a special case. That's why I count them separately,
: as "leaf" nodes. In other words, I have:
: 1) Search calling search -> search_node
: 2) Search calling quies -> leaf_node
: 3) Quies calling quies -> quies_node
: So total_nodes is the sum of the three.
: I think this is useful for two reasons:
: 1) Comparing the leaf node number for ply n with the number for ply n+1 gives
: you the best estimate of your program's branching factor (I am talking about
: iterarive deepening here)
: 2) The ratio quies_node/leaf_node gives you the average size of your quies
: search per node. In other words, I hand a position to my quies search and I
: want to know, how many nodes does it take before this position is resolved and
: the score is returned?
: I haven't seen anyone else doing this and I wonder why -- It seemed natural enough
: to me...
: Joe Stella
: jo...@ultranet.com
I believe that Bruce and I both tried this at one time... but it was
different from what everyone else was doing and I went back to two
counters... one incremented in Search, one in Quiesce...
Robert Hyatt
Jouni Uski (Jouni...@semitechturku.com) wrote:
: >
: > I will this evening run the win at chess 300 test at the current
: > version of Diep. i will publish it tomorrow. I will not make the
: > announced compare with the nullmove turned off. After few positions
: > already i saw enough: nullmove gives so terribly much that testing
: > without nullmove simply takes me too much time.
: >
: > Previous version solved 297 win at chess positions. If i remember well,
: > there were 3 positions where it needed between 3 and 10 minutes to
: > solve a position, and the rest of the 294 positions were solved within
: > that time. Most of these 294 positions were even solved within 10 seconds.
: What are the best results in WAC testsuite now? For comparison Mchess 6
: solved 298 in my 486/80Mhz in 10 min time limit!!
: Jouni
Cray Blitz solves 299 in less than 5 seconds per move on a T90. It solves
297 in < 1 second... I don't have the log, but it takes something like 15
seconds to get #141 for some reason that I don't recall.
Crafty gets 296 correct in 1 minute or less on the P6/200...
Robert Hyatt
Peter W. Gillgasch (gil...@ilk.de) wrote:
: Hold it. There are about three "types" of programs out there:
: (1) fast searchers (Fritz, WChess, maybe Nimzo). Those need a laundry
: machine chip.
: (2) positional tactictians (The King, Genius, Hiarcs, MChess etc). Those
: need a "real" computer.
: (3) positional couch potatoes (most academic programs). Those programs
: are weak and/or need fat machines.
Hmmm... that would include Chess 4.x, HiTech, Belle, Cray Blitz, Dark
Thought, *Socrates, and many others. I don't see what the "most academic
programs" has to do with your statement above??? Several of those are *not*
"positional couch potatoes"... HiTech can hand you your head in a sack
positionally most of the time... As can some of the others...
: If you start with a (3) type programs you are stuck there. Nothing will
: ever bring you to (1) or (2).
You lost me here...
: Right, but folks who select Kasparov as a target are megalomaniac doomed
: to failure types anyway.
And there too...
brucemo
Jouni Uski wrote:
> >
> > I will this evening run the win at chess 300 test at the current
> > version of Diep. i will publish it tomorrow. I will not make the
> > announced compare with the nullmove turned off. After few positions
> > already i saw enough: nullmove gives so terribly much that testing
> > without nullmove simply takes me too much time.
> >
> > Previous version solved 297 win at chess positions. If i remember well,
> > there were 3 positions where it needed between 3 and 10 minutes to
> > solve a position, and the rest of the 294 positions were solved within
> > that time. Most of these 294 positions were even solved within 10 seconds.
> >
>
> solved 298 in my 486/80Mhz in 10 min time limit!!
I usually get 296-297 in a minute or so. A few of them are real stumpers for
me, including position 141, which some other programs solve very quickly. It
takes Ferret ages to solve this.
On the positive side, it gets position 2 very quickly, some other programs
take hours.
About 281 in 10 seconds, P6/200, by the way.
bruce
brucemo
Robert Hyatt wrote:
> no... this applies to most any program... Cray Blitz was not a bitmapper
> yet still used this optimization. *any* test takes time. And in 99.9% of
> the positions it's wasted. Question is, do you save more in those .1% by
> doing the test, or do you lose more in the 99.9% by doing the test. In both
> of my cases, it was a win to defer the test. Not a huge win, mind you, but a
> win...
In my case it was a win to make the test, in most cases.
For a lot of folks it won't be hard to check it either way.
bruce
brucemo
Vincent Diepeveen wrote:
> Well, diep solves much more positions for example from the Nolot
> positions, although this is just a tactical test.
>
> Ain't that enough?
Assuming it's true, it isn't enough, because it is a tactical test, and it
provides no substantiation for your claim the Diep's positional strength curve
eventually crosses the curve of every other program.
I think that perhaps it is not true, though.
Tacked on to this are my results from the Nolot suite. I include PV's at the
point at which it found (and held) the solution move, and PV's in subsequent
plies in some cases.
I have a copy of the post in which you first discussed this suite. It is hard
to determine exactly what you claim in that post, but I think you are claiming
the following:
1) 10 plies, 51 minutes, unknown score, unknown PV.
4) You made mention of 18 plies, but you also mentioned that you didn't get the
answer, although it was close. So I don't know if you missed it in 17 plies but
thought you'd get it in 18, or what.
10) 10 plies, 10 minutes, unknown score, unknown PV.
11) You claimed that you'd get this in 13 plies, but only made mention of Diep
getting through 11 plies in 10 minutes, so I don't know if you actually
performed the search.
So it sounds like you got 2, maybe 3, and you felt like you could tune for a few
more.
I discount the idea of tuning to get these. I did not tune for these and won't
tune for them in the future.
My own program is pretty generic, but as you can see from my attached results,
it is capable of solving four of them at least, the longest solution taking 24
hours on a P6/200 and the shortest solution taking 14 minutes. Judge the
solutions for yourself. Some of the scores are unconvincing, but in each case
it got most or all of the lines mentioned in Baudot's original article.
So given my own program as a counter-example, I don't see that your claim that
your program solves "more positions" is substantiated, but your claim is very
vague, so perhaps I am misunderstanding it.
Perhaps you could provide PV's, scores, and times, as I have done?
bruce
----------------
Position 1:
PV 01:56:21.248 13 -93 [right] Nxh6
PV 02:31:03.632 13 -67 [right] Nxh6 c3 Nf5 cxb2 Qg4 g6 Kh2 Qd7 Nh4 Kg8 Nxg6
Bg7 Nf6+ Nxf6 Qxe6+ Qxe6
PV 05:00:06.391 14 -44 [right] Nxh6 c3 Nf5 cxb2 Qg4 g6 Kh2 Qd7 Nh4 Rd8
Nxg6+ Rxg6 Qxg6 Qg7 Qh5+ Qh6 Qxh6+ Bxh6 Rb3
----------------
Position 2:
PV 24:10:06.519 16 24 [right] Rxc5
PV 25:58:18.955 16 412 [right] Rxc5 Qxc5 Nxc5 Nxc5 Bh6 Nxb3 axb3 Nd7 Bxf8
Rxf8 Qe4 b6 b4 Re8 f4 Nf6 Qd4
----------------
Position 3:
Not attempted.
----------------
Position 4:
Not solved through 16 plies, >26 hours.
----------------
Position 5:
Not solved through 17 plies, >41 hours.
----------------
Position 6:
Not attempted.
----------------
Position 7:
Not solved through 17 plies, >30 hours.
----------------
Position 8:
Not solved through 12 plies, >19 hours.
----------------
Position 9:
Not attempted.
----------------
Position 10:
PV 10:52:06.991 15 40 [right] Rxf7
PV 11:40:57.135 15 77 [right] Rxf7 Rxf7 Bxf7+ Kxf7 Qh5+ Kg8 Nd5 Qxd4 Qe8+
Bf8 Ne7+ Kh8 Rf1 Qf6 Rxf6 gxf6 Kg1 Kg7 Nxc8
Ne5
----------------
Position 11:
PV 00:14:23.902 13 -227 [right] Rxh6
PV 00:15:41.083 13 -205 [right] Rxh6 Nxh6 Qg5 Nf7 Qd8+ Nxd8 h6 Qe7 h7+ Kxh7
g8=Q+ Kh6 Qh8+ Qh7 Rh1+ Nh5 Rxh5+ Kxh5 Qxh7+
Rh6 Be2+ Kg5 Qg7+ Rg6
PV 00:20:00.195 14 -155 [right] Rxh6 Nxh6 Qg5 Nf7 Qd8+ Nxd8 h6 Qe7 h7+ Kxh7
g8=Q+ Kh6 Qh8+ Qh7 Rh1+ Nh5 Rxh5+ Kxh5 Qxh7+
Rh6 Be2+ Kg5 Qg7+ Rg6
PV 00:22:19.225 14 -143 [right] Rxh6 Nxh6 Qg5 Nf7 Qd8+ Nxd8 h6 Qe7 h7+ Kxh7
g8=Q+ Kh6 Qh8+ Qh7 Rh1+ Nh5 Rxh5+ Kxh5 Qxh7+
Kg5 Bxe6 Nxe6 Qf5+ Kh4
PV 00:33:13.246 15 -93 [right] Rxh6 Nxh6 Qg5 Nf7 Qd8+ Nxd8 h6 Qe7 h7+ Kxh7
g8=Q+ Kh6 Qh8+ Qh7 Rh1+ Nh5 Rxh5+ Kxh5 Qxh7+
Kg5 Bxe6 Nxe6 Qf5+ Kh4
PV 00:40:05.729 15 -59 [right] Rxh6 Nxh6 Qg5 Nf7 Qd8+ Nxd8 h6 Qd4 h7+ Kf7
g8=Q+ Ke7 h8=Q Kd6 Bxe6 Ndxe6 d3 Kc7
PV 01:09:11.569 16 -26 [right] Rxh6 Nxh6 Qg5 Nf7 Qd8+ Nxd8 h6 Qe7 h7+ Kxh7
g8=Q+ Kh6 Bxe6 Ndxe6 Qh8+ Qh7 Qf6+ Qg6 Rh1+
Nh5 Qh8+ Qh7 Qf6+ Qg6
PV 03:39:05.772 17 -134 [right] Rxh6 Nxh6 Qg5 Nf7 Qd8+ Nxd8 h6 Qd4 h7+ Kf7
Bxe6+ Ndxe6 g8=Q+ Ke7 h8=Q Qxe4 d3 Qf5 Qhh7+
Qxh7 Qxh7+ Kf6 Qh8+
brucemo
It's a little more slippery than that, actually.
He's not even claiming that the program would WIN GAMES at long time
controls, just that it would produce the best analysis.
But essentially I agree with this post.
The only reason I'm not yelling for an email computer chess championship is
that I don't enough machine time to participate, probably.
bruce
brucemo
>
> : (1) fast searchers (Fritz, WChess, maybe Nimzo). Those need a laundry
> : machine chip.
> : (2) positional tactictians (The King, Genius, Hiarcs, MChess etc). Those
> : need a "real" computer.
> : (3) positional couch potatoes (most academic programs). Those programs
> : are weak and/or need fat machines.
There is another type of program, typified by Crafty, Ferret, and Shredder.
Stefen: please pardon me if I put you in the wrong company, but this seems
accurate to me.
These programs are very fast, but are end-point evaluators, so they are sort of
mid-way between #1 and #2.
> Hmmm... that would include Chess 4.x, HiTech, Belle, Cray Blitz, Dark
> Thought, *Socrates, and many others. I don't see what the "most academic
> programs" has to do with your statement above??? Several of those are *not*
> "positional couch potatoes"... HiTech can hand you your head in a sack
> positionally most of the time... As can some of the others...
Hitech seems to be of type #2, but it's got custom hardware so it is as fast as
a type #1, although on a P6 I think the type #1's are a little faster than
Hitech now.
bruce
Dan Kirkland
In article <5brf40$a...@merlin.pn.org>,
kerr...@merlin.pn.org (Tom C. Kerrigan) writes:
>Vincent has recently claimed 700,000 non-quiescence-search nodes per
>second on a p5/100 if he takes a lot of stuff out of his program. BTW, he
>implies that this particular program has no move ordering.
I think you people don't read so good...
First, while he did post 700,000...
From reading the rest of the post it seems that he intended
200,000 (not 700,000...?).
Second, he said he was doing very few moves in the Qsearch.
Clearly he is implying that he is doing a super-limited
Qsearch (likely pretty close to not doing a Qsearch at all).
Therefore most of the time will be used in the full width
part of the search.
So basicly he has a program that is almost without a Qsearch
that gets 200,000 nps on a p5/100.
Now back to the posts on this subject...
Again, people can't seem to understand what they read.
While I haven't been to the Diep homepage, I have read what
has been quoted. And I have not read where Vincent says
that Diep needs a time advantage to beat other programs.
Instead it says that while other programs may be better
than Diep at faster time controls (up to a few minutes),
Diep is better at very long time controls (a couple hours).
Most of us know that at very long time controls alpha-beta
blow up so much that it seemingly makes almost no progress
after a while. The search tree gets so big that it can
take hours sometimes just to increase by one ply!
Vincent is simply saying that while other programs get to
a point where they can't make much progress, his program
uses knowledge based forward pruning to keep the number
of moves to a more reasonable level. And therefore Diep
keeps making progress, even after a couple hours, while
other programs get lost searching an impossible list of
moves.
Now I'm not taking sides in this, I'm just trying to make
a few things a bit clearer (fingers crossed!).
Hope this helps...
dan
Vincent Diepeveen
>From: vdie...@cs.ruu.nl (Vincent Diepeveen)
>
>>Please show us why your program is stronger than any other,
>>Mr. Diepeveen.
>
>: I don't claim that it is strong at tournament of course.
>: I only claim that after say about 15 minutes on a Pro with about 30
>: mb hash (or about 45 minutes on a P100-32), Diep solves more
>: positions than any other program.
>
>Let me summerize, if in the year 2000 we have the P8-800 Mhz which is
>for example 5 times faster than the PP200 you would have the strongest
>program at 40 in 2:00 in the middle game.
>
>Huge claim...
In solving positions YES.
In playing tournament games I DON'T KNOW. I can only hope for the best.
It seems you cannot read English well, nor read my homepage.
It is explained at my homepage and several times by me over here
that when playing games the key point is
not making bad moves. No matter how well you play. Just make a blunder
and you loose. I have seen brilliant players loosing terrible won positions
because of this phenomena.
Look to your own Rebel. It is not really brilliant, but simply wins most
games by doing no bad moves, and not making strategical choices (except
if you force it to make one).
I don't want to say that Rebel 8 plays as passively like Genius,
but it looks a lot more like genius than rebel decade for example.
What most commercial programs offer (a program that usually doesn't do
a bad moves) is in strong contradiction to what
for example correspondence players need, and i am trying to put in Diep.
Most correspondence players play at a certain level (a strong one).
Don't need a book, just
a look in the millionbase, and the only way to improve that game
is by making moves of a higher (positional/strategical) level.
This is something i think Diep is
better in than for example Rebel. Just give it a position, let it think
for a long time, and look whether it has found a better move.
Look to my homepage for the first examples i published.
Why don't you try them on Rebel?
Does it find any of the moves?
Does it find both moves like Diep does?
In these positions finding the strongest move is requested. Not 2
non-bad-moves, but 2 good moves. 2 brilliant moves. Let's wait until
Rebel is tested on the 2 positions i so far managed to put on.
I'm going skiing next week. I'll give you an extra week of thinking time
for Rebel!
>- Ed -
>: Especially middlegame it comes up with very strong moves. I'm talking
>: of course about positions that were in games. Not about artificiel
>: positions like white to mate in 270. Diep is not made to find
>: a forced mate in 270.
>: Vincent
Vincent
Vincent Diepeveen
>This is in response to Vincent's first post to this thread (or at least
>the first one I got). I don't feel like quoting the entire mess.
>
>Vincent: Looks to me like you defined your own competition and declared
>yourself the winner. Well, turns out I'm taking the same approach to
>computer chess. Surprise! Now you have some competition. Prove that you're
>better than I am before you say you're the best. Or maybe your next post
>should read, "I write the best program named Diep."
>Cheers,
>Tom
How does your program do on the Nolot Positions?
Just a first indication?
Vincent Diepeveen
In <5c10un$t...@decius.ultra.net> no_jun...@here.com (Joe Stella) writes:
> hy...@cis.uab.edu (Robert Hyatt) wrote:
>
>>Are you counting depth=0 nodes in the basic search or as q-search nodes. That
>>is at the last ply where you look at all nodes (depth=1) from each of these positions
>>you reach a node where you can stand pat or try a capture. These are technically
>>q-search nodes, and there is one of them (at least) for every move searched at
>>[...]
>
>
>The depth=0 nodes seem to be a special case. That's why I count them separately,
>as "leaf" nodes. In other words, I have:
>
>1) Search calling search -> search_node
>2) Search calling quies -> leaf_node
>3) Quies calling quies -> quies_node
>
>So total_nodes is the sum of the three.
>
>I think this is useful for two reasons:
>
>1) Comparing the leaf node number for ply n with the number for ply n+1 gives
>you the best estimate of your program's branching factor (I am talking about
>iterarive deepening here)
>
>2) The ratio quies_node/leaf_node gives you the average size of your quies
>search per node. In other words, I hand a position to my quies search and I
>want to know, how many nodes does it take before this position is resolved and
>the score is returned?
>
>I haven't seen anyone else doing this and I wonder why -- It seemed natural enough
>to me...
to calculate the % my quiescence search i used in Diep the same approach.
I have these 3 things also.
To the Diep-screen i print however the sum of the 3.
> Joe Stella
> jo...@ultranet.com
Tord Kallqvist Romstad
Dan Kirkland (kirk...@ee.utah.edu) wrote:
: Vincent is simply saying that while other programs get to
: a point where they can't make much progress, his program
: uses knowledge based forward pruning to keep the number
: of moves to a more reasonable level. And therefore Diep
: keeps making progress, even after a couple hours, while
: other programs get lost searching an impossible list of
: moves.
Vincent doesn't use any knowledge-based pruning, I think. He
says that he only uses null-move pruning...
Tord
Vincent Diepeveen
>: Then i implemented alfabeta, and killermoves. Alphabeta by the way slows
>: down search speed considerably, so does a deeper search. Speed by then
>: was around 150,000 - 250,000 nodes a second in C.
>
>Sounds reasonable at this point...
>: Then i implemented hashtable. Not yet transposition, just 32 bits
>: tuples from which 16 bits hashing and 16 bits for best move.
>
>: This considerably slowed down search again. to about 115,000 up to 150,000
>: in complex middlegame. Why is that so hard to believe?
>That's not a difficult to swallow number... 700,000 was...
But it is nicer to say you once searched 700000 than it was to say
i search 115,000 in an stupid experiment. 115,000: Fritz already does do that.
>: How many nodes a second do you search? What do you do in q-search?
>: I did very little in that program. At maximum 1 recapture. None preferably.
>
>: Later i changed this to 2 recaptures (or king capture). This worked
>: far better. Giving better scores, but considerably slowed down search.
>
>: Perhaps you should profile your q-search?
>
>: To go back to Diep: Diep spends 5-15% of all nodes in his q-search.
>: In Diep i count the number of nodes spent in q-search to the number of
>: nodes spent in alfabeta to get the number of total nodes. In the
>: experimental program i didn't do this. Eats too much system time, an doesn't
>: give you the real speed of your program. It just gives the speed of
>: your capturelist() function :)
>Are you counting depth=0 nodes in the basic search or as q-search nodes. That
>is at the last ply where you look at all nodes (depth=1) from each of these positions
>you reach a node where you can stand pat or try a capture. These are technically
>q-search nodes, and there is one of them (at least) for every move searched at
>depth=1. This can't possibly be only 15% of the total search, because if you look
>at a tree, the last full-width ply has a much larger percentage of the trees moves
>than this.. typically at least 5x the number of nodes as at the previous ply...
>This trips up comparisons from time to time... I like the definition "if, at the
>current ply, I can stand pat or search deeper, whether I search a capture, a check,
>or some other move, then this node is a quiescence node, because normal alpha/beta
>doesn't tolerate standing pat in the base search..."
Just like Joe stella pointed out, let first split and define the different
nodes:
ab = alfabeta, q = quiescencesearch
a) ab-nodes
b) q-nodes called by ab
c) q-nodes called by q-nodes.
(i don't count makemoves, i just count function-calls)
b) the number of q-nodes called by ab i call leaf-nodes.
To get this 5-15% : c) / b) = 5-15% in Diep.
In some win at chess positions where there are a lot of checks and promotions
and pins and threats this could even go to much more. This are however not
typical middlegame positions.
Surprisingly this 5 is usually not hit in endings with rooks, on the contrary,
endings with rooks usually contain a lot of good checks and 'intruder' moves,
which must be seen to get a quiescent position.
This 5% one usually gets when pawn structures are against
each other; when very little pawns can move, so not only closed positions,
but positions where one cannot make stupid pawn moves.
This was of course a big surprise. I thought always that moves capturing
a previously Qd1-h5?? were the moves causing that q-search overhead.
A pawn seems an important thing in search. I have done also experiments
with a pawnhashtable not only containing the score of the pawn position,
but also containing the best pawn move in that position (as you have a
lot of times, about 98-99% of the times the pawnposition already hashed,
just not the piece structure).
Unlucky that experiment failed, but i think the last word has not been
told about it.
Vincent Diepeveen
>I don't have this post yet. Guess I'll have to make do with the quote...
>> Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
>
>> : This considerably slowed down search again. to about 115,000 up to 150,000
>> : in complex middlegame. Why is that so hard to believe?
>Because Schach 3, running entirely out of L1 cache, searches some 80k
>"conventional" (I assume) nodes/sec. At least you're in the right ballpark
>now, though. Sort of. It still sounds like you're claiming to count two
>"conventional" nodes as one. Is it so hard to admit that you pulled 700k
>out of your ass?
Perhaps your mind is puzzling. I have a program that can plays chess and is
called Diep. It searches at a P100 between 4000-6000 nodes. in that
number q-search is included.
I have done a experiment in order to see how fast one can search.
See it as a complete rewrite. A complete new begin.
The program would fit into cache of any processor... :)
After the test i threw away this try. I saw, although searching deeply,
it playing terrible bad, therefore i continued with Diep.
The experiment puzzles you, as i counted different from your way.
Why did i count different? Well, as the q-search was so damned little,
that it was not worth mentioning. The later C-program searching 115,000 nps
DID contain a q-search which was allowed to capture more pieces.
Even although you didn't know this, you still told me: IMPOSSIBLE!
I don't know who is to blame here, Me because i didn't tell you my
q-search was so limited? Or you because of your poor imagination?
>> : I did very little in that program. At maximum 1 recapture. None preferably.
>
>What the hell kind of search is it when you only search one move? I search
>captures that are deemed non-losing by my SEE.
SEE was takes too much systemtime if you just want to test how fast one
can search.
> When I'm in check, I try
>all responses. This is basically how everybody I've ever talked with does
>it, too. Except you. I have no idea how you're doing it.
During your first lesson: programming, you immediately began to
read how to use pointers?
>> : In Diep i count the number of nodes spent in q-search to the number of
>> : nodes spent in alfabeta to get the number of total nodes. In the
>> : experimental program i didn't do this. Eats too much system time, an doesn't
>> : give you the real speed of your program. It just gives the speed of
>> : your capturelist() function :)
>Woah! The speed of your capturelist() function?? Please don't tell me you
>count every move you generate as a "node"!
This function was used in q-search, and as i already told you,
q-search didn't count as a node.
>> : YOU MUST DEBUG YOUR Q-SEARCH AND PROFILE IT.
>
>A lot of nerve you have, telling me where my bugs are.
Perhaps you should do something about carefully reading things
before writing instead of the reverse order?
>My program agrees with a ton of other programs. Are you saying we all have
>the same bug? Why do you assume that you're right and I'm wrong?
>Arrogance, is my guess.
No, an experiment in order to see how deep one can search with a stupid
program, and how fast this thing could be.
Vincent Diepeveen
In <5c4mm7$9...@ee.utah.edu> kirk...@ee.utah.edu (Dan Kirkland) writes:
>In article <5brf40$a...@merlin.pn.org>,
> kerr...@merlin.pn.org (Tom C. Kerrigan) writes:
>
>>Vincent has recently claimed 700,000 non-quiescence-search nodes per
>>second on a p5/100 if he takes a lot of stuff out of his program. BTW, he
>>implies that this particular program has no move ordering.
>
>I think you people don't read so good...
>
>First, while he did post 700,000...
>From reading the rest of the post it seems that he intended
>200,000 (not 700,000...?).
the program that searched 700,000 the q-search was so limited that
it even played tactically bad because of horizon effects... :)
the 200,000 program (in C 115000 nodes a second) i refer to it the version
that didn't have the same problem, and a better q-search and hashtables
and killermoves. No more.
>Second, he said he was doing very few moves in the Qsearch.
>Clearly he is implying that he is doing a super-limited
>Qsearch (likely pretty close to not doing a Qsearch at all).
>Therefore most of the time will be used in the full width
>part of the search.
the program that was interesting
>Now back to the posts on this subject...
>Again, people can't seem to understand what they read.
Yep
>While I haven't been to the Diep homepage, I have read what
>has been quoted. And I have not read where Vincent says
>that Diep needs a time advantage to beat other programs.
True.
>Instead it says that while other programs may be better
>than Diep at faster time controls (up to a few minutes),
>Diep is better at very long time controls (a couple hours).
Not true.
I claim that it finds better moves, and sometimes a weak move
(although i'm working on it, and the last versions seems also not bad
at tournament level), caausing a game to be lost.
To measure this, one can use a lot of test positions, preferably a
where one must play a very strong positional move.
I claim that from such a testset Diep solves more positions, because
at these depths knowledge simply works better than no-knowledge.
Doesn't imply that i search deeper. Of course i still search 2 ply less.
>Most of us know that at very long time controls alpha-beta
>blow up so much that it seemingly makes almost no progress
>after a while. The search tree gets so big that it can
>take hours sometimes just to increase by one ply!
I see in diep that at these depths branching factor is about 3 to 3.5
that is true, but this is also true for other programs like Fritz,
so still Fritz will search deeper.
>Vincent is simply saying that while other programs get to
>a point where they can't make much progress, his program
>uses knowledge based forward pruning.
No. I don't forward prune. I do use nullmove.
If you search deeply with Diep, then the positional insight of the game
gets relative better compared to for example Fritz.
It doesn't matter how deep fritz search, after a deep search it still
only knows what it already knew before it started to search. of course
it is a tactical better move, and the move takes more into account what
the opponent possibilities are, but it doesn't play positional much
better than what it wanted to play after the pre-search.
In the case of Diep, it evaluates just like a human at the leaf nodes,
and i try to do this as good as possible, and keep on implementing
new knowledge and fixing bugs in old knowledge.
Example:
suppose that the tactical barrier in a given position is 10 ply, and
that the best move in this position is move y;
So when Fritz plays move x after 10 plies search
then when Diep plays move x after 10 plies search,
then there is a greater chance that Diep plays the better move y
at depth 11, than the chance that Fritz will play it.
I guess this is because the positional factors Diep is based on is
knowledge applied in the leaf nodes, where Fritz knowledge comes from
piece-square tables, which one could crude compare to picking a best
move without search, and just tactically verifying it (something which
humans do not do, they evaluate leaf nodes).
> to keep the number
>of moves to a more reasonable level. And therefore Diep
>keeps making progress, even after a couple hours, while
>other programs get lost searching an impossible list of
>moves.
>Now I'm not taking sides in this, I'm just trying to make
>a few things a bit clearer (fingers crossed!).
Most programmers clearly understand what i mean, they just want
to play games, something
their program is good at, and don't want to admit that the positional insight
at leafnodes of their program is below that of a kid
and that the next 100 years it will still make the
same stupid positional mistake, derived from that same rude
endpoint evaluation, which still doesn't see the change when you for example
exchange a bad bishop for a good knight. If a program doesn't know this
basic knowledge, then it will never see it.
It is however questionable how much basic knowledge there is.
Perhaps at a certain point it is not necessary to implement more knowledge?
It is however clear that this basic knowledge must be more than in the
current state of the art programs is.
Vincent
>Hope this helps...
>dan
lensp...@aol.com
In article <5c0ds1$p...@turtle.stack.nl>, mar...@stack.nl (Marcel van
Kervinck) writes:
>
>Robert Hyatt (hy...@cis.uab.edu) wrote:
>
>> It's better to get to the next ply, generate
>> moves, capture the king, and realize that the previous move was
illegal,
>> because this doesn't happen often *except* if the king was in check at
the
>> beginning position of the last ply.
>
>In my program, I make a move and I know instantly it leaves the
>king in check, due to sufficiently updated attack tables.
I'm not versed in bitmap implementations, so here's a method I use.
Granted I'm using the same type of board representation used in the
original SARGON (Rebel uses it also, but with White on the left instead of
at the bottom). This is just a simplified pseudocode for clarity.
GENMOVES()
If check(side) then
ToggleAttacker1() ;switch its color so it's not detected again
temp=check(side) ;look for second attacker
ToggleAttacker1() ;switch it back
If not temp then
capture(attacker1) ;generate captures
if attacker1>knight and attacker1<king then ;sliding piece?
interpose(attacker1) ;generate interposing moves
fi
fi
GenerateKingMoves()
else
for a=21 to 98 do
If (our-pawn) then
generatepawnmoves()
elseif (our-knight) then
generateknightmoves()
elseif (our-r-b-q) then
generateslidermoves()
elseif (our-king) then
generatekingmoves()
fi
od
fi
return
My pawn move generator is the slowest, because it has to test for
self-check in each of the 3 directions. The only thing is if one square
ahead leaves the side to move in check, it simply will not look at the
2-square move. Of course, if one square forward is ok, and 2 squares is
legal (first move), it will not test for check again.
My knight generator simply removes the knight from the board, and tests
for check. If not in check, every legal move (captures an open squares)
is added to the move list right away.
My sliding-piece generator looks at both directions in each
file/rank/diagonal back-to-back. It makes the first move in one
direction, and if it leaves the king in check, it will not waste any more
time on that line. If ok, then all legal moves on that line are added to
the list right away.
My king generator removes the king, and tests all squares it can move to
for any attackers. Each square not under attack is added to the move
list. This method also works for the castling destination and 'through'
squares.
Granted, this is somewhat slow, but the original SARGON programs simply
added all moves not off the board or onto its own pieces to the move list,
then tested EACH one for check.
>> 1. checking for illegal moves is generally bad, because most moves are
>> legal and the test is wasted.
>> In Crafty, when in check, I have a
Ed Schroder
From: vdie...@cs.ruu.nl (Vincent Diepeveen)
>Vincent,
>On your home page I find the following text:
> [ For all chessprograms worth buying search is tremendeously important.
> The reason: the deeper your lookahead (ply depth = half move depth),
> the more tactical things you see, and the deeper the positional
> evaluation is done. As most programs (for example: Fritz, Kallisto,
> Nimzo, The King, Mchess, Zarkov, Hiarcs, Rebel) depend for their
> knowledge so heavily on piece-square tables and cheap knowledge, not
> surprisingly a deeper search doesn't bring that much more positional
> insight to these programs. ]
>Speaking only for Rebel your claim that Rebel "depend for their knowledge
>so heavily on piece-square tables and cheap knowledge" is *NOT* true!
>Can you please change this *untrue* text on your home page?
>Thanks in advance.
: I changed it. Sorry, i didn't know that Rebel was so quickly
: evaluating all the positional factors.
Thanks!
- Ed -
Ed Schroder
From: vdie...@cs.ruu.nl (Vincent Diepeveen)
>Let me summerize, if in the year 2000 we have the P8-800 Mhz which is
>for example 5 times faster than the PP200 you would have the strongest
>program at 40 in 2:00 in the middle game.
>Huge claim...
: In solving positions YES.
: In playing tournament games I DON'T KNOW. I can only hope for the best.
: It seems you cannot read English well, nor read my homepage.
I was just quoting your own home page Vincent.
You say:
I don't claim that it is strong at tournament of course.
I only claim that after say about 15 minutes on a Pro with about 30
mb hash (or about 45 minutes on a P100-32), Diep solves more
positions than any other program.
This is a huge claim and your 2 Nolut positions doesn't mean anything
to me. Just 2 positions and what does it proof *IF* it shows up that Diep
is faster than all other chess programs on these 2 positions?
There are probably a few thousands known test positions where Diep will
be not the fastest.
Meaning more proof!
: Look to your own Rebel. It is not really brilliant, but simply wins
: most games by doing no bad moves, and not making strategical choices
: (except if you force it to make one).
I am not in the mood to argue with you here.
[ snip ]
- Ed -
: Vincent
: --
Ed Schroder
Peter W. Gillgasch
[Three guys discussing. I'll quote this in full length. Sorry.]
Robert Hyatt <hy...@cis.uab.edu> wrote:
> brucemo (bru...@nwlink.com) wrote:
> : Robert Hyatt wrote:
> : >
> : > Peter W. Gillgasch (gil...@ilk.de) wrote:
> : >
> : > : Hold it. There are about three "types" of programs out there:
> : >
> : > : (1) fast searchers (Fritz, WChess, maybe Nimzo). Those need a laundry
> : > : machine chip.
> : > : (2) positional tactictians (The King, Genius, Hiarcs, MChess etc). Those
> : > : need a "real" computer.
> : > : (3) positional couch potatoes (most academic programs). Those programs
> : > : are weak and/or need fat machines.
>
> : There is another type of program, typified by Crafty, Ferret, and Shredder.
>
> : Stefen: please pardon me if I put you in the wrong company, but this seems
> : accurate to me.
>
> : These programs are very fast, but are end-point evaluators, so they are
> : sort of mid-way between #1 and #2.
>
> : > Hmmm... that would include Chess 4.x, HiTech, Belle, Cray Blitz, Dark
> : > Thought, *Socrates, and many others. I don't see what the "most
> : > academic programs" has to do with your statement above??? Several of
> : > those are *not* "positional couch potatoes"... HiTech can hand you
> : > your head in a sack positionally most of the time... As can some of
> : > the others...
>
> : Hitech seems to be of type #2, but it's got custom hardware so it is as
> : fast as a type #1, although on a P6 I think the type #1's are a little
> : faster than Hitech now.
>
> : bruce
>
> I was referring to the "academic couch potato" program classification...
Hold it, before this gets a life on its own :) I didn't say "academic
couch potato" [although I admit that I find it amusing that you said
that 8^)], I said "positional couch potatoes (most academic programs)".
With that I meant programs that need a huge *machine* speed advantage +
complex evaluation to overcome the tactical barrier.
An experiment. Equalize the hardware - not to prove anything about
strenght, but to prove something about the "type" of a program. And take
a low level hardware, something like a P90 (which isn't exactly low
level, but if we take something smaller most type 3 programs will not
even be able to be executed).
In this scenario
type 1 programs run (by definition) in their "usual" environment.
type 2 programs run at the low end of their usual environment.
type 3 programs run in an environment that is below their usual
standard.
Now the "typical" games of type 3 programs:
type 1 versus type 3: type 1 wins by tactics, lots of "this looks ugly,
but I will get away with it" games. Some draws
by "swindle".
type 2 versus type 3: type 2 wins by positional insight but mainly by
tactical pattern recognition stuff (speculative
play). Call it "a better selective search".
type 3 programs are just throwing instructions on the knowledge axis
without making the search smarter [with that I mean for example to
detect mates "at a glance" without any search at all etc.]. Hence my
original claim in respond to Vincent's post stands, if you start with
"type 3" you cannot go into the "type 2" or "type 1" direction. A "type
1" program can migrate towards "type 2" [migrating to "type 3" makes no
sense].
Bob said "lost me there" regarding this claim, but I can only say "been
there, done that".
Regarding the Bob's list of "type 3" programs.... Let's ignore custom
hardware. The programs Bob mentions are IMHO "couch potatoe" types. This
includes DarkThought. Since the programs Bruce mentioned are roughly in
the same ball park I don't think that there is enough justification to
claim that they are "different", but since I don't know too much about
Shredder I can't comment. Crafty is not that different of the
DarkThought code I delivered in the fall of 1995 to the guys after
working nine months full time on it. What a long time ago that is...
With respect to Hitech I'd say it is a type 1 program. And you don't
need a 200 mhz P6 to go that fast...
brucemo
Dan Kirkland wrote:
> Vincent is simply saying that while other programs get to
> a point where they can't make much progress, his program
> uses knowledge based forward pruning to keep the number
> of moves to a more reasonable level. And therefore Diep
> keeps making progress, even after a couple hours, while
> other programs get lost searching an impossible list of
> moves.
No. What you are saying implies increased efficiency. If what
you were saying is true, there would be some sort of speed
crossover point, meaning that if were to start Diep on one
machine, and Fritz on another, and wait, that after some long
period of time you'd come back and Fritz would be working on
ply N and Diep would be working on ply N+1.
I doubt that Mr. Diepeveen is claiming this. I think what he
is claiming is that if you left Diep running on one computer,
and Fritz running on another computer, that initially Fritz
would be planning to make a better move than Diep would be, but
that if you waited long enough, you'd come back and see Diep
planning a better move. It'd probably be searching a shallower
depth, but it'd be finding better moves. So it's not a
crossover point in terms of SPEED, it's a crossover point in
terms of STRENGTH.
This opinion may or may not be true of Fritz, but of course Mr.
Diepeveen isn't just making this claim about Fritz, he's making
it about EVERY other program, or at least every other program
running on a micro.
bruce
Robert Hyatt
lensp...@aol.com wrote:
: In article <5c0ds1$p...@turtle.stack.nl>, mar...@stack.nl (Marcel van
: Kervinck) writes:
Here's about all I can say on this topic: the "name of the game" in computer
chess is "procrastination"... never do now what you can put off until later,
because with alpha/beta, later might not ever come.
That's why I don't worry about being in check when I generate moves, except
when I'm in check at the beginning of a search. Because most moves are legal
in normal positions, doing an InCheck() call has a definite cost. Going to
the next ply and generating moves, and then exiting if you rip a king has a
bigger cost, but if you don't take the rip exit very often, it works out (at
least in Crafty and Cray Blitz) to be faster. I did this exclusively for a
while, but then got interested in the positions where Crafty starts off in
check, because then almost every move goes through the slow "rip" exit at the
next ply. Here it turned out to be faster to use the InCheck() test, and then,
later, to write a GenerateLegalMove() function that was more efficient than
using the rip rejection when in check.
Your milage may vary, but clearly going to the next ply and noticing you capture
a king is much cheaper than doing an InCheck() call after you try each move from
the move list. Just so long as you don't capture the king too often. If you aren't
in check at the start, it's an uncommon event...
Robert Hyatt
brucemo (bru...@nwlink.com) wrote:
: Robert Hyatt wrote:
: >
: > Peter W. Gillgasch (gil...@ilk.de) wrote:
: >
: >
: > : (1) fast searchers (Fritz, WChess, maybe Nimzo). Those need a laundry
: > : machine chip.
: > : (2) positional tactictians (The King, Genius, Hiarcs, MChess etc). Those
: > : need a "real" computer.
: > : (3) positional couch potatoes (most academic programs). Those programs
: > : are weak and/or need fat machines.
: There is another type of program, typified by Crafty, Ferret, and Shredder.
: Stefen: please pardon me if I put you in the wrong company, but this seems
: accurate to me.
: These programs are very fast, but are end-point evaluators, so they are sort of
: mid-way between #1 and #2.
: > Hmmm... that would include Chess 4.x, HiTech, Belle, Cray Blitz, Dark
: > Thought, *Socrates, and many others. I don't see what the "most academic
: > programs" has to do with your statement above??? Several of those are *not*
: > "positional couch potatoes"... HiTech can hand you your head in a sack
: > positionally most of the time... As can some of the others...
: Hitech seems to be of type #2, but it's got custom hardware so it is as fast as
: a type #1, although on a P6 I think the type #1's are a little faster than
: Hitech now.
: bruce
I was referring to the "academic couch potato" program classification...
:)
Robert Hyatt
Stefano Gemma (stefan...@spiderlink.it) wrote:
: Hyatt wrote:
: > What about maintaining the PV? Checking the time every so often? And so
: forth.
: What is the PV?
The series of moves in the best path through the tree, which produces the
best score (minimaxed) that you find.
: > Most of us are interested in the speed at which someone can play real
: chess. With
: > no hash table, your move ordering is going to be inferior, making your
: tree much
: > larger.
: Ok, but we were talking about the max speed reacheable, with the simplest
: program. Obviously a program that play so bad it is not very interesting,
: but because of its speed it is a good point to start from. When i will add
: some extra evaluation features - like not to move queen and king in the
: opening ;-) - obviously the speed will decrease but it is better to start
: from a good speed and then decrease it, than start from a slow program and
: slow it down more ;-)
While that's true, turn off alpha/beta and you go very fast, because you
don't waste effort generating moves and then throwing them away by the
backward pruning process. It'd be very fast, but not search very deep,
and you can't compare those numbers to anything real..
: > If you generate all moves first, which most programs do, and then get
: lots of
: > cutoffs from good move ordering, the above rate will shrink quickly,
: because you
: > invest the time to generate moves (slow) but then don't get to search
: them
: > (which is fast) therefore driving the time to generate a single move way
: up...
: This is too many complex for my poor english ;-). I already generate all
: moves first and evaluate them (the Genera procedure generates and evaluate
: moves, but don't execute them), so i already get a lots of pruning from
: good ordering. As you can see, the nodes counter (in the orrible game that
: i've reported) get lower when there are good moves and bigger when the
: position it is not easy... and in this case... it develope a piece, because
: it don't know anything else to do :-)
: Maybe this message is too long, do i need some pruning? :-)
: Ciao!
:
Robert Hyatt
: Robert Hyatt <hy...@cis.uab.edu> wrote:
: Hold it, before this gets a life on its own :) I didn't say "academic
: couch potato" [although I admit that I find it amusing that you said
: that 8^)], I said "positional couch potatoes (most academic programs)".
: In this scenario
Ok... I understand your terminology now... I thought you were simply lumping
all academic programs into the "positional couch potatoe" classification, and
I enumerated a bunch of academic projects that may or may not fit that...
: Regarding the Bob's list of "type 3" programs.... Let's ignore custom
Peter W. Gillgasch
Robert Hyatt <hy...@cis.uab.edu> wrote:
> Ok... I understand your terminology now... I thought you were simply lumping
> all academic programs into the "positional couch potatoe" classification, and
> I enumerated a bunch of academic projects that may or may not fit that...
Good. Didn't want to put academic approaches like Crafty or DarkThought
down. Hopefully my point is clearer now. No sweat, no firing squads 8^)
-- Peter
Tom C. Kerrigan
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
> How does your program do on the Nolot Positions?
> Just a first indication?
Beats me. Weren't those posted a few years back?
I could probably get a perfect score with a bit of tinkering. I bet you
could, too. :)
Cheers,
Tom
Tom C. Kerrigan
Vincent Diepeveen (vdie...@cs.ruu.nl) wrote:
> Perhaps your mind is puzzling. I have a program that can plays chess and is
My mind is very puzzling. BTW, don't go around telling people they should
improve their English. Jesus. This, from a person who can't seem to spell
"lose" right, among [many] other things.
> The experiment puzzles you, as i counted different from your way.
Right. You counted the "wrong" way. When you don't post anything to the
contrary, I assume that you count nodes the way everybody else I know
counts them.
> Even although you didn't know this, you still told me: IMPOSSIBLE!
And now I read, in another of your posts, that you never actually hit
700K. Damn, am I good or what??
> > When I'm in check, I try
> >all responses. This is basically how everybody I've ever talked with does
> >it, too. Except you. I have no idea how you're doing it.
> During your first lesson: programming, you immediately began to
> read how to use pointers?
Never had programming lessons. Point being?
> >> : YOU MUST DEBUG YOUR Q-SEARCH AND PROFILE IT.
> >A lot of nerve you have, telling me where my bugs are.
> Perhaps you should do something about carefully reading things
> before writing instead of the reverse order?
I post carefully. Notice that my posts are still correct, despite this
node count misunderstanding. I anticipated this, actually. You telling me
that my quiescence search has a bug is simply unjustified. Perhaps I
should give you posting lessons?
Cheers,
Tom
Peter W. Gillgasch
Chris Whittington <chr...@demon.co.uk> wrote:
> Ah, well the academics said it, so it must be right.
Academics ? [ Pulls out his AK-47, grabs his "Peace through superior
firepower" t shirt, picks up his blue "natural born killers" sun glasses
and rolls his eyes ]
Where ? Not here...
-- Peter
Somebody tell me about the perfect bomb
The royal valley of a Blitzkrieg Bop
Somebody tell me how to use my gun tools
Kiss the napalm in the afternoon
Chris Whittington
--
http://www.demon.co.uk/oxford-soft
Peter W. Gillgasch <gil...@ilk.de> wrote in article
<199701231508475228191@[194.121.104.144]>...
Ah, well the academics said it, so it must be right.
Chris Whittington
mclane
kerr...@merlin.pn.org (Tom C. Kerrigan) wrote:
>Anyway, it seems that Vincent is a better programmer than I am by a factor
>of around 500...
>Vincent, can people look directly at you? Or are they blinded by the
>light?
>Cheers,
>Tom
Vincent van Gogh !!
lensp...@aol.com
In article <5c7mva$i...@juniper.cis.uab.edu>, hy...@cis.uab.edu (Robert
Hyatt) writes:
Your point is well taken (as the Jaguar ads suggested, I did the math!).
As soon as I finish the main search loops in Skunk 2.0, I will look at
this idea in 3.0. (Of course, I'm not looking for this to be any kind of
high-power program, being on an old 8-bit Atari, but I'm basically giving
the rest of us die-hard 8-bitters something to work with, with plans on
porting some of my ideas to the Intel-based systems.)
Chris Whittington
--
http://www.demon.co.uk/oxford-soft
Peter W. Gillgasch <gil...@ilk.de> wrote in article
<19970123211450676488@[194.121.104.141]>...
> Chris Whittington <chr...@demon.co.uk> wrote:
>
> > Ah, well the academics said it, so it must be right.
>
> Academics ? [ Pulls out his AK-47, grabs his "Peace through superior
> firepower" t shirt, picks up his blue "natural born killers" sun glasses
> and rolls his eyes ]
>
> Where ? Not here...
What ??!! You joined the real world ? They accepted you ? Not possible :)
Chris Whittington
Tom C. Kerrigan
Chris Whittington (chr...@demon.co.uk) wrote:
> > > Ah, well the academics said it, so it must be right.
> > Academics ? [ Pulls out his AK-47, grabs his "Peace through superior
> > firepower" t shirt, picks up his blue "natural born killers" sun glasses
> > and rolls his eyes ]
> > Where ? Not here...
> What ??!! You joined the real world ? They accepted you ? Not possible :)
The real world is accepting Peter on a trial basis. :)
Peter, we need to get together sometime. I want to see this shirt. :)
Ruf mich an! :)
Cheers,
Tom
brucemo
Vincent Diepeveen wrote:
> I will this evening run the win at chess 300 test at the current
> version of Diep. i will publish it tomorrow. I will not make the
> announced compare with the nullmove turned off. After few positions
> already i saw enough: nullmove gives so terribly much that testing
> without nullmove simply takes me too much time.
>
> Previous version solved 297 win at chess positions. If i remember well,
> there were 3 positions where it needed between 3 and 10 minutes to
> solve a position, and the rest of the 294 positions were solved within
> that time. Most of these 294 positions were even solved within 10 seconds.
Did you do this?
FYI, here is my latest WAC, 60-second run, P6/200. The times are times to
find-and-hold, with fractional seconds rounded down.
0 20 40 60 80 100 120 140 160 180 200 220 240 260 280
+-----------------------------------------------------------
01 | 0 0 0 0 0 0 0 53 0 0 0 0 5 0 0
02 | 13 0 0 0 0 0 0 0 0 0 0 2 0 0 0
03 | 0 0 0 0 0 0 0 0 1 0 0 12 2 0 1
04 | 0 0 0 0 0 0 0 0 0 0 0 0 0 7 0
05 | 0 0 0 0 0 2 0 2 0 0 0 0 0 13 0
06 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
07 | 0 0 0 0 11 0 0 1 0 0 0 0 1 0 0
08 | 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
09 | 0 0 0 0 0 0 0 0 0 0 0 7 0 42 0
10 | 0 0 0 0 0 0 1 18 0 3 3 -- 0 11 0
11 | 0 27 0 5 6 0 0 0 0 0 0 0 0 0 4
12 | 0 0 0 0 17 0 0 0 0 0 0 0 2 0 0
13 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 12
14 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
15 | 0 0 2 0 0 0 0 0 0 0 0 30 0 0 0
16 | 0 0 0 0 0 1 0 0 0 25 0 0 26 0 0
17 | 0 0 0 0 0 0 0 2 0 0 0 4 0 0 11
18 | 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0
19 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
20 | 0 0 0 0 -- 1 0 0 2 14 0 0 0 0 0
> >I would expect that since you claim that your program is a
> >strong analysis program if you leave it running for a few
> >hours, that unless your claim is purely intuitive, you would
> >at least have some proof in your possession that Diep is
> >strong if given sufficient time to analyze.
>
> This is true. I let it run usually for about half an hour.
>
> As we both know, my time is limited, so i cannot test more than few
> positions an evening.
You got any more cool positions? I liked the two in your web page.
> Ok. Please look tomorrow 21/01/1997 after 14:00 at my homepage.
> The first of the examples should be there. But for now, i first
> need to pick up my new video card. Hope it works.. :)
Are you referring to the position that's in your web page now?
Something you can do is make a "suite" version that eats something like an
EPD file, and spits its output not to the screen, but to a disk file. I'm
not sure how you're doing WAC (300 positions) without this, but I also don't
understand why you're needing to do a screen dump to collect search
statistics.
bruce
brucemo
Tom C. Kerrigan wrote:
> What the hell kind of search is it when you only search one move? I search
> captures that are deemed non-losing by my SEE. When I'm in check, I try
> all responses. This is basically how everybody I've ever talked with does
> it, too. Except you. I have no idea how you're doing it.
Not anymore.
bruce
Vincent Diepeveen
>Vincent Diepeveen wrote:
>
>> I will this evening run the win at chess 300 test at the current
>> version of Diep. i will publish it tomorrow. I will not make the
>> announced compare with the nullmove turned off. After few positions
>> already i saw enough: nullmove gives so terribly much that testing
>> without nullmove simply takes me too much time.
>>
>> Previous version solved 297 win at chess positions. If i remember well,
>> there were 3 positions where it needed between 3 and 10 minutes to
>> solve a position, and the rest of the 294 positions were solved within
>> that time. Most of these 294 positions were even solved within 10 seconds.
>
>Did you do this?
Yes and No. Yes, as i tested some of the positions Diep usually
has trouble with, no because i didn't test them all.
Went skiing last week, so could not respond earlier.
Found again a bug in the evaluation, bug in financhetto bishops.
First will fix this.
Then will run test on all positions at a PP200-32, and put results on a disk,
and put it at the homepage of me.
Next Monday at 13:00 dutch time it should be there.
Yep.
>Something you can do is make a "suite" version that eats something like an
>EPD file, and spits its output not to the screen, but to a disk file. I'm
>not sure how you're doing WAC (300 positions) without this, but I also don't
>understand why you're needing to do a screen dump to collect search
>statistics.
I have an automatic tester for EPD files (which tests all positions
in the EPD files) which only prints to disk the
time needed to find a move, the score, and i recently added that it also
prints the depth it first found the move, without jumping to another move.
Time is the time needed without jumping to another move, so search continues,
although it has found the move (except if the score is very huge, so mate or
too much material winning).
To use the autotester one only needs to change the
next 2 parameters in diep.ini:
solvepositions true
logmoves true
and then start diep with a batfile:
c:\diep\> type autotest.bat
if exist diep.log del diep.log
diepwat.exe winatchs.fen
ren diep.log winatchs.log
type winatchs.log | more
Vincent
>bruce
Tom C. Kerrigan
Well, maybe you're not searching all responses to check or not using your
SEE or something, but I will bet good beans that our q-searches search at
least approximately the same things...
Cheers,
Tom
Robert Hyatt
Tom C. Kerrigan (kerr...@merlin.pn.org) wrote:
: Well, maybe you're not searching all responses to check or not using your
: SEE or something, but I will bet good beans that our q-searches search at
: least approximately the same things...
: Cheers,
: Tom
What he meant is that we are not even noticing check in our q-searches any
more, period. We don't get out of check, we don't look at all legal moves,
we don't think about single response, because there's no check to see if we
are even in check. Illegal moves are eliminated by capturing the king at
the next ply, but if all moves are illegal, we take the stand pat score and
keep on searching...
Much faster, has not hurt on win at chess, and we still find mates in 10 in
blitz games all the time...
Jouni Uski
Ferret seems to be better than any commercial program in
WAC suite. Let's hope Ferret goes also to buy soon!
BTW are positions 100,230 solved with longer time or not?
Jouni Uski
brucemo
Tom C. Kerrigan wrote:
>
> Well, maybe you're not searching all responses to check or not using your
> SEE or something, but I will bet good beans that our q-searches search at
> least approximately the same things...
>
> Cheers,
> Tom
Nope. Doesn't even see checks, and there are "winners" it won't search.
bruce
Tom C. Kerrigan
Robert Hyatt (hy...@crafty.cis.uab.edu) wrote:
> Tom C. Kerrigan (kerr...@merlin.pn.org) wrote:
> : Well, maybe you're not searching all responses to check or not using your
> : SEE or something, but I will bet good beans that our q-searches search at
> : least approximately the same things...
> more, period. We don't get out of check, we don't look at all legal moves,
Fine. Like I said, we are searching at least approximately the same
things. This check thing is a detail. I doubt Crafty has a command to say,
"Gee, let's just look at one capture per quiescence search," similar to
what Vincent is doing...
> Much faster, has not hurt on win at chess, and we still find mates in 10 in
> blitz games all the time...
As you're so fond of saying, the above goes for *your* program. (Ferret,
too, in this case.)
I tried it and didn't like it. I'll probably play with it again later.
Cheers,
Tom
brucemo
Oh oh.
I'm not making any sort of claims based upon suite results.
Also, the score can change as I add and delete heuristics. I
have one in there that I'm not sure I like, which is worth one
correct answer.
But yeah, Ferret has a lot of tactical zip, if you discount
positions designed to break null-move programs, and certain
mate problems.
I think that both of the un-solved ones weren't found in
considerable time, but I didn't run it overnight or anything
like that.
bruce