Author: Robert Hyatt
Date: 05:45:58 08/25/98
Go up one level in this thread
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.. > >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... >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... > >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... 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.
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.