Selon Alexander Wagner <[EMAIL PROTECTED]>:
> pgeorges schrieb:
>
> Hi!
>
> > I tried to extend the number of lines used to fill the tree cache (2000
> > lines from ECO classification). Then I ran it with a tree from a 3 M
> > games base : the cache would need several weeks to be filled (!).
>
> 3M means 3*10^6 I guess or 3.000.000 games. It would make me
> wonder if you could fill the cache in much less that that
> time. IMHO that's the point why one would need some user
> defined level as you can't fill every line into the cache.
> Additonally at some point I feel you'd not gain from the
> cache anymore as searching the cache would need the same
> time than searching the db.
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.
> > So I removed this, and added extra menus to fill the cache
> > corresponding to an opening base (with a few games, each
> > less than 100 moves).
>
> This sounds more resonable. But just to get it correctly.
> What you call an opening base means essentially a scid-db
> that contains just games for the openings one is interested
> in. The simplest idea to build such a DB would be to select
> all games for A00, and then cut the games to say 25 moves.
> Right? (Of course one would invest a bit more work into the
> creation of such a DB.) The result might be called A00DB.
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 :
1.e4 e6 2.d4
( 2.Qe2 {attaque Tchigorine} 2...c5
( 2...Be7!? )
3.f4 Nc6 4.Nf3 Nge7 5.g3 d5 6.d3 g6 {= renforce le contr�le de d4} )
( 2.Nc3 {var. 2 cavaliers} 2...d5 3.Nf3 d4!?
( 3...Nf6 4.e5 Nfd7 5.d4 c5 )
4.Ne2 c5 5.d3 Nc6 )
( 2.c4 {Steiner (anglo-fran�aise)} 2...d5 3.exd5 exd5 4.cxd5 Nf6 5.
Bb5+ Nbd7 6.Nc3 Be7 7.Qf3 O-O 8.Bxd7 Qxd7!? 9.Nge2 Rd8 10.Nf4 Bd6 )
( 2.f4 {La Bourdonnais} 2...d5 3.e5 c5 4.Nf3 Nc6 5.c3 d4!? 6.d3 Nh6 )
( 2.d3 d5 3.Nd2 {pour �viter l'�change des dames} 3...c5
4.Ngf3 Nc6 5.
g3 {indienne} 5...Bd6!?
( 5...Nf6 6.Bg2 Be7 7.O-O O-O 8.Re1!? )
6.Bg2 Nge7 7.O-O O-O 8.Re1 Qc7 9.Qe2 f6 )
( 2.Nf3 c5 3.d4 cxd4 4.Nxd4 Nc6 5.Nc3 Qc7 )
2...d5 3.Bd3
( 3.f3? dxe4 4.Nc3
( 4.fxe4?? Qh4+ )
4...Bb4!? )
( 3.Nf3? dxe4 4.Ne5 Nd7 5.Nc3 Ngf6 )
( 3.f3? dxe4 4.Nc3
( 4.fxe4?? Qh4+ )
4...Bb4!? )
3...dxe4 4.Bxe4 Nf6 5.Bf3 c5 6.Ne2 Nc6 7.c3 cxd4 8.cxd4 e5! *
> > This opening base contains my own book and the cache is
> > filled by walking through all moves and variations. The
> > timing is more reasonable (around one hour for each game).
> > Once done, the tree works instantly.
>
>
> 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. 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.
Pascal
-------------------------------------------------------------------------
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
