Re: [PATCH] volatile-data plots now handle 'reversed' ranges during replots

[Ethan M. <merritt@u.washington.edu>]

On Wednesday, 03 April 2013, Dima Kogan wrote:
> I'm attaching another patch. This one adds support to the "reverse"
> ranges setting for replots of volatile data. This is similar to the
> previous ranging fixes, where the setting was respected for the original
> plot, but ignored for replots.

I'll test the patch, but I fear it may break zoom/unzoom.

> Does anybody know why multiple passes are made? 

The volatile path can only handle the simple case of un-transformed data.
This case is common enough to be useful, but it cannot substitute for the
general case treatment.

Consider:

  f(x) = 2*x
  plot 'silver.dat' using (f($1)):2
  f(x) = x/2.
  refresh # redraws the original plot even though f(x) has changed
  replot   # draw a new plot using the new f(x)

The fundamental problem is that gnuplot does not store the original
data values internally.  It only stores the transformed coordinates used
in the plot.   This is particularly annoying in the case of log-scaled axes,
where the log scaling is applied to the data when it is read in rather
than when it is plotted.  So log scaling interferes with the volatile 
data path.

> Is it a major undertaking to reduce this to a single pass, so that all data
> becomes "volatile" and we can get rid of the multiple code paths?

Yes.  You would have to change it so that the original data values are
stored internally so that they can be reused without rereading from
the input file.   That basically isn't possible. 
Consider
      plot "data" using 1: (sum [i=2:100] f(column(i)))
In order to reevaluate this after possibly redefining f() you would
have to store 100 columns of data internally.  As it is now, they
are processed on input and only the resulting sum is stored.

Nevertheless, I have long wanted to do away with the log-scaled axis
code.  Having to log/unlog the data every time you access the
stored values complicates the code throughout the plotting routines.
I would much rather get rid of all that extra code and apply the
log-scale transformation at the time the data is plotted.  
The "set link" command added in 4.7 was designed to take us halfway
to this goal.  The "link" code attaches a scaling function to the axis,
which could in this case be log().  The problem is that there is
a complicated bit of code that generates log-scale tick positions as
a special case, and it's not obvious to me how to replace this
transparently.  On the other hand the existing log-scale tick mark
code has been buggy for 20 years or so; the oldest open bug still
being tracked is "short log axes get bad autotics", added when the
SourceForge tracker was started in 2000.  So maybe throwing it out
and starting over wouldn't be a bad idea anyhow.

     Ethan

> 
> I'm also including the test cases I used to validate this. For all the
> test cases, I made sure that both the original plot and a replot looked
> good.
> 
> Lastly, I'm really not at ease with these patches. Currently there are
> separate code paths for volatile and from-a-file data; these paths get
> out of sync, and issues such as this arise. I'm assuming that where
> reading data from files gnuplot can (and does) take multiple passes
> through the data, which is impossible when reading a pipe. 
> 
> dima
> 
>