From: Ville Hakulinen [mailto:ville.hakuli...@iki.fi]
Sent: Tue 16-11-2010 13:40
Hi,
> Hi all,
>
> Currently I'm using Scid's training feature to collect lines
> to a repertoire database and this works fine, but it would
> be nice to be able to easily get the most common line that's
> not covered by the repertoire.
>
> So let's say I have two databases: A is built up from a game
> collection and B (repertoire database for black) contains
> just one game with the moves (1.e4 c5) in it. And let's also
> say that in database A 1.e4 occurs 46.7% of the time, 1.d4
> occurs 35.3% of the time and after 1.e4 c5 2.Nf3 occurs
> 81.3% of the time.
How about games in A with the move order 1.Nf3 c5 2.e4?
> So 1.e4 c5 2.Nf3 occurs in 46.7% * 81.3% of the games
Hm, I do not think so. What about al those black alternatives
to 1... c5? These are included in the 46.7%, right? Or are all
games in A that start 1.e4 already filtered to Sicilians only
(obviously your choice of play with black)?
> which is about 38%. So when asked to play the most common
> line not in B, Scid would play 1.e4 c5 2.Nf3 since that's
> more common than 1.d4.
What does "play" mean?
>
> So let's assume we insert a game with 1.e4 c5 2.Nf3 d6 into
> B. Now we see that 1.e4 c5 2.Nc3 occurs about 3.9% of the
> time and 1.e4 c5 2.Nf3 d6 3.d4 occurs about 30.8% of the
> time, so this time Scid would ask for a reply to 1.d4.
Do you mean 3.d4 (30.8%), or 1.d4 (35.3%) indeed?
So far words and statistics ...
Your story sounds pretty interesting, but I do not get it
completely.
What is the ultimate goal of the operation? Build a collection
of games in B? Build a single game with variations (a tree) in
B?
Assuming you go for the tree model for B, I understand that,
looking from a certain position in B, you want to add the most
frequently occurring position from the tree of A that is not
yet in B, into B. Right?
Your percentages are confusing, since what does represent 100%
in your case? Is it all games in A, or all games having the
current position in A? It seems to be the latter, so your
search algorithm has a strong preference to include those long
only-move (drawing) lines as soon as they appear on the
horizon. Funny.
I am also not sure where the operation is supposed to look in
the B-tree. This is caused by the start of your scenario.
Let's start with an empty tree B. What would happen then?
I guess the operation will - from the initial position (IP) -
first add 1.e4 to B; and then? Should it compare 1.d4 (next
best IP) to 1...c5 (best 1.e4)?
And then it should walk through all three positions in B and
compare (e.g.) 1.c4 (next next best IP) to 1...c5 (best 1.e4)
and 1...Nf6 (best 1.d4)
Etcetera.
The number of lookups in A increases rapidly ;-)
What should make the operation stop?
How should transpositions be handled?
Do you need any meta-data from A in B?
I did not even experiment yet with tree masks, but they seem
to be powerful. Could they mean something for you?
Regards,
Joost.
> And so forth.
> --
> Ville
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
