#1388 Per-line ranges apply only to functions, not to data plots

5.0
closed-wont-fix
nobody
None
5
2014-08-18
2014-04-24
Christoph Bersch
No

Today I observed, that "per-line" ranges, i.e. something like

set xrange [1:5]
plot x lc rgb 'black', [3:4] x lc rgb 'red' lw 5

works fine for function, the example above works fine. But for data the range settings of the second command are ignored:

$data <<EOF
1
2
3
4
5
EOF

set xrange [1:5]
set style data lines
plot $data u 1:1 lc rgb 'black', [3:4] $data u 1:1 lc rgb 'red' lw 2

I would expect this to work in the same manner as for functions.

Thanks,
Christoph

Discussion

1 2 > >> (Page 1 of 2)
  • Ethan Merritt
    Ethan Merritt
    2014-04-24

    I never intended the piecewise ranges to apply to data files. The idea was to allow independent sampling ranges. I guess the documentation could make that clearer.

    Even in older gnuplot versions you could filter the range of input data in the using spec. The lack of control only existed for functions, which don't have a using spec, and sampled functions done with '+', which otherwise have no provision for setting a range.

    I realize that this makes a range statement at the very start of a plot command different from ranges in the later positions. This is not ideal. The long-standing interpretation of an initial range has been that it was equivalent to a "set xrange" statement. My own preference would be to drop that interpretation altogether and have it be analogous to the later ranges. I.e. it would only apply to sampling the first plot segment. But I haven't made that change because I expect others to disagree with me on this point.

    Maybe I'm wrong and other people would generally agree with me that since we are not promising backward compatibility, internal consistency in version 5 is more important than retaining the old interpretation of the first range spec in a plot command. What do you think?

     
  • Karl Ratzsch
    Karl Ratzsch
    2014-04-25

    I´ve got one (possibly stupid) idea for this: Can´t the per-line ranges just be given after the function or file name? Then one could have both, e.g.

     plot [-11:11] "data" [-10:10], f(x) [1:6]
    

    and it´d be backward compatible, too.

     
    Last edit: Karl Ratzsch 2014-04-25
  • I was just surprised, that the piecewise ranges don't apply to data file. I would find that much more consistent, no matter if there other ways (using) to achieve the same result.

    What I also found non-intuitive was, that e.g. the plot

    plot [0:10] x, [10:20] x**2
    

    draws only the x part, because the xrange is set to [0:10]. However, using

    plot sample [0:10] x , [10:20] x**2
    

    uses the default range of [-10:10]. Only the command

    plot [0:20] sample [0:10] x, [10:20] x**2
    

    gives the "correct" result.

    Intuitively, I would expect the command

    `plot [0:10] x, [10:20] x**2
    

    to set xrange to [0:20] and plot the functions in their individual intervals. If one wants to specify a different overall xrange, one could use plot xrange [-10:30] [0:10] x, [10:20] x**2. But that would have other downsides. Expecially, when the yranges come into play...

    Don't know if there exists a better convention to properly combine the piecewise ranges and the total range. I guess one would have to make a lot of use cases and then consider if it makes sense to change the overall sense to change the overall syntax.

    But in any case, I would make the behavior equivalent for functions and data.

     
    • Ethan Merritt
      Ethan Merritt
      2014-04-26

      I would make the behavior equivalent for functions and data

      How would that be possible? They are intrinsically different. "data" has a self-defining natural axis range but has no associated sampling. "function" has no natural axis range (other than the program's arbitrary default [x=-10:10] but is strongly dependent on sampling. Remember that the sampling range may not coincide with the axis range.

      Your example "plot [0:10] x, [10:20] x**2" conflates xrange and sampling range because both functions use x. Consider instead:

        plot [0:10] x, [10:20] '+' using (cos($1/10)):(sin($1/10))
      

      Here you can see that the first bracketed expression [0:10] affects the axis range, while the second bracketed expression does not. I don't like this, but for me the better solution is to have neither expression affect the axis range. Both would affect sampling only, and the ranges would be controlled only by "set xrange".

       
  • Karl Ratzsch
    Karl Ratzsch
    2014-04-30

    I still say the ambiguity with the control of the axis range would be solved by changing the present (in gp50alpha) syntax (ranges given before function or filename) to expecting an additional sampling range after the function or filename, leaving only the axis range before the first function or file name, where it always was.

    See my posting above.

    The sampling range could then for datafiles just work as a filter, which is, i guess, what Christoph expected it to do in the first case.

     
    • expecting an additional sampling range after the function or filename,

      We have been on quite a long-term campaign to get rid of exactly that kind of position dependency in gnuplot's command syntax. Is this really sufficient reason to abandon that?

       
  • Ethan Merritt
    Ethan Merritt
    2014-04-30

    Karl: I think your range-comes-last suggestion is clever. But I also think it may be solving a problem that shouldn't exist in the first place.

    What is the argument that data files ever need an in-line range spec? It has always been possible to filter the data as it is read by putting a ternary test in the using spec. Why isn't that sufficient?

    That also applies to the very first range in the plot command. Why was it ever needed? I'm not impressed by the argument that it saves typing 8 additional characters, e.g.

      plot [min:max] 'foo.dat'
    

    vs

      set xr [min:max]; plot 'foo.dat'
    

    Perhaps there is an even more clever approach that makes it easier to place a filter in the using spec. For instance it is currently legal to say:

      plot [20:40][10:40][5:10] 'silver.dat' using 0:2:3 lc palette z
    

    That's ugly. It's also almost certainly wrong, since the 3rd range gets applied to the x2 axis rather than to z or to cb. What if this were

      plot 'silver.dat' using 0[20:40] : 2[10:40] : 3[5:10] lc palette z
    

    Better, although it's still hard to read and unclear whether the 3rd range is supposed to apply to z or to cb. I'd still prefer

      set xr [20:40]; set yr [10:10]; set cbr [5:10]
      plot 'silver.dat' using 0:2:3 lc palette z
    

    I can see an argument that putting the ranges in-line has no lasting effect, whereas putting them in a separate "set range" statement leaves the range in effect after the plot. But if that is the primary requirement maybe what we need is an easy save/restore command for ranges?

     
    • I'm not impressed by the argument that it saves typing 8 additional characters,

      That never actually was the argument for its existence. The argument has always been that sometimes you may want to override the range / autoscale settings temporarily, for the duration of a single plot, without losing them completely in the process. I.e. the use case is

      set xrange [0.2340985:0.2340987]
      plot 'data', f(x)
      #  hmmm... need to look at something else for a moment
      plot [5:20] 'some other data'
      # OK back to original plot, with the original range:
      plot 'data'
      

      That has been the general scheme of gnuplot since essentially forever: you have compile-time defaults which are changed until further notice by {un}set commands, and can be overridden on-the-fly for individual plots, or even individual curves in a plot command, by options right inside the plot command. I don't quite see why that's suddenly supposed to be such a bad idea.

       
      Last edit: Hans-Bernhard Broeker 2014-04-30
      • Ethan Merritt
        Ethan Merritt
        2014-04-30

        That was the point I raised in the final paragraph above. If the reason for allowing an initial in-line range is to overcome the lack of a save/restore for axis ranges, maybe the answer is to add save/restore of axis ranges.

        Heck, we even have code already for a LIFO stack of ranges settings - it's in the zoom/unzoom routines. What about making command line versions of the zoom/unzoom commands?

          zoom x [1:2] y [3:4]
          plot FOO ... title "with new ranges"
          unzoom
        

        I realize that your example was not a true "zoom" because it plotted some other bunch of data. So zoom/unzoom might not be the best choice of command names. Then again, if you plot a new data set after interactive zooming you get this same behavior. The new plot is in the "zoomed" state, and the "unzoom" hotkey will restore a previous set of range settings.

         
        Last edit: Ethan Merritt 2014-04-30
        • maybe the answer is to add save/restore of axis ranges.

          But why only axis ranges? A lot of settings are routinely overridden inside plot commands (dummy variable names, axis ranges, default plot styles, linestyle features, linetype features, surface meshing, pm3d, ...)

          OTOH, I really don't see that this would be worth breaking compatibility for.

           
1 2 > >> (Page 1 of 2)