#1890 Zoom retained across plot commands

None
open
nobody
None
2016-12-20
2016-12-19
Dan Sebald
No

With the latest development code (and Qt terminal) I find that zoom coordinates are retained across plot commands. Perhaps this is how it's always been, but I suspect users generally would feel that shouldn't happen.

To illustrate, try the following sequence:

gnuplot> set xrange [0:10]
gnuplot> plot sin(x)
[PERFORM A ZOOM WITH THE MOUSE]
gnuplot> set xrange [-100:100]
gnuplot> plot cos(x/5)
[NOW PRESS 'u' TO UNZOOM]

The result is

1) Upon the second plot, even though I specified a new xrange, gnuplot retains the zoom box coordinates for the prior plot.

2) Upon pressing 'u', the coordinates go back to the unzoomed coordinates of the first plot, i.e., [0:10]

This probably isn't a difficult change to make. I think the issue is more an agreement of what should happen in this scenario. I would think that upon the subsequent 'plot' command gnuplot terminals should erase all memory of the zoom and unzoom coordinates of the plot and place the terminal state into unzoomed.

Discussion

  • Ethan Merritt

    Ethan Merritt - 2016-12-19

    Are you sure?

    It is true that the "unzoom" command could be more accurately described as "return oldest previous zoom state", but I don't know when an explicit new set of ranges on the command line is ever ignored.

     
  • Dan Sebald

    Dan Sebald - 2016-12-19

    Well, yes that is the behavior, and it makes sense given what we were looking at the other day as far as setting the plot coordinates before calling the plot function again. This behavior doesn't work so well in practice. I have a setup that looks at various groups of data and I'm often zooming and then eventually go to the next group of data. But I don't ever think to unzoom the current plot before going to the next group of data. I can't think of a command to automatically put in the gnuplot input stream that would force the terminal to unzoom.

     
  • Ethan Merritt

    Ethan Merritt - 2016-12-19

    I think you should try your test again.
    No version of gnuplot that I remember works as you describe. If you set a new set of axis ranges on the command line, that's what you get in the next plot regardless of any previous zoom/unzoom history.

     
  • Dan Sebald

    Dan Sebald - 2016-12-20

    I just got the latest version. What I described is pretty much what happens, although there is a clarification. Upon doing the second plot, the xrange does come out to be -100:100, but the yrange is still zoomed instead of being auto-adjust. And the 'u' is as I described...uses the coordinates generated from the previous plot.

    I found a new bug. It must be polar plot. I'll add a note to your recent bug ticket.

     
  • Ethan Merritt

    Ethan Merritt - 2016-12-20

    [shrug] if you want a totally clean slate between plots, that's what the "reset" command is for. Otherwise I think it's reasonable to assume that if a user didn't clear the settings from the previous plot it's because they want to keep them. So I don't consider this a bug. If you want to start a discussion on what should or shouldn't chang in a future version of gnuplot - that's a topic for the mailing list.

     
  • Dan Sebald

    Dan Sebald - 2016-12-20

    OK. Not right now, but some day when I've more time I'll write the discussion list, and we can reopen this ticket if necessary.

    I tried "reset". It brings back the auto-scale, but the 'u' unzoom is the same. It has some benefit though.

     
    • Ethan Merritt

      Ethan Merritt - 2016-12-20

      Are you suggesting that "reset" should clear the zoom stack?
      I suppose we could add code to do that, but I don't at the moment see any problem it would solve.

       
  • Dan Sebald

    Dan Sebald - 2016-12-20

    Yes, clearing the stack. I have a little app with collections of signals to look at. One group of data is plotted and the user will examine the data, probably zoom in to see something of interest, maybe zoom back out, the zoom to look at another segement. Then it is on to the next signal in the list. It might be totally different x and y ranges. Accidentally typing 'u' (simply because one is using 'u' a lot in this scenario) will apply the ranges from the previous plot to the new data, which may not even fall within that old range. It's as if the new plot gets into a zoom state that can't be undone; the app is generating the gnuplot commands so there is no way to issue the range again at some command line. The significance isn't apparent until having a setup as I described, i.e., using the mouse zoom in a very interactive way.

     
  • Ethan Merritt

    Ethan Merritt - 2016-12-20

    I'm not convinced. The next user or application to come along may want exactly the behavior you are complaining about. Being able to return to a previous zoom setting for a new data set sounds like a desirable feature rather than a bug.

     
    • Karl Ratzsch

      Karl Ratzsch - 2016-12-23

      Make that an option to "reset", and leave it to the user to re-bind the "u" key accordingly?

      Or perhaps giving a "_range" command should reset the zoom stack. I guess that would always make sense:

      plot sin(x)/x
      # now zoom in
      set xrange [-20:20]
      set yrange [-10:10]
      plot 8*cos(x)
      # (zoom again, if you want and) press "u"
      
       
      Last edit: Karl Ratzsch 2016-12-23
      • Ethan Merritt

        Ethan Merritt - 2016-12-23

        It may depend on how you think of it. I could also argue that if you set a new explicit range it should be pushed onto the top of the zoom stack rather than replacing it. That way if you change your mind it's easy to undo it.

         
        • Karl Ratzsch

          Karl Ratzsch - 2016-12-23

          Possibly. ;-)

          I must say I'm with Dan here, have always found it slightly confusing that "u" wouldn't land me at the "default" ranges that were active at the moment of the last "(re)plot" command. To return to a previous zooms setting I'd press "p" a few times.

           

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks