Author: blass uri
Date: 07:42:28 05/03/00
Go up one level in this thread
On May 03, 2000 at 10:34:28, Ed Schröder wrote: >On May 03, 2000 at 09:41:13, Dan Ellwein wrote: > >>On May 03, 2000 at 01:21:58, Ed Schröder wrote: >> >>>On May 03, 2000 at 00:17:28, blass uri wrote: >>> >>>>On May 02, 2000 at 07:38:08, Ed Schröder wrote: >>>> >>>>>On May 02, 2000 at 06:26:34, Michael Neish wrote: >>>>> >>>>>> >>>>>>Hello, >>>>>> >>>>>>I wonder whether anyone could help me, or offer any suggestions as to the >>>>>>following little problem. >>>>>> >>>>>>The program I'm writing needs two ply to see what I think should take only one >>>>>>ply. >>>>>> >>>>>>In the position below White wins material by the blindingly obvious Bg5. >>>>>> >>>>>>[D]6k1/pp1nrppp/5rb1/P2P4/5BP1/5P2/4BK1P/R3R3 b - - >>>>>> >>>>>>However, if I set my program to look only one ply deep, it doesn't see this >>>>>>move, and prefers Bb5. At two ply, though, it sees it all right. I think one >>>>>>ply should be enough, as the Qsearch ought to take care of the ensuing >>>>>>exchanges. Indeed, other programs I have tried manage to find it easily enough >>>>>>in one ply. >>>>>> >>>>>>This might be a trivial position, but if it's taking longer than it should to >>>>>>see these tactics then I could be wasting plies in my search. >>>>>> >>>>>>By the way, in case anyone asks, I'm not doing anything unusual in Qsearch. I >>>>>>call Eval() first, return if it fails high, otherwise set alpha to the Eval() >>>>>>score if it's greater than alpha, and then search through the available >>>>>>captures. >>>>>> >>>>>>Thanks for your help. >>>>>> >>>>>>Mike. >>>>> >>>>>Rebel gives a bonus of 1.00 in eval for Bg5 assuming one of those rooks >>>>>get lost. A higher bonus is quite risky as the opponent often has an >>>>>escape. The effect in search is minor. It was effective in the days of >>>>>programs running at 5 Mhz hiting 5-6 plies only. Nowadays I would not >>>>>spend time on such (processor) time consuming cases. >>>>> >>>>>Ed >>>> >>>>I do not understand why not. >>>> >>>>If there is a long line when the final position is one of these cases >>>>you can have a better evaluation. >>>> >>>>Usually long lines are not forced so the effect may be better positional moves >>>>and not tactics. >>>> >>>>Uri >>> >>>Your point sounds very plausible but isn't true. Search solves these >>>kind of cases and you only end up with some speed loss. Running a >>>set of 500 positions only gave a few (non-important) different moves. >>> >>>That is one of the crazy things of CC, you have to go from scratch on >>>your code every 3-4 years as many things that were good then are >>>out-dated now because of increasing hardware (Mhz & Ram). >>> >>>A few days ago I wrote something about 1992 and one instruction making >>>Rebel (The ChessMachine then) stronger. It made me think about and as >>>a result I improved that piece of code with a net result of 28% speed >>>gain. The change would not have been a good idea in 1992. >>> >>>Search is a strange animal and hard to understand for the human brain. >>>It is full of unexpected surprises. I estimate that after 20 years >>>wrestling with search I only understand 5% (or so) of search. >>> >>>Ed >> >> >>Ed... >> >>sounds like there might be a correlation here between search and the human >>brain... >> >>in that we 'only' use about 5% of our brain... >> >>and... >> >>after many years of performing brute force/selective search techniques (going >>back to Shannon - 1950's), we only understand about 5% of what's really going >>on... >> >>well... any-way... >> >>just a thought >> >>:) >> >>PilgrimDan > >Well maybe the 5% is also true for life itself no matter what age :-) > >Ed I think trying to understand more is a good idea because knowing the reason that something help your program may help you to discover more ideas to help your program. Uri
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.