Author: Alexander Kure
Date: 12:38:18 11/19/99
Go up one level in this thread
On November 19, 1999 at 14:56:11, Vincent Diepeveen wrote: >On November 19, 1999 at 14:33:26, Alexander Kure wrote: > >>On November 19, 1999 at 13:57:01, James Robertson wrote: >> >>>On November 19, 1999 at 06:29:39, Alexander Kure wrote: >>> >>>>Hi, >>>> >>>>There were some postings recently about Nimzo 7.32's handling of simple standard >>>>engames like KR-K, KBB-K, KBN-K where Nimzo 7.32 was not able to deliver mate. >>>>Well, the reason is quite simple: As long as the 3 and 4 piece endgame >>>>tablebases are installed and properly loaded when starting Nimzo 7.32, he will >>>>have no problem to mate. Now the question is what happens to Nimzo when >>>>confronted with these kind of endings where he has no access to endgame >>>>tablebases at all? The answer is quite simple: *All* endgame code regarding >>>>these endgames was removed from Nimzo 7.32. So when deprived of access to 3 and >>>>4 endgame tablebases he has *absolutely* no idea what to do as there is no code >>>>in the evaluation to tell him what to do! >>>>Of course one can argue that this is nonsense and Nimzo 7.32 were to keep his >>>>endgame knowledge no matter if he uses endgame tablebases or not, but in the age >>>>of tablebases it seems not necessary anymore. >>>>You can test this with Nimzo'99, who still has this code and who has no problem >>>>to mate KR-K, KBB-K and KBN-K. >>>>So instead of using Hiarcs 7.32 as your alternative endgame engine maybe you >>>>could give Nimzo'99 a try ;-) >>>> >>>>Greetings >>>>Alex >>> >>>To be quite honest, I think this is either false or a dumb idea. It has already >>>been posted that Nimzo's tablebases don't give the distance to mate; therefore, >>>they are useless for mating. For instance, almost every KRK position will say >>>"mate!". That is wonderful, but if the winning side decides to move his king to >>>a1 and his rook to h8, he still has "mate!" in the tablebase scores. And if King >>>on a1 and rook on h8 is just as good as any other KRK position, Nimzo will never >>>make progress. Therefore, Nimzo _must_ have some other mating scheme. >>> >>>Also, you can replace Nimzo's entire KRK tablebases with one line: >>>if (losing_side_pieces==KING && winning_side_pieces==KING+ROOK) return MATE; >>> >>>And save a TON of space. That is why I think that the tablebases for some >>>positions (KQK, KRK, KBK, KNK, KBBK, etc.) are not such a good idea. >>> >>>James >> >> >>Hi James, >> >>Maybe there is some misunderstanding, so i will try to clarify: >>Nimzo is accessing the Ncd-Endings in the quiescence search. As this is a memory >>(not a file) access it should be faster than even calling the eval function. >>So when detecting a won ending, like e.g KR-K the search stops there knowing it >>is won. Back again at the root (i.e. ply 1 -n where n is a set by the user) when >>it really comes to the position Nimzo 7.32 uses Nalimov in order to determine >>the fastest winning move. Maybe you were confused by assuming that Nimzo 7.32 >>uses *only* his endgame tablebases, but of course this is not the case, as you >>already suspected. > >What are 'ncd-endings' in the qsearch? > >Suppose we exchange to KRP KR somewhere. >How much RAM is my machine at the SSDF list suppose to have to >have it faster available than an evaluation? > >If it isn't accessing disk, which is roughly a 400,000 times slower than >RAM, then i have a problem believing this. > > > >>Greetings >>Alex Hi Vincent, Actually all ncd endings (3 and 4 pieces) need app. 11 MB. Greetings Alex
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.