Author: Bernhard Bauer
Date: 00:47:55 08/25/98
Go up one level in this thread
On August 24, 1998 at 12:49:40, Robert Hyatt wrote:
>On August 24, 1998 at 10:50:48, Bernhard Bauer wrote:
>
>>On August 24, 1998 at 10:02:40, Robert Hyatt wrote:
>>
>>>On August 24, 1998 at 08:53:01, Bernhard Bauer wrote:
>>>
>>>>On August 24, 1998 at 04:57:58, Andreas Stabel wrote:
>>>>
>>>>>I have discovered some small problems with crafty.
>>>>>
>>>>>1) If a castling leads to a check, crafty does not output the + after
>>>>> the move, i.e. O-O is output and not O-O+.
>>>>>
>>>>>2) Sometimes crafty does not output the right move list when in analyze
>>>>> mode. Enter crafty and then analyze mode. Type the
>>>>> moves a3, a6 and Nf3. If you now type history you only get the first
>>>>> moves. Below is the output:
>>>>>
>>>>> book 0.0s 29% g6
>>>>>analyze.Black(1): a6
>>>>>a6
>>>>>Black(1): a6
>>>>> clearing hash tables
>>>>> time surplus 0.00 time limit 30.00 (3:00)
>>>>> depth time score variation (1)
>>>>> 4-> 0.29 0.00 2. Nf3 Nc6 3. Nc3 Nf6
>>>>> 5 0.41 0.22 2. Nf3 Nc6 3. Nc3 Nf6 4. e4
>>>>> 5-> 0.99 0.22 2. Nf3 Nc6 3. Nc3 Nf6 4. e4
>>>>>Nf3 6 0.99 1/19 2. Nf3
>>>>>White(2): Nf3
>>>>>analyze.White(2): White(2): Nf3
>>>>> clearing hash tables
>>>>> time surplus 0.00 time limit 30.00 (3:00)
>>>>> depth time score variation (1)
>>>>>hi 5 0.20 4/19 2. ... d5
>>>>>Black(1): hi
>>>>> white black
>>>>> 1 a3 ...
>>>>> 5 1.09 -0.02 2. ... d5 3. e3 Nc6 4. Bd3 Bg4
>>>>> 5-> 1.24 -0.02 2. ... d5 3. e3 Nc6 4. Bd3 Bg4
>>>>> 6 2.28 -0.32 2. ... d5 3. e3 Bf5 4. Be2 e6 5. O-O
>>>>>
>>>>>Note that before the "hi" is typed, crafty outputs "Black(1): " , but it
>>>>>should have output "Black(2): ".
>>>>>
>>>>>3) Finally I have a position where crafty does not find a mate in one.
>>>>> Is this a bug or is it nullmove related or something ?
>>>>> The FEN is: 7k/4N3/7K/4N3/8/8/b7/8 w - - 0 5
>>>>> The mating move is N5g6#. By the way this position arise from a nice
>>>>> problem with FEN: 6bk/8/3P2K1/4N3/8/8/2r5/1N6 w - - 0 1
>>>>>
>>>>>I run crafty on a Windows 95 with EGTB, ROCK opening book and 24Mb (5Mb) hash.
>>>>>
>>>>>Best regards
>>>>>Andreas Stabel
>>>>
>>>>4) Something like
>>>> setboard 8/2B2pPb/7k/4K3/3p2P1/8/8/8 w
>>>> d
>>>> search g8=N+
>>>> move
>>>>will not work. Crafty says: Illegal move (ambiguous): g8
>>>>
>>
>>You did'nt comment on this!
>>
>
>this I'll have to look at... the "search" command is really more of a
>debugging tool than anything else, because you can get the exact same
>result by just typing the move and letting it search from the other side.
>It is no more/less efficient...
>
>
>
>
>>
>>>>5) setboard 4k3/nnnnnnnn/8/8/8/8/RRRRRRRR/4K3 w
>>>> move
>>>>will crash Crafty.
>>>>
>>>
>>>
>>>
>>>I can't reproduce this. There are no "piece limits" in crafty, and setting
>>>this position simply produced a funny-looking position. Typing "go"
>>>produced Rxh7 with an eval of +25 with no problems...:
>>>Crafty v15.19
>>>
>>
Let me first say that IMHO we often get different results. Why???
I have testet the above position "FEN: 4k3/nnnnnnnn/8/8/8/8/RRRRRRRR/4K3 w"
1. with my own compiling of crafty 15.18 with MSVC++5.0.
2. with IBM's xlc
3. with gcc 2.7.0
4. with wcrafty-15.8-smp.exe from your ftp site
And Crafty *always* crashes immediatly.
I think you should be able to reproduce this behavior - and it may be
important because it you don't get this running a different gcc under
LINUX you may have an error that may not show up for you, but is still
there and may produce bad results in other cases.
Some weeks ago we had discussed the following position
+---+---+---+---+---+---+---+---+
8 | | | *Q| | | | | |
+---+---+---+---+---+---+---+---+
7 | | | | | | | | |
+---+---+---+---+---+---+---+---+
6 | | | | | | | *P| |
+---+---+---+---+---+---+---+---+
5 | B | | | | | | | *P|
+---+---+---+---+---+---+---+---+
4 | | | | | | | | *K|
+---+---+---+---+---+---+---+---+
3 | | | | | | | | P |
+---+---+---+---+---+---+---+---+
2 | R | | | | | | P | K |
+---+---+---+---+---+---+---+---+
1 | | | | | | | | |
+---+---+---+---+---+---+---+---+
a b c d e f g h
It is a null move position. I claimed that crafty could *not* solve
this position. You postet output that showed a solution on ply 14.
Before you had Rf2 with a score of 0.00. I had *always* Rf2 with a score
of -0.66.
I think we should be able to agree on output.
>>I have this problem with crafty running NT4.0 and AIX2.2. In both cases
>>crafty crashes running version 15.18.
>>
>>
>>
>>>
>>>
>>>>Personally I find 3) the "insufficint material feature" quite annoying
>>>>and would be happier whithout it.
>>>
>>>
>>>I disagree. I think that after playing one game with something like KNNP
>>>vs KB or KP, and seeing it allow the opponent to rip the pawn for its last
>>>piece (the bishop or pawn) that you'd not like removing this, because it
>>>wouldn't know to protect that pawn at all costs to keep winning chances
>>>alive...
>>>
>>>This from *lots* of experience on the chess servers, which is why this was
>>>added, of course...
>>>
>>>As I said, it is wrong so rarely as to not matter. It is right enough that
>>>it is very useful...
>>>
>>
>>It's not rarely to me.
>>Here a position without knights.
>>
>>White(1): White(1):
>> +---+---+---+---+---+---+---+---+
>> 8 | *K| | K | | | | B | |
>> +---+---+---+---+---+---+---+---+
>> 7 | *B| | | | | | | |
>> +---+---+---+---+---+---+---+---+
>> 6 | | | | | | | | |
>> +---+---+---+---+---+---+---+---+
>> 5 | | | | | | | | |
>> +---+---+---+---+---+---+---+---+
>> 4 | | | | | | | | |
>> +---+---+---+---+---+---+---+---+
>> 3 | | | | | | | | |
>> +---+---+---+---+---+---+---+---+
>> 2 | | | | | | | | |
>> +---+---+---+---+---+---+---+---+
>> 1 | | | | | | | | |
>> +---+---+---+---+---+---+---+---+
>> a b c d e f g h
>>
>>White(1): end-game phase
>> clearing hash tables
>> time surplus 0.00 time limit 5:00 (5:00)
>> depth time score variation (1)
>>starting thread 1
>> time: 0.03 cpu:6166% mat:0 n:600 nps:10000
>> ext-> checks:60 recaps:0 pawns:0 1rep:0
>> predicted:0 nodes:600 evals:1
>> endgame tablebase-> probes done: 0 successful: 0
>> hashing-> trans/ref:0% pawn:0% used:w0% b0%
>>
>>White(1): Bh7
>> time used: 0.03
>>learning position, wtm=1 value=-66
>>game is a draw due to insufficient material.
>>
>>Do we really have to pay the price?
>>
>>Kind regards
>>
>>Bernhard
>>
>
>
>Here's the question: How many times do you see this? I just searched
>thru my "crafty database" of games played on ICC/chess.net/etc, which has
>over 70,000 games in it... and I found *zero* that fit this problem. IE
>where the game ended with KNN vs KX where the KNN could force mate. There
>was one exception with a KNN vs KP that happened once, but in testing this
>Crafty couldn't win it anyway without the database.
Obviously you get *zero* from 70,000 games. What else? Your database is
done in that way. But it is not only a problem for KNN vs KP positions
as you can see from the above position. A simple KB vs KB is handles wrong.
I don't care wether crafty is right in 99.999999% of all positions because
I am only interested in *one* position. The position I have to deal with.
And I want to be shure that this position is done right.
>
>So, as I said, this doesn't seem to be a problem. I believe that someone
>complained about such a 'trick' to Amir Ban also, and his response was the
>same as mine, "it is correct far more times than it is wrong, and I'd rather
>avoid trading into a known draw far more than I'd rather try to avoid missing
>a very very rare mate"....
Yes I saw this. It will not help if Amir Ban does it in the same wrong way.
He (and you) does it for speed reasons. But it will give him a bad reputation.
Wich is especially bad for a commercial program. People will say:
"Program X can play at an Elo level of 2500 but can not find a mate in *one*."
Or:
"Sometimes may dog plays better than Junior."
But we do not have to agree on this subject.
Kind regards
Bernhard
>
>
>
>
>
>>>>
>>>>Kind regards
>>>>Bernhard
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.