Re: Feature request - assignment in expressions

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

On Tue, 08 May 2007 17:57:54 +0200, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Monday 07 May 2007 23:56, pl...@pi... wrote:
>>
>> thanks very much for picking this up. That seems quite close to what I  
>> was
>> requesting. I extended your example to pick up the x value of the ymax  
>> as
>> well. The plot gives the sample-and-hold plot as expected. Proof of
>> principle. Nice one.
>>
>> The nice thing is this can be limitted by setting the range before plot.
>> This is a nice quick solution that avoids quite a bit of effort messing
>> about with external scripts for simple stuff like this. A nice addition.
>
> Please continue to play with it.  We need to discover what limitations  
> and
> drawbacks this simple implementation may have before seriously  
> considering
> to add some variant to the program.
>
> I hope we can come up with a nicer syntax, as it seems ugly to me to hide
> this inside the 'using' clause.

Yes it feels like a bit of a cludge but I'm happy to have a cludge rather  
than an impasse. I think the 'after' syntax is seems much more integrated.


  Thinking out loud....  what about a
> parallel clause with a name like 'after'.  The operations in the 'after'
> clause would be carried out before passing the data through for actual
> plotting:
>
>    plot <foo>  using 1:2 after track_max($2) with lines
>
> perhaps it should allow multiple operations:
>
>    plot <foo> using 1:2 after {track_max($2), track_min($2), sum($2)}  
> with lines
>
>
> More thoughts:
>
> - (Pro) As compared to filtering through an external script, this  
> mechanism
>   has the advantage that it can affect internal gnuplot user variables.
>
> - (Con) This is incompatible with the revised zooming/refresh code
>   that I am working on.  There the idea is to avoid re-reading the input
>   data if all you want to do is replot it.  But the assign/after  
> mechanism
>   is applied during data input, so it would be bypassed by any such  
> shortcut.
>
> - Having to use the name of the variable rather than the variable itself
>   may make sense to a low-level programmer, but is likely to be confusing
>   to many users.  Suggestions for a syntax that hides this level of
>   complexity would be welcome.  Or perhaps some additional cleverness in
>   the parset is possible.  We have one such function already,
>   exists("VARNAME"), but that one is also confusing.
>
Yes , it's a shame if you have to do it that way, I assumed you'd just  
done that for speed to test the idea because it was simpler to code.



>> This presents me with some small issues remaining to be solved:
>>
>> 1. My xdata is time format , I imagine your patch does not try to fit  
>> all
>> cases but in assigning the x value it gets truncated to the nearest  
>> hour,
>> 12:45 becomes 12.0
>
> I have never understood the time-handling code.  I suspect that the
> whole special case time format mechanism is no longer needed, as the same
> goal can be achieved using general string-handling functions.
> In your case, you probably need to use some combination of stringcolumn()
> strptime() strftime() rather than setting a time format.
>
>> 2. my inexperience with gnuplot, it seems that if I try to set a label
>> after the plot command (which I need to do for xmax,ymax) it does not
>> show. The same command before plot command does work but it's at (0,0).
>
> Of course.  When you draw a new graph by issuing the command "plot" or
> "splot", it uses the currently defined labels.
> If you define a label afterwards, how could it possibly appear in the
> already-drawn plot?  If you don't mind reading the data a second time,
> you could "replot" to pick up the new labels.
>
Redoing the whole job just to add a label seems a bit extravagant. I  
thought there may be some trick with multiplot that I had not discovered  
yet. Your reply suggests there is not.

This seems an illogical restriction from a users point of view even if it  
makes sense in the way gnuplot stores label info.

maybe there should be some mechanism if there isn't , eg. set label ....  
replot.

BTW I posted a bug to the bugs list about time data not being respected by  
table mode . Although I noticed the cursor is now display time data  
correctly, having gone to cvs, this does seem to be an area that still  
needs implementing consistantly.

I'll try to do an trapezoidal A.U.G  using your mod., I had to put this  
out to awk which was an annoying waste of effort. It will be a good test.

Thanks for your interest.