Author: Ed Schröder
Date: 07:34:28 05/03/00
Go up one level in this thread
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
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.