Author: Vincent Diepeveen
Date: 16:06:05 06/18/01
Go up one level in this thread
On June 18, 2001 at 13:12:37, Robert Hyatt wrote:
>On June 18, 2001 at 08:54:10, Uri Blass wrote:
>
>>>
>>It is not about wasting one ply but about clearly more than it and
>>it is clear that not using null move is counter productive when the difference
>>becomes bigger and not smaller at longer time control so the fact that they had
>>better hardware only supports using null move.
>>
>>I suggest that you try Deep Fritz without null move and you can see that at long
>>time control it clearly suffers.
>>
>>Here is a simple test
>>Deep Fritz(pIII800 64 mbytes) needed 16 hours and 29 minutes with null move
>>pruning to find g5
>>
>>Please test it without null move pruning.
>>I have not time to do it but I bet that it cannot see g5 even if you give it
>>200 hours.
>>
>>I will be surprised if the price at long time control is not more than 3 plies.
>>
>>Abir Har aven - Uri Blass
>>2kr4/pppq1pp1/2nb1n2/3p4/5Pb1/2PPP2r/PP1BB1NP/R2QKN1R b KQ - 0 1
>>
>>
>
>
>That is a flawed experiment. Here is why:
>
>Fritz uses null-move to reduce its branching factor. If you eliminate this,
>it is very inefficient. Because it has been _designed_ around the null-move
>search for years, and it has been explicitly tuned for this kind of search.
This is true.
>DB didn't use null-move search. But they _still_ found a way to take the
>branching factor below 4.0, which means they did something Fritz doesn't.
This is utterly nonsense
a) their hashtable was already filled
b) first 30 seconds or so they search from parallel viewpoint
very inefficient. First 10 seconds or so they can only
get a few processors to work efficiently together, only
after perhaps a minute all processors slowly are working a
bit efficient.
I already have this problem for 4 processors, Zugzwang clearly
had this problem. etcetera.
c) crafty has an even better branching factor when it is
searching in the same way as Deep Blue, as deep blue had.
When crafty dies because of extensions, then prob DB too,
but the searches were simply too short (3 minutes at most)
to show this. Also older The King versions simply die
because of extensions and fullwidth search after it gets to
around 6 ply fullwidth search depths (same depth as which
DB got). Diep also had the same problem in my tests. You simply
die around 11 to 13 ply fullwidth. Extensions completely blow up
the tree then.
There is too little data to suggest DBs branching factor was good.
I never saw outputs of hours of them. Just calculate the error
margin. First few ply get quick out of hashtable (because of
better sorting), more processors start to join the search tree).
So in short there is no way to base your conclusion upon, whereas
Both me and Uri have given loads of proof, insight that the opposite
is true!
>Knowing that, how can you compare the two? Answer: you can't... not without
>a lot more information that we simply don't have..
What i know is that DB 100% sure had no hashtable in hardware search.
This is so easy to proof.
What i know 100% sure is that i completely outsearch deep blue at 3 minutes
a move, both positionally, strategically, perhaps only tactical it sees the
same.
Perhaps i'm tactical not much stronger, it seems they extend a load of things
first few plies. But if my new machine arrives (dual 1.2Ghz K7), then
i'm pretty sure i'm tactical also stronger as DB.
This is however *so hard* to proof, that it's irrelevant for the discussion.
Objective analysis of strong chess players indicate clearly that DB made
huge amounts of bad moves, where nowadays chessprograms do not make
the same mistakes. the good moves all get reproduced too by the same
programs.
'saving your ass' nowadays programs are very good at when compared to 1997.
In general the weakest chain which programs had in 1997 is completely
away.
I think it more than logically that *everything* on DB sucks when using
todays standards. Just like everything on todays programs will suck
when compared to DIEP version 2004.
Schach 3.0 from 1997, in those days the tactical standard (nullmove,
hashtable, singular extensions, etcetera), i'm tactical outgunning
it *everywhere* and on nearly *every* trick.
It's branching factor sucks.
What we all forget in all these discussions is that in 1997 i was
laughed to hell in rgcc especially when i said that branching factors
could be getting much better above 10 ply when using nullmove and
loads of hashtables.
it was even posted that getting a branching factor of under 4.0 would
be *impossible* by a guy called Robert H.
With 200M nodes a second and a search depth of 11 to 13 ply with
a load of extensions and with an evaluation considering at least
mobility a bit (DB clearly did a simplistic count on how many squares
a queen occupies for example), 11 to 13 ply was *GREAT* then.
Especially knowing the design of the chip wasn't done in 1997 but
the years before that.
Now we are all USED to nullmove. Used to big hashtables.
Both things DB lacked.
Logically we outclass it by todays standards now.
Just for fun someone might want to do a match.
rebel 8 at a 200Mhz MMX machine (which was the fastest hardware for
Rebel available start of 1997, K6 only was released later that year)
versus a top program of today at 1.33Ghz.
Of course both using the books of that date they were released,
so rebel usin gthe 1997 book, and the todays program using the todays
book.
Of course all games 40 in 2 level. Other levels are no fun and will be
of course an even clearer walk over.
I can tell you even a funnier story. Jan Louwman had matched diep against
nimzo 1998 with the 98 book. both k7-900. 3 hours a game.
*complete* walkover.
in 1998 nimzo98 was the best program at SSDF list, not world champion,
but definitely one of the stronger programs.
Played at todays hardware it gets completely destroyed by todays
software.
in 1997 and 1998, outsearching the opponent still dominated the
commercial programmers. quality at other terrains was not so relevant,
relatively seen.
Now a program must be strong *everywhere*.
- good book (so for example either playing 1.e4 well prepared or
never playing 1.e4)
- good development of pieces and quick castling (shredder!!!)
- reasonable buildup in middlegame
- good endgame
- EGTBs
And during the play no weird things in pruning which cause weird scores
to get backupped to the root.
So the search must be very 'pure' and not disturbed.
In 1997 the common believe of most scientists in rgcc was that nullmove
was very dubious. Of course most programmers already believed in it.
Some simply couldn't believe in it, as their search was build upon pruning
and fullwidth search.
One of them simply skipped all those pruning problems (which would
have taken another 10 years of design) and searched 11 to 13 ply fullwidth.
Can't blame him for doing that.
But what was wise to do in 1997, is now of course completely outdated.
Best regards,
Vincent
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.