Author: Thomas Mayer
Date: 15:10:17 02/01/05
Go up one level in this thread
Hi Vincent, On February 01, 2005 at 17:20:25, Vincent Diepeveen wrote: >On February 01, 2005 at 14:35:53, Thomas Mayer wrote: > >>Hi Vincent, >> >>On February 01, 2005 at 14:30:22, Vincent Diepeveen wrote: >> >>>On February 01, 2005 at 14:22:26, Thomas Mayer wrote: >>> >>>>Hi Vincent, >>>> >>>>On February 01, 2005 at 14:05:50, Vincent Diepeveen wrote: >>>> >>>>>On February 01, 2005 at 14:02:18, Vincent Diepeveen wrote: >>>>> >>>>>>On February 01, 2005 at 12:20:30, Thomas Mayer wrote: >>>>>> >>>>>>You mean like this? >>>>>> >>>>>[D]8/8/P4b2/2K3k1/8/8/8/8 b - - >>>>> >>>>>1-0 >>>>> >>>>>Whereas : >>>>>[D]8/8/P4b2/2K3k1/8/8/8/b7 b - - >>>>> >>>>>Is a draw. >>>>> >>>>>And if you remove the f6 bishop it's a win for white again. >>>> >>>>thanks... your example kills my second idea... so I must return failure when 2 >>>>bishops are present... I could create rules which even would cover those >>>>problems, but for a fast routine they would be to complicate... >>>> >>>>It's always good to have an FM handy... :) >>> >>>Thanks. >>> >>>The question is where you worry about. If you have a 5 men EGTB already who >>>cares about extrapolating 4 men info from a 5 men egtb? >> >>The idea is simple -> deep in the search or in the qsearch I have only my 4 men >>bitbases... it's good to have exact results here for some 5-men... :) I can >>guess sometimes even 6, 7 or 8men results... I am quite sure that it will work, >>but as I have said in another post -> when it is programmed I will present some >>results... (If it works like I hope it should work...) -> in that respect kb*kp* >>is now the first really interesting recognizer / special endgame I am >>programming... but there is more to come... :) >> >>Greets, Thomas > > You risk an evaluation error which is real huge when you evaluate something > to a win which in fact isn't a win :) which is to prevent, of course... at the moment it evaluates a win where it is DEFINITELY a win, a draw where it is definitely a draw and a maybe win, well, where it maybe wins... the last position is simply scored usual with a little bigger tendency to 0... look at my example, it works quite well... :) -> if the white site make a mistake, Quark sees that instantly... and it has no negativ effects so far... (The only problem currently is, that the eval of the special endgames (and they are a growing number) must fit somehow to the old eval... but that is solveable, maybe not until Paderborn, but it can be done...) So far even when I have not nearly programmed the full set of 4men+ endgame-recognizers and routines I usually gain 1-2 plys in every late endgame and it starts to find solutions now one ply earlier. One thing I hope is, that I can probe lesser in the 5 men endgame-tablebases which might help me with another extra ply... And of course Quark learns with this a lot other stuff, which it did not know before (at least not where it can not use the nalimov tbs) -> e.g. that queen against two minors wins quite often and some other basic rules... Older version did score e.g. KRBKR simply as draw, the current version takes now a bit care not to stay in the edges... -> Also all those special endgames help to make the normal evaluation easier to maintain, because all those exceptions can be deleted... This way it speeds Quark even up... And one last point: This is fun... :) Greets, Thomas
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.