[EMAIL PROTECTED] schrieb:
Good Morning! > The cache keeps a compressed filter associated with each > cached position. So once you have a pointer to an index > pointing to the filter, the search takes no time (you > don't have to go through all games to check if the > position present). So the more cache you have, the > better. One point is that RAM is limited. So at some point you'll start to swap out the data to the disk. Also you'll have to search the correct pointer. So my feeling(!) is that there has to be some "natural" limit beyond which you do not gain any performance. > What I call an "opening base" is a base containing a few > games (main lines) with a few moves in variations. For > example one game is the following : I'll have a closer look at this, but as far as I see it translates directly to repertoir files and is almost exactly the way I build them. I'll take your example and try to set up one. If I've some more time I'll have a look how to convert that, but it looks a bit recursive, and I frankly admit that I hate recursion and frear it like the devil the holy water (as we'd say in germany). >> That is now I open the 3M DB you mentioned in the first >> hand and say something like "fill the cache with the >> input from A00DB"? It will then search every position >> found in A00DB in 3M DB and add the games found to the >> cache. I guess if the games found by this procedure drops >> below a certain number (say 10 or 50, I do not know when >> direct searching gets as fast as cache searching) it does >> not follow the input tree any longer but moves on to the >> next game in A00DB. > > I don't use this approach. It was simplified a lot. But taking your opening base (now that I now what we're talking about here) the natural approach would be to go to each position in that base and fill the cache withe those. And I feel that most people would find that actually pretty usefull. > But I encounter another problem : Scid's Tree cache have a > hard limit : so if you fill a cache, some moves will be > rejected from it. To be clear, you can spend a lot of > time filling and saving the cache, but you may end with a > cache that is incomplete. Hm, I admit that it would be a very nice thing for the user not to have to dig in the code to find that valuable information... I think some "n lines left for the cache" (say if 95% is filled) would be some way to deal with it. The nice way would probably be to drop the limit. -- Kind regards, Alexander Wagner Universitaetsbibliothek Ilmenau Langewiesener Str. 37 98693 Ilmenau Tel.: 03677/69-4521 , Fax.: 03677/69-4617 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
