Re: Assignment functions (patchset # 1774478)

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

On Thu, 16 Aug 2007 14:10:10 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> Ethan A Merritt wrote:
>> On Wednesday 15 August 2007 00:40, plotter wrote:
>
>> The space required to write it out once should be about the same either  
>> way.
>> But yes, I can see that the earlier f(x)=assign("var",expression)
>> makes it much easier to re-use the definition concisely in multiple plot
>> commands.
>
> Maybe, instead of inventing more new syntax, we should follow
> established C syntax a little further, e.g. implement the comma operator
> and the "each assignment is an expression, too" idea.  E.g. an averaging
> filter could be expressed as:
>
> 	using 1:(N = N + 1, sum = sum + $2, sum / N)
>
> or even
>
> 	using 1:((sum += $2)/++n)

That I like, I think the assign() idea was done as a quick and easy way to  
slip this into the existing parser. It served well to prove the principal  
but yields a rather clumbsy syntax.

I would like to see this sort of "each assignment is an expression"  
approach, that was in fact my original request which Ethan rapidly  
provided in what is now called the "old" implementation.

I think it is useful that whatever is done can be done within a function  
call or similar mechanism that allows pulling the detail outside of the  
plot command itself.


>
>> It would be very easy to move the assignment evaluation to the beginning
>> of the per-line processing rather than the end.  But then it becomes a
>> problem what to do if the data line turns out to have missing or invalid
>> entries. The earlier variant already suffers from this (see below).
>> I'm open to suggestions here.
>
> Honestly, I think this whole idea is going in the wrong direction.
> We're straying awfully far from the "one tool <--> one task" approch of
> Unix tradition here.  gnuplot is a plotting program, not a substitute
> for awk, Perl or Excel.  I'd prefer it if we left generic data
> processing to generic tools designed for the job.

I see your point and I dont think gnuplot needs to provide these sort of  
data processing tools itself. The whole thing here is just to provide a  
mechanism not to start providing any data processing functions directly.  
This would be going beyond "one tool <--> one task" .

Adding a means to hook in simple algebraic tasks written by the user is  
more analogous to calling an awk script from gnuplot except that it is  
tightly bound to the plot iteration rather than duplicating that  
externally.

My area under graph example could be done externally but I can do the same  
thing with gnuplot for the price of two local variables and one (longish)  
line added to my gnu file.

I would not wish to do complex data processing this way but for simple  
tasks like a.u.g. , mean/min/max values it makes a lot of sense.


>
> And even if we're going to do this, the using specification is not
> really the right place to do it in.  It should be moved to a separate
> command.
>

Your comment agrees with my wish to see a mechanism outside the plot line  
rather than burgeoning the using spec, though I would like to see this as  
a hook into the existing plot iteration of the data.

If this were done as a separte command it would end up having to duplicate  
much of what plot does. That duplication of code could lead to errors.

I think my preference would be , as you suggest, "each assignment is an  
expression" and comma syntax but inside the existing function call. This  
would avoid the rather awkward assign() .

Thanks for you comments, Peter.