Re: Quick refresh [was: q for quit in plot windows]

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Sunday 01 July 2007 16:41, Daniel J Sebald wrote:
> 
>>The following is confusing to me:
>>
>>" The `volatile` keyword indicates that the contents of the data file
>>may be different if the file is re-read.  This tells the program to
>>use `refresh` rather than `replot` commands whenever possible.
>>
>>I assume "tells the program" means "tells gnuplot".  But beyond that, the 
> 
> interpretation of this is more left to the user.  OK, "volatile" is clear.  
> But for one user it may be desired that the volatile files be reread with 
> every new "replot", for another user it may be desired that the volatile 
> files not be reread.
> 
> Exactly. That's why they get a choice of whether to use the keyword
> or not.  If you know the data may change, but you want to zoom and
> play aroung with the the existing plot without reading in new data,
> then you plot it with "volatile".  This tells gnuplot to keep using
> the old data rather than reading in new data.
> 
> If you want to update the display with the newest available data every
> time you hit the 'e' key, then you *don't* flag it volatile.  Hmmm,
> yes I see that could be a bit confusing.  I'll ponder a better way
> to describe it.

Well, that feature makes sense.  Typing 'e' in the plot window will update the data?  That's nice.  I see that now, "builtin-replot".  However, I'd argue--given the "refresh" feature is in place--that zoom/unzoom and log/unlog should not ever reread from a file.  That's what 'e' is for.


>>In other words "volatile" is an accurate word, but implication is 
> 
> somewhat ambiguous. 
> 
> Feel free to suggest better wording, or even a different keyword.
> The basic point is to provide a way to say "reread every time"
> vs. "reread only when there's no other option".

zoom/unzoom/log/unlog keystrokes in the plot window always being "refresh" is fine with me.  No one should be using those features as a means to re-read a data file.  Is there an instance someone can think of where that is preferred?  In fact, it's kind of strange that anyone would want to reread data when zooming.  The question becomes "Is what I'm seeing a result of looking more closely or the data changing?"


>>The other thing I don't like is the "whenever possible".  I've been 
> 
> trying to make the point that unless there is precise behavior for this 
> feature the "whenever possible" is going to make the user or programmer 
> give up in futility because he or she won't know when datafiles are 
> actually reread.  "Not when log/unlog via mouse or set", "not when there 
> are splines", "not for this condition", etc.  
> 
> "The perfect is the enemy of the good".  For the last 20 years
> gnuplot has not allowed you to zoom volatile data.
> Mostly it's been a minor annoyance.  Now there's a reason to support
> it, since Octave sends data in-line.  But you are taking the extreme
> position that a patch to fix this is no good unless it also re-works
> log/unlog  axis rescaling. I just don't get it.

I've proposed a method that achieves the full spectrum of features, feeds data at the very front and runs it through the system so there is no concern about any different behavior having to do with splines or probably any future processing method.  It's just that I think that is the much preferred way to go.  Keep in mind I didn't start with this antithesis position.  I've tried different ideas for how to reuse the plot data, all with some problems.  I've eventually moved to the position that "save data from df_readline()" is the way to go.


> I'm perfectly happy to see the axis scaling cleaned up.
> But it's an orthogonal issue.  Besides which, in all the years that
> I've used gnuplot (less then 20 but more than 10 :-) I've never 
> wanted to toggle log scale with a hot key.  Is this really so 
> important to you?

No, I've not made great use of log/unlog, but there are fields where this would be the case,  spectrum analysis, time/frequency analysis.  But from a user's standpoint consistency is the issue.  The user isn't concerned about the innards of gnuplot, he or she just notices that zoom/unzoom works but not log/unlog when the data comes in from a pipe or at the command line.


>>I'd say drop the "volatile" keyword.  Then two methods are acceptable.
>>One, there are two commands "replot/refresh" in which "replot" *always* 
>>rereads files and "refresh" *always* retrieves the data from memory.  
> 
> 
> That is exactly what I implemented.  If you have found a case in 
> which it doesn't act this way, please report it as a bug.
> 
> The "volatile" keyword does not affect this.
> 
> Perhaps my documentation and description is inadequate, since you seem
> to misunderstand what the patch actually does.  I welcome your
> help in improving the documentation, but I do not agree with you that
> the log/unlog business is particularly relevant.  It's a footnote at
> best: "Please note that the 'l' and 'L' hotkeys are disabled if the
> plot contains in-line or volatile data".

You haven't said anything yet about the solution to the splines issue, or any future processing that a programmer may apply to the data which invalidates going back and forth between logarithmic, inverse and linear scales.  From what you have said above I'm gathering that now even long term you think that log/unlog on volatile data will not happen.

And there is the issue of the patch currently not resampling the FUNC data in refresh mode.  That one can be fixed in concept, but not easily without shuffling around some code so that one can get to the hunk labelled "second pass" in plot2d.c and plot3d.c.

I'm not seeking perfection, but I'm saying there are too many compromises with the approach, especially when there is an alternative.

Dan