Author: Vincent Diepeveen
Date: 12:14:38 10/11/02
Go up one level in this thread
On October 11, 2002 at 13:34:10, Jeremiah Penery wrote:
>On October 11, 2002 at 13:10:23, Vincent Diepeveen wrote:
>
>>On October 11, 2002 at 10:44:37, Jeremiah Penery wrote:
>>
>>>On October 11, 2002 at 10:32:24, Gian-Carlo Pascutto wrote:
>>>
>>>>On October 11, 2002 at 09:41:13, Uri Blass wrote:
>>>>
>>>>>It evaluates the position as clear advantage for white(I think that white is
>>>>>winning and h3 cannot save black).
>>>>
>>>>IIRC, h3 forces a draw.
>>>
>>>It becomes a repetition draw. DT/DT2 could not recognize repetition draw in the
>>>hardware, so it's no surprise at all they couldn't see this.
>>
>>No it's not a repetition draw.
>>
>>It's simply winning a pawn with black by force by a check at the
>>end after which the e5 pawn is hung.
>>
>>Then you get left with KRP KRP which is a trivial 0.00 score.
>>
>>However, if you don't see that line, which is just 12 ply, then
>>you have of course a problem.
>>
>>with 3 minutes a move and millions of nodes a second DT couldn't see it.
>>
>>Repetition has nothing to do with it at all.
>
>Try turning off repetition detection with DIEP on this position. I'm interested
>to see how much it will change the output. There are a lot of repetition lines
>that can come from this. For example:
>
>1. ...h3 2. Rxh6 a3 3. Rxh3 Ra4 4. Rh8+ Ke7 5. Rh7+ Kd8 6. Rd7+ Ke8, etc.
>
>If you don't detect repetition, you might think white is winning in this line.
>If this gets backed up to the root, it could be enough to make the program think
>h3 is a bad move.
I posted the line a thread under this. If i turn off nullmove and
singular extensions and turn off repetition i still find h3 here at 13 ply.
However don't ask me how many nodes i need when i turn off nullmove.
Now compare this with the shitload of extensions from deep thought.
9 ply is what i need. Even if they need 12 or 13 ply (impossible with
correctly implemented SE) then still you need get confronted with the hard
fact of inefficiency of the DT/DB hardware processor. It's very inefficient
- no hashtables
- no killermoves
- no good move ordering at all in hardware (costing too
much hardware clocks simply)
- no nullmove
In hardware he's doing a kind of random move ordering.
Terrible inefficient.
That's the point i am trying to make
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.