Re: multiple plot lines with plot '-'

[<pl...@pi...>]

On 18/05/12 01:32, Tait wrote:
>>> f(x,y,z)=<some function>
>>> g(x)=<some other function>
>>> plot 'datafile' using (column(f($1,$2,$3))):(column(g($4)), \
>>> 	'data2file' using ($1>$2 ? column(g($4)) : 1/0)
>>
>> I think your example needs to be stripped down to the bare essentials of
>> making the point you are trying to make. I'll have a guess about what
>> you are trying to say, sorry if I miss the mark, and I think you are
>> mistaken.
>
> I was trying to make two separate points in that example, and you missed
> the first -- and more important -- of them. To simplify:
>
> plot 'datafile' using (column($1))
>

Yes, I had not thought of that trick. Nice.

One case where this could produce a change in behaviour is if a variable 
was assigned from the data in the first plot line and used to determine 
which columns were read later. This would prevent pre-emptive reading 
unless Allin's "read everything" solution was adopted.



> The column to be used for data is the column specified in the first
> column of the data file. This is not and cannot be known until the file
> (that column, at least) is actually read. The point of including the
> functions is that we might not even know based on a single line of the
> input what column we would need to preserve. The only way to know what
> must be preserved is to actually evaluate the using conditions on the
> input, see what results, and then reread the file for the next plot
> because it, too, may have the exact same dereferencing behavior that
> the first using statement had. And even more so, to the extent the first
> using evaluation had side-effects that alter the meaning of the second
> using statement, these side-effects cannot be anticipated ahead-of
> time without actually doing the calculations demanded by the user.
> These kinds of side effects are already suggested by demos like
> http://gnuplot.sourceforge.net/demo_4.6/running_avg.html.
>
> In short, the current behavior of gnuplot makes it impossible to
> do a single-pass read of the data file. We could break the current
> behavior, of course, but then we explicitly decrease the flexibility
> we have for the sake of introducing other inconsistent and backward-
> incompatible magic behavior.
>
> At risk of repeating myself, caching may be worthwhile, but not in
> the way and with the syntax you've suggested.
>
>>> 			... The behavior of '-' is currently the same as
>>> for a data file. ...
>>
>> No, you need to read up on how '-' works.  This has been covered in a
>> number of posts in this thread.
>
> I know exactly how it works, and it works just like data files work.
> I use and rely on this behavior. The behavior you want, and that
> you (incorrectly, imo) describe as being the same as what's done for
> data files is different. When you say plot 'file1', '', gnuplot does
> not save 'file1' and rewind through this cache to find the data it
> needs when plotting the ''. It plots 'file1', then when it sees ''
> it reads 'file1' (again). When gnuplot plots '-', it reads the inline
> data, and when it sees '' after, it reads the inline data again, not
> a cached copy that it rewinds and replays. The fact that '-' might be
> different on the first and second read is exactly the same as 'file1'
> might be different on the first and second read. This describes the
> same behavior for both 'file1' and '-'.

If you are suggesting that associating a file descriptor with a file; 
opening; reading; closing; reopening (with implies a seek(0) ) ; and 
rereading   is the same as opening ; reading upto 'e' marker *in the 
data* then continuing to read the same opened device,  I have to say 
your reasoning is getting a bit contrived.

I find it hard to see that as being the same behaviour.

What you're asking for is that
> unlike the 'file1' case, '-' be handled differently, so that it saves
> or caches the data and rewinds back and forth through this cache
> instead of reading anew. This sort of special-case handling of '-'
> might be a worthwhile option, but it's a separate feature, and one
> that must be kept optional so as to not break backward compatibility
> and important use cases for some users (like me).
>
>
open '-' is already a special case. That is the source of the "problem". 
However, I totally agree with you about backwards compatibility and it 
would need a pretty substantial problem for me to suggest breaking that.

Since this idea just looked like a nice improvement when I suggested it 
I don't see any pressing case. I'm always looking for speed improvements 
and rereading my data file six times seemed wasteful.

There is clearly a lot of divergent ideas of what would (not) be useful 
so I'm dropping the idea.

Thanks for all replies and comments, it's been interesting and has 
brought up some good ideas.

regards, Peter.