From: Ethan A M. <merritt@u.washington.edu> - 2007-07-02 04:38:21
|
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. The ruler and grid toggles stopped working also, but they could probably have been fixed in a simpler manner if that were the only problem. > 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? Yep. We use it often. We have long-running jobs that do simulations or stochastic refinement. If you plot the logged output, you can often tell whether it has found a likely solution yet or not. So we leave a gnuplot plot window on the workstation screen to monitor the history of the run so far. Often I run a little script in an infinite loop that replots every few minutes, but if you want to see the current status at any time you can just hit the 'e' key (or the replot icon on the wxt terminal). 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. > 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 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, 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. 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? - It doesn't handle strings or expression evalution involving strcol(). This may or may not be a killer. - 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. 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. 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. -- Ethan A Merritt |