The idea is that the performance impact must be nearly unnoticeable. But for this I will need help in testing. Writing code takes 1 hour, testing usually 5 ...
Pascal 2009/7/1 Julio Pietropaolo <jpietropa...@gmail.com> > This is just my opinion. > One of the things that i love of Scid is that it's really fast... and its > bases are really small in size. > If adding this long game support means losing speed in searches, increasing > the size and so... mmmm I don't knows if the advantages will justify the > lose of performance, but its just my opinion... > I have a 1.400.000 games database and no problems at all with the current > features, its not about to write a "book" of a game and save it to a > "working" database. > > > > Pascal Georges escribió: > > My short answer : > > I can now load long games, but one Alexander sent to me takes 10 seconds to > load in PGN window (parsing, colorisation, etc). This game has a length of > 77 kB, so I will set a hard limit at 128kB, any higher value is hardly > usable. > > Concerning the extra fields in a game, there are 2 kinds : > - a field that belongs to the index (like a marker tag). Drawback : it is > present for all games, even those that does not need it. Hence it has to be > strictly limited and should only be used for short information with a wide > usage (a "tactics" bit is ok here) > - a free field (like a PGN header [WhiteCountry ...]) is far better for > such data and can be searched through the already existing search features > of Scid. > > So right now I see nothing to add to the game index. > > Pascal > > 2009/6/30 Alexander Wagner <a.wag...@physik.uni-wuerzburg.de> > >> Pascal Georges wrote: >> >> Hi! >> >> - on average a game takes 200-300 bytes (reference base with some >>> annotated games) >>> >> >> This could be, sure. Especially for unannotated games. >> >> - current Scid's limit is 64kB for a game (this means 30 games can fit >>> in a disk block), which with the usual size of a game seems really >>> enough for me >>> >> >> - the few examples of very long games I got so far (some time ago) >>> were uselessly and artificially long (whispers / kibitz, rarely >>> interesting) >>> >> I think one might most likely hit the wall in case of >> commentary in prose, am I right? Just as this text gets no >> compression at all, I guess. In that case could one possibly >> store textual commentary outside the games blocks to improve >> performance and work with some sort of pointer to the >> external text? Just an idea, I don't know Scids internal DB >> organisation. >> >> One usecase for "rarely interesting" kibitz/whispers is some >> sort of "social aspect" in CC gameplay as I was told about >> from some Club members. They really play a game while >> chatting with each other. Here "chat" in the sense of >> instructural "chat". (I think this could be a usecase in FICS >> as well but I do not really play on FICS that much.) >> >> If yes, what are the other changes to introduce in Scid's >>> base format ? Please be very precise and concrete here >>> (not "add extra markers to a base" or "cache the most used >>> searches"). >>> >> >> Well you name two points ;) A bit more to the point... >> >> This is just a list it should be checked what's feasable. >> But this are points where I stumble upon some limitation in >> the current format and in daily use not in esotheric cases >> ;) >> >> In CC I have some game associated metainfomation that would >> be suitable for Flags. E.g. there're tournaments with as >> well as without engines. Thematic tournaments that start >> with a given position (implemented by a move sequence, not >> by a FEN, so you can't find them by searching for >> nonstandard staring position ;), games that do not allow for >> tablebases, stuff like that. To keep record of this kind of >> information I think a set of "per base definable flags" >> would be helpful. Say an array of user flags that I can >> define to a meaning by some sting on the level of a certain >> base. I could then define e.g. "no engines" to "baseflag 0" >> and set this flag for games without engines and clear it for >> games with engines allowed. (Currently, I work around this >> by a similar construction that lives in CC code only.) Now >> this flag would not make sense outside the CC games base, of >> course, therefor it would be some sort of local flag. >> >> There should definitely be a flag for mode. OTB and CC are >> quite different. This also goes with some tag for the time >> control. Suggested is the [TimeControl ""] tag in the >> header like >> >> [TimeControl "2592000+86400"] >> >> (30d + 1 per move for a Fischer clock e.g.) >> >> Also for my Ref bases I'd really appreciate some flags I >> could set. Currently I use combinations of flags for certain >> information. (E.g. I set brilliancy + blunder for games I've >> an annotation in a book that does not talk about a specific >> point in the game but found it remarkable for several >> reasons. This works but it is not nice and surely is only a >> workarround. And it defies me of marking my personal >> brilliancies...) I use flags mainly to speed up searches for >> specific informations. Especially, for hooking up my printed >> literature with my reference base. >> >> To keep a refbase up to date it would be worthwile to >> support tow additional fields "Source" and "Date added". >> Currently, I set those in additional header fields, but I >> think this could be more compact if some encoding is used >> that refers to some internal authority. >> >> Concerning Metadata: there's some small company in northern >> germany that produces databases which add additional >> information to the header like >> >> [whiteCountry "ENG"] >> [whiteTeamCountry "ENG"] >> [whiteTeam "II"] >> [whiteIccfID "123456"] >> [whiteFideID "123456"] >> [Source ""] >> [SourceDate ""] >> >> This is most likely not complete. It could be worth while >> to look at what's used there these days and support it >> adequately. >> >> Also for hooking up my printed literature (there is a lot, >> IMHO it would be worth to take this fact into account) I >> found it very convenient to add tags to the header. You may >> remember that I currently use [Ref ""] lines for this >> followed by [Ref1 ""] and so on if I've a game that is >> discussed in several source from differnt perspectives. This >> is far from perfect. I admit that I'd greatly appreciate >> some numerical flag (unsigned int) that could hook up with >> some normalised Note field, like you use it in scientific >> literature once you cite another work. Say, the "Evergreen >> Game" is discussed by Kasparovs in his series and Burgess' >> et al. Now, I'd like to be able to attache some [1] [2] >> where [1] gives the full reference of Kasparovs book while >> [2] the same for Burgess book. It does not have to be a book >> that is referenced here, it could be any note in prose about >> common points within a game. >> >> For a new file format it would be great if it could also >> know about some archiving/transport format that consists >> only of one single file. This single file could unfold on >> the target system to the usual set. (This function is >> similar to cbv.) >> >> One function I missed is already tackeld by the Masks. I'm >> not sure if it might not be possible to use the Mask input >> also for the caching. Like installing an opening key in CB? >> I did never work with CB itself, but as far as I got it I >> like the idea to install opening keys (caches for those >> openings one is most interested in collecting all games that >> are of interest in this area) as well as endings and tactics >> or startegic motives. Those "specialised caches" whould be >> most helpful for a reference base of course. >> >> One point I'm not at all clear about is actually concerned >> with game metadata again. I wonder if one could not use some >> sort of authority records for player/event/site names >> instead of the written strings. This would surely have a >> larger impact on the structure. However, IMHO it would ease >> up the spell checking stuff and one could come up with a >> plain soution to find Jussupow - ah in english Yusupov. >> Just to give some name I always forget the spelling used... >> He would just be 1234567 and Scid could draw the spelling(s) >> from the ratings file e.g. (Could be advisable that the >> spelling is stored in the DB for the case no rating file is >> present.) I use this feature a lot in my daily work with >> books and miss it in Scid. (German librarians love authority >> records...) >> >> -- >> >> Kind regards, / War is Peace. >> | Freedom is Slavery. >> Alexander Wagner | Ignorance is Strength. >> | >> | Theory : G. Orwell, "1984" >> / In practice: USA, since 2001 >> >> > ------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------ > > _______________________________________________ > Scid-users mailing > listscid-us...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/scid-users > > >
------------------------------------------------------------------------------
_______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
