Author: Sune Fischer
Date: 08:22:28 06/22/02
Go up one level in this thread
On June 22, 2002 at 11:00:52, Robert Henry Durrett wrote: >On June 22, 2002 at 10:46:07, Sune Fischer wrote: > >>On June 22, 2002 at 09:34:51, Uri Blass wrote: >> >>>On June 22, 2002 at 07:51:03, Sune Fischer wrote: >>> >>>>On June 22, 2002 at 06:56:11, Uri Blass wrote: >>>> >>>>>On June 21, 2002 at 12:28:49, Christophe Theron wrote: >>>>> >>>>>>On June 21, 2002 at 06:53:41, Uri Blass wrote: >>>>>> >>>>>>>On June 21, 2002 at 04:57:44, Russell Reagan wrote: >>>>>>> >>>>>>>>On June 21, 2002 at 04:38:04, Uri Blass wrote: >>>>>>>> >>>>>>>>>How much time does your program need to see that it is a draw? >>>>>>>> >>>>>>>>At least a few more weeks :) >>>>>>>> >>>>>>>>Russell >>>>>>> >>>>>>>It is an easy draw for the following reasons; >>>>>>> >>>>>>> >>>>>>>1)White need always to move the knight by Nb3 N.. Nb3 N.. Nb3 N.. when the >>>>>>>knight is never captured(the knight is never captured in b3 and we need to prove >>>>>>>that the knight has a safe black square to go in order to prove that it is a >>>>>>>draw). >>>>>>> >>>>>>>2)The black king cannot control a1 so the black bishop needs to be in the long >>>>>>>diagnol in order to prevent a1 from the knight. >>>>>>> >>>>>>>3)The black bishop in the long diagnol can not control a5 so the black king >>>>>>>needs to control that square. >>>>>>> >>>>>>>4)3 means that the black king cannot control c1 and d2 so the black bishop needs >>>>>>>to control these squares but the black bishop must be in b2 in order to control >>>>>>>both a1 and c1 and it does not control d2 from that square. >>>>>>> >>>>>>>I believe that even programmers with rating of 1500 can find that it is a draw >>>>>>>and I wonder if one of them was smart enough to write the relevant code to >>>>>>>explain it to the computer. >>>>>>> >>>>>>>Uri >>>>>> >>>>>> >>>>>> >>>>>>The question is: will it make the program stronger? >>>>>> >>>>>>I can easily see how it can make a program weaker by slowing it down, and I >>>>>>seriously doubt it will increase the program's rating by a single elo point. >>>>> >>>>>I can see how it can make the program better. >>>>> >>>>>If you have a function that calculates it only at the first plies and continue >>>>>to claculate it only if it finds that the knowledge is relevant then the program >>>>>may be only 0.1% slower in most of the positions when it may see the draw and >>>>>avoid a mistake in some cases. >>>>> >>>>>You can still say that there are things that are more important to do but I >>>>>believe that every knowledge can do programs stronger. >>>>> >>>>>Uri >>>> >>>>I think that if this should be have any effect on strength (against humans) it >>>>should be detected at the leaf nodes, so we have a few plies to avoid it. >>> >>>I think that the leaf nodes of 3 ply or 4 ply search may be enough in part of >>>the cases. >>> >>>Not in every case but in significant part of the cases when similiar problems >>>happen and when the hardware get faster the programs may search even deeper >>>because I suggest to use 0.1% of the time for these problems and I do not >>>suggest to use fixed depth(it may be even better to use even 1% of the time but >>>not 50% of the time). >>> >>>>There is no doubt the GM will spot this draw a long time before its on the board >>>>and will play for if he is in trouble. >>> >>>Even in this case it is not clear that he can give the program a long forced >>>line for the draw so detecting the draw few plies before it happens may be >>>enough. >>> >>>Note that I do not use these ideas today in movei because there are more >>>important things to do and I do not work a lot about movei. >>> >>>Uri >> >>I think the problems lies in how do such an evaluation, >>are you going to write: >>if (white has 1 bishop && >> black has 1 knight && >> white has 2 connected pawns && >> black has his king and knight under the pawns && >> white has a bishop of wrong color && // subroutine call needed >> black can't be forced away && // subroutine call needed >> black has enough squares to not be in zugzwang) // subroutine call needed >> return contemptfactor; >> >>just to solve 1 specific case? >>What if the pawns are not connected, what if.... >>There could be cases where this is not even draw. >> >>It is not something I plan to implement in the near future, that's for sure ;) >> >>-S. > >How about the idea of using "indicators" which would indicate the possibility >but anything else? The amount of code &/or clock cycles required for this might >be much less than that which would be required for a definitive evaluation. >Only is the presence is "indicated" would the engine go into the longer code. >This might solve the problem in a statistical manner. If the "indicators" are >not perfect, then there will be missed opportunities, but if the "indicators" >are good, then missing an opportunity would not occur often enough to matter. >Don't ask me to define the indicators. That will take a strong chessmaster or >better, I'm afraid. > >Bob D. Well to be honest I have something like that, but only for a total of 4 pieces. I 'bisect' my way through to the specific cases, that is relative cheap I think, the first condition obviously being if there are 4 or less pieces on the board. But I think most engines have that, because those endgames occur frequently and are also easy to code, e.g. what program doesn't have drive king to the edge knowledge when in a KR-K endgame. When there are more pieces things get ugly, KBPP-KNN for instance - care to design a static eval for that? You see specific cases are of almost no interest because there are billions of them, we need general rules that will work on hundreds of cases, or it is just not worth the time. -S.
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.