Re: [Scid-users] Tree windows
Michal Rudolf wrote: When the user want to move back or forward and the tree windows is still busy: 1) cancel the current search and starts the new one 2) schedule the new search but ends the current search too My preference went to 2, considering that so results are computed and cached. I used first approach in ChessX. I agree with Alexander that it is more user friendly (less delay). Yes, probably best. Another question: why the tree modify the filter? Is this usuful? Sometimes i search all the games of a particular player (usually an opponent). Then i open the tree window (forgettin to copy the games to the clipbase) and, voilà, my search is gone! Really annoying. I think it will be better to leave the filter untouched, what do you think? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
2010-03-30 15:17:23, Fulvio: Another question: why the tree modify the filter? Is this usuful? Sometimes i search all the games of a particular player (usually an opponent). Then i open the tree window (forgettin to copy the games to the clipbase) and, voilà, my search is gone! Really annoying. I think it will be better to leave the filter untouched, what do you think? That's why I loved 'dataset' idea from old Chess Assistant. Basically, you could make any of your filters permanent, limiting all operations to that dataset (until it is removed). Then, setting the filter by Opening Tree is not a problem - single shortcut and you are back to your search result. Same for researching your opponent's openings - choose a dataset containing only his games and trigger Opening Tree on these games./ -- Michał Rudolf -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
Michal Rudolf wrote: Hi! ... the point is IMHO not that much the amount of disk space, I think this is a non-issue these days, but the actual time it takes to write out the cache to the disk. Given a larger base (about the size of a usual reference base) this takes some time, indeed. How much time is it? I'd have to measure it but several seconds. If you know that it does it it is ok, but I don't think it's ok all the time, as Scid also writes the cache if the file was just opened, as far as I understood it. I admit that this is the reason why I actually switched off the autosave function an instead placed a quite extensive indexing scheme to Scid once I update those bases. I might add that my reference bases don't even live on a network, but on a not too bad local drive. What do you mean by extensive indexing scheme? Pre-generated cache? Yes a pregenerated cache (fill cache) resulting from some 3500 lines. One idea is to store ply number of the last non-unique position in each game. But, this will require quite expensive indexing when database is modified. I think the major issue is that you can come back to a well known position by transpositon. Therefore, it can well be that no really good solution exists here, especially not a perfect one. That why you would need to search a whole game, making the process quite slow. I fear that. -- Kind regards,/ War is Peace. |Freedom is Slavery. Alexander Wagner| Ignorance is Strength. | | Theory : G. Orwell, 1984 / In practice: USA, since 2001 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
Fulvio wrote: Hi! When the user want to move back or forward and the tree windows is still busy: 1) cancel the current search and starts the new one 2) schedule the new search but ends the current search too My preference went to 2, considering that so results are computed and cached. I used first approach in ChessX. I agree with Alexander that it is more user friendly (less delay). Yes, probably best. Another question: why the tree modify the filter? It did not for a long time. From the ChangeLog for 3.7: - Tree window : when a Tree is updated and the current base is not the Tree's one, the Tree base will automatically load the first game in the filter (so by switching to the Tree's base, the position is already set to the previous one and for example an Opening report can be immediately generated) If I remember correctly changing the tree bahaviour concerning the filter had such an idea in mind however I did not find the specific reason in ChangeLog. Maybe I missed it. Plus, there is some point relating to history, but I'm not sure if it is involved here. In former versions Scid allowed only for one tree window which was usually locked to the current base unless you explicitly said it to be otherwise. I remember vaguely that Pascal mentioned that it was not too trivial to enable multiple trees. (And they're very useful, indeed.) Is this usuful? Depends. Probably, if you think in the direction of opening report generation it is useful. Similar, if you want to have some drill down, say from a specific position (set by the tree window) narrow down to games of a specific player or whatever by header search. Sometimes i search all the games of a particular player (usually an opponent). Then i open the tree window (forgettin to copy the games to the clipbase) and, voilà, my search is gone! Really annoying. I agree, similar things are the usecases where I find it annoying myself, but as there were no complaints about the behaviour on the list I thought I'm the only one. I think it will be better to leave the filter untouched, what do you think? Probably this would be better together with a menu like set filter to tree contents. (The latter could also be accomplished by position search, however.) I like Michals idea of datasets btw. I don't know CA, however, therefore, I'm not sure if it could be accomplished by Scids saved search functions say, writing a saved search and recalling it. It sounds like a possibility to me. -- Kind regards,/ War is Peace. |Freedom is Slavery. Alexander Wagner| Ignorance is Strength. | | Theory : G. Orwell, 1984 / In practice: USA, since 2001 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
2010-03-30 18:17:17, Alexander Wagner: I like Michals idea of datasets btw. I don't know CA, however, therefore, I'm not sure if it could be accomplished by Scids saved search functions say, writing a saved search and recalling it. It sounds like a possibility to me. The only requirement is to introduce one more level of enumerating games in database. After choosing a dataset, the database should behave as if it contains only games from the dataset. So, that will require some internal changes (but no database format changes and almost no GUI changes). No, saving a search is not enough, as this just stores search parameters and is not very useful. What we need is just making the filter permanent. -- Michał Rudolf -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
2010-03-22 17:33:18, Alexander Wagner: 1) Sometimes it get stucked leaving me with a waiting mouse icon Agreed, specially when you use mouse wheel to scroll through the game. When the user want to move back or forward and the tree windows is still busy: 1) cancel the current search and starts the new one 2) schedule the new search but ends the current search too My preference went to 2, considering that so results are computed and cached. I used first approach in ChessX. I agree with Alexander that it is more user friendly (less delay). Still, there might be an issue here with how the fill cache function works. I don't think that there is a side effect but you should be careful not to break it. If the cache is updated only after full, successful search, no break will happen. BTW. is it possible to enable 'Auto-Save Cache Buffer option by default? Now it seems the cache content is lost when one forgets to set it. As we already have the option to set cache size, I suggest to just drop the option and always save cache (letting user to set a very small cache if he is concerned about disk space). Some in the opening where the tree is very helpful and should be updated, some in the middle or endgame where ther're just no games anymore. Do you see an automatic way to prevent Scid from continually updateing the tree here? One idea is to store ply number of the last non-unique position in each game. But, this will require quite expensive indexing when database is modified. -- Michał Rudolf -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
Michal Rudolf wrote: Hi! Still, there might be an issue here with how the fill cache function works. I don't think that there is a side effect but you should be careful not to break it. If the cache is updated only after full, successful search, no break will happen. BTW. is it possible to enable 'Auto-Save Cache Buffer option by default? This would surely be possible ... Now it seems the cache content is lost when one forgets to set it. As we already have the option to set cache size, I suggest to just drop the option and always save cache (letting user to set a very small cache if he is concerned about disk space). ... the point is IMHO not that much the amount of disk space, I think this is a non-issue these days, but the actual time it takes to write out the cache to the disk. Given a larger base (about the size of a usual reference base) this takes some time, indeed. I admit that this is the reason why I actually switched off the autosave function an instead placed a quite extensive indexing scheme to Scid once I update those bases. I might add that my reference bases don't even live on a network, but on a not too bad local drive. Additionally, one would have to disable it if the base is read only. (I'm not sure what happens now, I'll have to check.) From this I'd guess that it would make sense if autosave cache is a property of the base in question, but I think this would change the db format to allow to store this flag. Some in the opening where the tree is very helpful and should be updated, some in the middle or endgame where ther're just no games anymore. Do you see an automatic way to prevent Scid from continually updateing the tree here? One idea is to store ply number of the last non-unique position in each game. But, this will require quite expensive indexing when database is modified. I think the major issue is that you can come back to a well known position by transpositon. Therefore, it can well be that no really good solution exists here, especially not a perfect one. -- Kind regards,/ War is Peace. |Freedom is Slavery. Alexander Wagner| Ignorance is Strength. | | Theory : G. Orwell, 1984 / In practice: USA, since 2001 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
2010-03-29 17:21:42, Alexander Wagner: Now it seems the cache content is lost when one forgets to set it. As we already have the option to set cache size, I suggest to just drop the option and always save cache (letting user to set a very small cache if he is concerned about disk space). ... the point is IMHO not that much the amount of disk space, I think this is a non-issue these days, but the actual time it takes to write out the cache to the disk. Given a larger base (about the size of a usual reference base) this takes some time, indeed. How much time is it? I admit that this is the reason why I actually switched off the autosave function an instead placed a quite extensive indexing scheme to Scid once I update those bases. I might add that my reference bases don't even live on a network, but on a not too bad local drive. What do you mean by extensive indexing scheme? Pre-generated cache? One idea is to store ply number of the last non-unique position in each game. But, this will require quite expensive indexing when database is modified. I think the major issue is that you can come back to a well known position by transpositon. Therefore, it can well be that no really good solution exists here, especially not a perfect one. That why you would need to search a whole game, making the process quite slow. -- Michał Rudolf -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
Re: [Scid-users] Tree windows
Fulvio wrote:
Hi!
I always have the tree windows opened when using scid.
I have two problems:
1) Sometimes it get stucked leaving me with a waiting mouse icon
2) I need to wait that the current search ends to move to another position
Agree on this point.
I want to correct that
Great! :)
and would like to have your opinions on which
behavior is better.
When the user want to move back or forward and the tree windows is still
busy:
1) cancel the current search and starts the new one
2) schedule the new search but ends the current search too
My preference went to 2, considering that so results are computed and
cached.
Giving the fact that the reference base in question might be a several
millions base where all this searching takes a while I tend to go for 1,
as 2 might be quite slow.
Still, there might be an issue here with how the fill cache function
works. I don't think that there is a side effect but you should be
careful not to break it. The other function that might have a side
effect is Fill mask with base as this would currently also create a
nice cache for a mask and this is actually desirable, I think. And at
least fill mask seems to work by just moving through a game in autoplay.
I'm not sure about how fill cache is implemented. As far as I understood
it you need to jump to each relevant end position, that's why
treecache.dat looks like
{}
{1.e4}
{1.e4 e6}
{1.e4 e6 2.d4}
{1.e4 e6 2.d4 d5}
{1.e4 e6 2.d4 d5 3.exd5}
and so on.
For example i can scroll fast the first 10 moves of a game, so when i
come back i have an instant cached result.
However i'm trying this solution but it's a bit weird: until all the
searches are ended results unrelated to the current position on the
board are displayed and you can't click on the tree windows to select moves.
I think, that the user should definitely see what he expects to see
right away that's why I think your option 1 would be nearer the mark.
Additionally, you'll not always want to fill the cache. If you can pull
his search to the front and move the other ones to the back it would
probably be ok, but I'm not sure about this scenario. In my actual
gameplay I've games in several stages where I switch to and fro. Some in
the opening where the tree is very helpful and should be updated, some
in the middle or endgame where ther're just no games anymore. Do you see
an automatic way to prevent Scid from continually updateing the tree here?
--
Kind regards,/ War is Peace.
|Freedom is Slavery.
Alexander Wagner| Ignorance is Strength.
|
| Theory : G. Orwell, 1984
/ In practice: USA, since 2001
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
[Scid-users] Tree windows
I always have the tree windows opened when using scid. I have two problems: 1) Sometimes it get stucked leaving me with a waiting mouse icon 2) I need to wait that the current search ends to move to another position I want to correct that and would like to have your opinions on which behavior is better. When the user want to move back or forward and the tree windows is still busy: 1) cancel the current search and starts the new one 2) schedule the new search but ends the current search too My preference went to 2, considering that so results are computed and cached. For example i can scroll fast the first 10 moves of a game, so when i come back i have an instant cached result. However i'm trying this solution but it's a bit weird: until all the searches are ended results unrelated to the current position on the board are displayed and you can't click on the tree windows to select moves. What do you thinks? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
