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

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

Ethan A Merritt wrote:
> On Sunday 01 July 2007 20:10, Daniel J Sebald wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>On Sunday 01 July 2007 16:41, Daniel J Sebald wrote:
>>>
>>>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?  
> 
> 
> Oy. Now I really do give up.  This was the entire original point of the exercise.
> The hotkeys 'e' 'a' 'n' 'p' and 'u' and mouse zooming stopped working for Octave.
> I have tried to make them work again.  

I'm not as lost in space as you are trying to imply.  Quite aware of the issue, just hadn't heard 'e' bandied about.


>>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?

> For this particular use it is not particularly important whether the
> zoom/unzoom also updates.  But if it doesn't, you'd want to force an
> update first using the 'e' key.

So, it isn't important, in this case, that the zoom/unzoom rereads data, which was my point.  'e' fits the bill.


>>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.    
> 
> 
> I am finding this discussion rather frustrating, because you don't seem
> to read either the patch documentation or the (2? 3?) explanations I 
> have offered for longer term plans.  In fact I think that long-term
> log/unlog will cease to be a special case, and no special measures
> will be needed to handle it.

I'm dogmatic because I don't believe it.


>>I'm not seeking perfection, but I'm saying there are too many 
>>compromises with the approach, especially when there is an alternative. 
> 
> 
> You have proposed an alternative, but you have not convinced me it
> will work.  Are you planning to finish off a complete alternative
> patch any time soon?  I thought you were bowing out of the project,

Yes, a month ago I said I'll be making changes in my life so I was trying to give developers an opportunity to integrate any patches I had remaining on sourceforge so I could address any concerns.  Patches that fix current bugs.  Ones I'd been asked to "pick a bug and fix it".  Etc.  Over the course of a month did any of them get consideration?  No.  When someone volunteers their time, should make good use of it.

And why ask for a review of your patch if you aren't willing to hash out any concerns, like the splines problem and the un-resampled FUNC data?  You are rushing your patch toward CVS whereas with other patches you've been measured and cautious.


> but if you are about to present a complete alternative solution
> I'm willing to hold off and run side-by-side tests on the two
> alternatives to evaluate pros and cons.

I'll put a complete patch in sourceforge.  Evaluate as you wish.  End of discussion.


> The problems I have with your current prototype patch include:
> 
> - It adds a whole new layer of data storage that at a minimum
>   doubles the space required.  In fact I think it will turn out
>   to be much worse than doubling by the time all plot types and
>   input alternatives are handled.
> 
> - The comments do not match the actual code.  For instance, the
>   comment at the top says that it does away with the df_eof 
>   mechanism.  But it doesn't.  In fact it breaks it entirely,
>   so far as I can tell by reading the patch.  Have you really
>   tested this?

Sure, df_eof is simply a global variable.  That information is already passed back by df_readline().  Don't need the extraneous global.  It's still used inside datafile.c of course.


> - It doesn't handle strings or expression evalution involving
>   strcol().  This may or may not be a killer.

I'll attempt to fix that.

The thing is, I don't think strings will work with the method you are proposing without additional code.  The x,y,z values of the labels are gotten in get_data() as:

case LABELPOINTS:
    /* Load the coords just as we would have for a point plot */
    store2d_point(current_plot, i, v[0], v[1], v[0], v[0], v[1],
                  v[1], -1.0);
    /* Allocate and fill in a text_label structure to match it */
    store_label(current_plot->labels,
                &(current_plot->points[i]), i, df_tokens[2], v[3]);
    i++;
    break;

But your patch is circumventing get_data().  So how is it that the values in the strings will have their x,y,z updated when the axis scale is modified?  Put a loop inside refresh_request() to update the x,y,z of strings as well.  But at what point does refresh_request() become an almost full reimplementation of the code inside plot2d.c?


> 
> - It doesn't actually provide any advantage over the current
>   "refresh" patch other than toggling the log scale.  If I'm
>   wrong about that, please provide a test script so that I can
>   understand the difference.  

The splines smoothing/curve fitting.  E(L(X)) may equal X, i.e., reversible axis transform.  But E(S(L(X)) != S(E(L(X))) = S(X).

The FUNC data is always resampled so that this works as expected.


>   You mentioned smoothing, but I  think you are off the mark there.
>   That is not an option you can change via replot in the first
>   place.  You would need to construct a whole new plot command.

No, but logscale is.  And if the roadmap is to allow logscale to work with refresh, with something like

plot "foo" with lines <smoothing option, I forget keyword>
set logscale x
refresh

the data comes in and is stored in "points".  Then smoothing code alters "points".  After that the data cannot be transformed between axis scalings anymore because it has been altered inside "points".


>   You do bring up an interesting point with regard to the 
>   sampling interval of functions.  If the sampling interval is
>   too coarse, then we may notice a difference between the two
>   approaches.  But I think I can bump up the sampling interval
>   in advance if I know that 'refresh' will be used for zoomin.
>   Thanks for that observation.

Not a good solution.

Dan