Pascal Georges wrote:
Hi!
> This means another option in an overcrowded dialog box
> (that even does not fit in low resolution screens).
Life is a complex thing. Nobody ever stated it is simple.
> Is it a really useful thing ?
Up to discussion, thats why I worte this mail anyway ;)
I'd find it useful, but I'm always with Mark Twain: if
you're ever on the side of the majority you should stop and
think about it. ;)
My point is, that you may have added your own annotations to
a game you actually played. What I have in mind is a
correspondence game that is played "without engine support".
(Even if I spent some time to the evaluation I might be
wrong. Acutally, being a slightly weaker player than
Kasparovs this happens quite often that I'm wrong.) Here,
things might get _really complex_ if the engine throws in
it's main lines at every other point, plus probably
crosschecking with another engine... However, the engine
eval values in the graphical display might be very usefull
to identify a blunder one made. To graph it, well one needs
the values first. One could then probably check in more
easily on the real points. And to get an estimate value I
can run the engines at a very short time limit and then
explore deeper at the crucial points.
> But feel free to add it if you want (maybe using notebooks
> widget in Tk 8.5).
I do not think a notebook is suitable there. It would make
the interface difficult. (Don't get me wrong, I like
notebooks, I come from OS/2, where the WPS uses them
extensively.) Besides AFAIK you added this dialogue, I'll
hardly code within it anything without discussing it first
;)
I think one could use drop down lists instead of the pretty
space intensive radio buttons, like for the one used for
the opeing book selection. It could look like this:
Add annoations:
For moves by both sides [V]
For white moves only
For black moves only
Annotate all moves [V]
When game move is not best move
When game move is a blunder
Only score
What do you think? That would save quite some space without
making it difficult to use and woudl also shorten the
dialogue for CE.
> - To have a "full" score graph, adding the engines evaluation
> even if the best line is played (by the engines thinking)
> would be helpful. One probably might want to add
> engine-lines only in case of "not best line played".
>
> I thought those options already exist !?
You can set "annotate all moves", right, but you'll then get
the engines line as well, not just the value.
> That's right, but in some cases the user may want to annotate the game
> up to the last move, and let it analyze the last position. So this would
> mean yet another option ...
I admit, that I thought about a checkbox for "stop after
last move" as you say both behaviours may be wished for.
> - Annotate several games: besides specifying a number, it
> might be a very good thing to annotate the games in the
> filter. (E.g. if you have ongoing games in a base and you
> want to auto annotate those finished only.)
>
> Another option ...
Probably using a radio?
Annotate seveal games
[*] Filter [ ] from current to [spinbox]
> - NAG values are currently added on the basis of the current
> positions evaluation and not according to the difference
> to the position before the current move. This results in
> a sequence of moves all getting e.g. "=" or "+/-" or
> whatever. I feel, only the move that led to equality or
> superiority should get the NAG value attached to it. (Is
> the current behaviour actually a bug or a feature?)
>
> A feature.
Is it really common to NAG _every_ move once the position
changed at some point and the advantage just stays? I never
saw this.
> - Considering exporting the games to some paper version it
> might be a good idea to add a D NAG if a larger change in
> the evaluation is found. Most likely a critical position
> might have been solved here. Probably this correlates
> with the addition of difference based NAGs?
>
> I never use export functions for reviewing games, given Scid is far
> better for that. But feel free to add this.
This is right, but there're some reasons to export. Think of
the Clubs journal published as PDF e.g. or just getting some
paper while on the train or ...
> Except on Pocket PC, Multi PV mode has little impact on
> performance (after the first couple of seconds). But if
> you have any figures...
Hm. If the engine processes evaluation along one line it
uses full performance on that single line, 100% CPU time
invested into this single line. If it has to calculate three
lines, it has 1/3, netting a 15s evaluation to 5s. This does
not necessarily mean that you "see" it on a 3GHz CPU and it
might be the reason why you see it on your CE.
Still it should not overwrite my setting ;)
> I feel there's a slight "bug" in UCI init code, ie.
> multi-PV is always reset to the value in engine config and
> not the value currently set by the user in the engine
> analysis window. Ie. if I set Shredder to use 3 lines in
> the engine config, fire up the engine, reduce this to 1
> stop and restart it it is reset to 3 lines in auto
> analysis.
>
> Of course, this is the correct behavior. The engine setup
> is there to be used.
Sure. I tell it "calculate 3 lines by default". Perfectly
sensible, the engine starts up with 3 lines. Then I reset it
to 1 line in the analysis window. Surely cause I had some
reason to do so. This should IMHO be respected.
> If you want a particular value for MultiPV, engine config
> is the place that has the highest priority.
I think, the highest priority should go to the user
overwriting the default in the analysis window itself.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
