Re: Assignment functions (patchset # 1774478)

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

On Wed, 15 Aug 2007 18:02:45 +0200, Ethan A Merritt  =

<merritt@u.washington.edu> wrote:

> On Wednesday 15 August 2007 00:40, plotter wrote:
>> >  Example:
>> >       SUM =3D 0
>> >       plot 'foo' using 1:(f($2)):assign(SUM =3D SUM + $2):assign(N =
=3D $0)
>> >       print "Sum of y values is ",SUM
>> >       print "Mean y value is ", SUM/N
>> >
>> However I see a couple of disadvantages with this approach of doing t=
his
>> in 'using' clause of plot.
>>
>> Firstly plot lines can get very long and cumbersome already, especial=
ly  =

>> by
>> the time one has added linetype title and colour specifiers. Already =
 =

>> some
>> of the uses I have for assign run to several lines on their own. I th=
ink
>> anything more than your simple example would make plot lines very har=
d  =

>> to
>> follow.
>
> The space required to write it out once should be about the same eithe=
r  =

> way.
> But yes, I can see that the earlier f(x)=3Dassign("var",expression)
> makes it much easier to re-use the definition concisely in multiple pl=
ot
> commands.
>
> I will have to think about whether there is a way to tweak the
> assign(var =3D expression)  variant so that you can be equally concise=
.

The big difference is the function is outside the plot command so all th=
at  =

is added is f($2) or a meaningful name like run_mean($2) that actually  =

make the plot command more readable and takes all the messy detail  =

elsewhere.


>
>> Second this is post processing. Much of the usefullness of this  =

>> technique
>> comes from the way I used it in a funtion that returns a value to usi=
ng
>> that gets plotted directly. The post processing seems to be a bit of =
a
>> show stopper for the way I was using this.
>
> It would be very easy to move the assignment evaluation to the beginni=
ng
> 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 inval=
id
> entries. The earlier variant already suffers from this (see below).
> I'm open to suggestions here.
>
> However, I'm not sure that the post/pre processing choice makes any
> fundamental difference in what you can plot.  The two variants below  =

> should
> achieve the same result, right?
>
>  old:  plot "foo" using 1:(assign("SUM",SUM+$2)) title 'running sum'
>
>  new:  plot "foo" using 1:(SUM+$2):assign(SUM=3DSUM+$2) title 'running=
 sum'
>
>

yes these two are equivalent because you've duplicated the code. If it w=
as  =

less trivial the whole thing would need duplicating and if the code  =

changed some other variables as in my examples this repetition would mes=
s  =

things up badly.

IMHO half the benefit of the old form was being able to operate on the  =

data and pass back a value to be plotted.

>
> One more thing:
> The behaviour of the earlier form is poorly-defined in a case like thi=
s
>
>    A(x) =3D assign("VAR_A", f(VAR_A))
>    B(x) =3D assign("VAR_B", VAR_A + VAR_B)
>    plot "foo" using 1:(A($2)):(B($3))
>
> OK, you can say "don't do that".  The point is that I don't think the =
 =

> order
> of evaluation is guaranteed.  Furthermore, what happens if column 3  =

> contains
> a '?' (missing data) or 'NaN' (illegal value).  Does the value of A ge=
t
> updated or not?  What about the value of B?  If so, with what value?
> Don't we have a problem that A and B can get out of sync?
>

That's true , although I dont think it's unsurmountable as long a functi=
on  =

can return NAN. The behaviour of
plot is defined in these circumstances and this sort of advanced user  =

technique carries a responsability of testing data before assigning and =
 =

conforming to plot behaviour.

I'd just started playing with NaN which is why I marked my running_mean =
 =

example as unfinished. This is something to look at but I dont think it'=
s  =

a problem, at least in the old format where preprocessing allows a means=
  =

to kick out. Returning NaN would be like raising an exception on that da=
ta  =

point. Things can be kept in sync.

Good point though.

You could check up on execution order. If that is not defined that could=
  =

be tricky , it may be necessary to force the order if plot contains  =

functions.

So far I have not tried a situation where this sort of dependancy comes =
in.


>
> I'm cc'ing this to the developer's mailing list.  Maybe useful  =

> suggestions
> will come in from a new direction.
>
> 	Ethan

Sorry, I did not realise I had mailed that last two comments to you only=
.  =

The reply policy of mailman lists is a contant cause of confusion. Since=
 I  =

am on several I often mix up who does what. I'll try to remember I shoul=
d  =

not use "reply" on gnuplot-beta.

thx.