Author: Jarkko Pesonen
Date: 05:54:07 06/29/00
Go up one level in this thread
On June 28, 2000 at 15:51:33, Robert Hyatt wrote: >On June 28, 2000 at 12:35:30, Bruce Moreland wrote: > >>On June 28, 2000 at 11:48:46, Robert Hyatt wrote: >> >>>I understand... but _here_ is the real question: In how many similar positions >>>will it have the same eval, and it be wrong? I've seen it play brilliantly in >>>one game, and then play like a patzer in the next four games. It is nice to >>>find positions where a program _really_ seems to get the right idea. But then >>>reality sets in, as you find similar (but not similar enough) positions where >>>the program comes to the same conclusion as in the brilliant game, but it is >>>dead wrong. >>> >>>This happens way too frequently with computer chess programs, unfortunately, >>>mine included. It will play a brilliant endgame against a GM, then come back >>>and play a completely insane endgame that no 2000 player would even consider. >>> >>>I don't like to brand programs as "brilliant" until they handle things most >>>of the time, not just some of the time... >> >>I think it probably understands it. I know that CST does things that are very >>speculative in the middlegame, but this may be a null-move killer. Does Crafty >>know to play 1. h5 in the following position? >> >>[D]2R5/4k3/p2Np2p/4P1p1/p5pP/q1P1P1P1/2P5/1K6 w - - >> >>Mine doesn't. Force the move though, and boom. >> >>bruce > > >Mine neither. Too many zug positions there.. But Crafty did know how solve this up to version 17.4 17.5 didn't solve this anymore. From main.c rewrite of outside passed pawn/pawn majority code. it is now much faster by using pre-computed bitmaps to recognize the right patterns.
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.