Author: Bernhard Bauer
Date: 07:41:01 08/25/98
Go up one level in this thread
On August 25, 1998 at 08:45:58, Robert Hyatt wrote:
>On August 25, 1998 at 03:47:55, Bernhard Bauer wrote:
>
>
>>
>>Let me first say that IMHO we often get different results. Why???
>>
>
>
>
>Here I have no idea. There is nothing in crafty that in indexed by the
>number of a specific piece. IE you can set a position with 40 queens, or
>40 rooks, or 40 pawns, and it doesn't cause any problems of any kind. The
>only thing that can break it (which should have been fixed in 15.18) was
>setting a position with setboard where the side not on move is in check.
>I can't fix this in "edit" because of the way winboard/xboard uses this to
>first set the position, and *then* sets the side-to-move. But other than
>that, there is no reason for a crash with a large number of pieces. I ran
>this both on a sun, compiled with sun's CC compiler, as well as on linux, and
>didn't get any sort of a problem.
>
>
>>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.
>
>can you send me a log.nnn file to see where it is having problems? Because
>it doesn't fail here on any compiler I have... gcc 2.7.2, egcs, the pentium
>compiler group pgcc compiler, nor sun's professional C compiler..
>
Ok. Here is the log file
--------------------------------------------------------------
Crafty v15.18 (2 cpus)
max threads set to 2
using cpu time
hash table memory = 24M bytes.
pawn hash table memory = 10M bytes.
White(1): setboard 4k3/nnnnnnnn/8/8/8/8/RRRRRRRR/4K3/ w
+---+---+---+---+---+---+---+---+
8 | | | | | *K| | | |
+---+---+---+---+---+---+---+---+
7 | *N| *N| *N| *N| *N| *N| *N| *N|
+---+---+---+---+---+---+---+---+
6 | | | | | | | | |
+---+---+---+---+---+---+---+---+
5 | | | | | | | | |
+---+---+---+---+---+---+---+---+
4 | | | | | | | | |
+---+---+---+---+---+---+---+---+
3 | | | | | | | | |
+---+---+---+---+---+---+---+---+
2 | R | R | R | R | R | R | R | R |
+---+---+---+---+---+---+---+---+
1 | | | | | K | | | |
+---+---+---+---+---+---+---+---+
a b c d e f g h
White(1): d
White(1): go
clearing hash tables
--------------------------------------------------------
>
>>
>>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.
>>
>
>
>it is equally probably that msvc has a bug.. but I need to know where the
>program is blowing up before I can figure that out. IE you might compile with
>-g, then run it under the debugger to see where it is dying... It is impossible
>to debug something I can't produce...
Ok. I get for UNIX (AIX3.2.5)
dbx ./crafty core
dbx Version 3.1
Type 'help' for help.
reading symbolic information ...
[using memory image in core]
segmentation violation in EPDTBScore at line 7278 in file "epd.c"
7278 if (rb.rbv[sq] == cp)
(dbx)
>
>
>
>
>>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.
>
>
>not necessarily. I *always* run the current developmental version, and not
>the last released version. Null-move is highly sensitive to evaluation
>changes, among other things, which could easily explain the difference. As
>an example, a minor eval change had version 15.18 (released) not solving
>win at chess 163 until one iteration later than it did before the change. Some
>detailed study found that the null-move search was the guilty party, because the
>eval change made something fail high on the null-move search when it didn't
>before the change... that happens regularly...
Yes, its difficult.
>
>
>
>
>
>>
>>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.
>>
>
>
>sorry, but your idea is *wrong*. Given the choice of being right 99.999%
>of the time, or .001% of the time, the choice is obvious. I do *not* want
>to trade into a KB vs KB, simply so that I can find the mate in 1 in the 4
>positions where it is possible in such a position. Crafty is written to play
>chess, not solve problems...
I don't make that difference. Problems are especially beautyfull. but I
accept your point.
> and this is one of the compromises that has to be
>played. IE how many humans play into an opposite bishop ending? If they are
>ahead two connected passed pawns? Not many because once the pawns are
>blockaded, it is a draw, and they know this, even though there might be
>something that actually makes this rule-of-thumb wrong. In this case, it is
>an important rule that most every chess program has (as I said, Amir mentioned
>that Junior does the same thing for the same reason...)
>
>
>
>
>>>
>>>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
>>
>
>
>I still disagree with the term "wrong". Programs don't play perfect chess,
>and probably won't for several thousand years. In such cases, when you can't
>cover *every* case, you have to compromise and cover *most* cases. This we
>do, by declaring KB vs KB a draw, instantly.
IMHO deep blue can solve a lot of studies. Simply by searching. But also
the rare cases have to be searched.
There was (is) great interest in Ferret. I hope that Ferret can do without
the "insufficient material feature" and I hope that if it uses null move
it has a zugzwang detection. That would do for me.
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.