Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Diep fullwidth vs Deep Blue fullwidth

Author: Vincent Diepeveen

Date: 14:20:54 12/24/99

Go up one level in this thread


On December 24, 1999 at 16:54:39, Robert Hyatt wrote:

>On December 24, 1999 at 16:32:49, Vincent Diepeveen wrote:
>
>>On December 24, 1999 at 15:53:49, blass uri wrote:
>>
>>>On December 23, 1999 at 19:24:48, Vincent Diepeveen wrote:
>>><snipped>
>>>>Bob i've got proof of bad working of singular extensions.
>>>
>>>I think it is possible that they had a rule of not extending
>>>wasting tempo moves so deep thought could not see when that 18.Rg1 is
>>>losing when it played 16.c4 because black waste tempo in the line Qh4-h3 Rg1
>>>Qxh2+.
>>>
>>>It is also possible that they did not extend this line because they did not
>>>extend lines that give the queen for a pawn.
>>>
>>>You need to see 14 plies from the move 16.c4 without extensions to find
>>>22...Qxh5#
>>
>>Don't forget check extensions in qsearch and exending on check,
>>apart from that singular extensions.
>
>Why are you still stuck on the deep thought hardware problems?  DB 1 and
>DB 2 were _far_ different.  DT didn't do nor understand checks/mates in the
>q-search.  It didn't understand repetitions in the hardware either. DB 2
>fixed both of these problems as well as added an order of magnitude more
>gates for the evaluation.

This was hong kong: deep blue 1.

Even deep thought should have seen of course. Put crafty to fullwidth
and see how little plies it needs to see c4 is very bad. Just give
a big bonus to not having a pawn on c2 or c3. See my previous post.

We talk about Deep Blue a few months before it plays Kasparov.
This is not an evaluation issue only. My eval sees it 1 ply sooner than
a simplistic piece square table program. The piece square table
version of DIEP needs only 9 plies to see this.

I don't DOUBT that extending all checks sees it even sooner.

>What is the purpose of trying to find errors in late 1980's hardware and then
>from that extrapolate things about DB2?  They have very little in common.
>
>
>
>
>>
>>That all rips plies from it. apart from that you don't need to
>>see all lines to already not play c4.
>>
>>If evaluation of Deep Blue I was really that bad, then it still should
>>see all this tactical. If it didn't , then obviously its fullwidth
>>search with singular extensions and some other crap didn't work for
>>this obvious position.
>
>
>That was _not_ deep blue.  It was deep thought hardware. This has been
>well-documented for several years now.  It was called (at one point)
>deep blue prototype. With the note that "this is the DB software search
>but using the original deep thought hardware."
>
>
>
>
>>
>>It clearly refutes the idea that singular extensions solve the game.
>>I see it very simple. A professional hardware designer makes a
>>special chip called deep thought, deep blue, deep blue II.
>>
>>An incredible achievement on its own.
>>
>>Then he's inventing singular extensions.
>>Though all commercial programmers who
>>dedicate fulltime to their program and many other researchers
>>can't get it to work, or make it work in such a way that it only
>>gives them sometimes in tacitcal position 1 or 2 ply more,
>>this hardware designer, can?
>
>
>I got it to work.  Bruce got it to work.  Lang got it to work.  Kittinger
>got it to work.
>
>>
>>And apart from this claim that it's seeing the right plies,
>>but then it falls into an easy joke?
>
>
>not the same hardware _at all_...
>
>
>
>>
>>I'll put now evaluation off from DIEP (not smart in itself, but i'll
>>just let it do material) and see how many plies after c4 it sees
>>serious trouble, besides seeing whether it plans c4 at all.
>>
>>>I do not think that the reason of not seeing this tactics was singular
>>>extensions because I believe that with singular extensions and some check
>>>extensions it is possible to see that 16.c4 is bad.
>>>
>>>Uri



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.