gnuplot-beta

iterate evaluate

[Juergen W. <wie...@fr...>]

Hi,

I would like to expand the iteration feature to the evaluate command
as I think this would be very useful.  I have attached a first naive
but generally working patch.  The problem is that the iteration is
not compatible to recursion.  Can it be fixed?  Is it worth the
effort?  IMHO a simple recursion detection would suffice.  I don't
see how to implement this right now in a way that still works after
an int_error(), though.

My use case: I have some more or less generic scripts with a
differing number of values d0, d1, ...  As I have to construct the
command line I'm stuck to the evaluate command.  I cannot even put
the iteration into a set command within the evaluated string.

BTW: AFAICS an int_error() leads to leakage right now as
check_for_iteration() simply discards (iteration_udv = NULL; ...)
instead of doing the correct deallocation.

Juergen

Re: iterate evaluate

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

On Tuesday 21 October 2008, Juergen Wieferink wrote:
> Hi,
> 
> I would like to expand the iteration feature to the evaluate command
> as I think this would be very useful.  I have attached a first naive
> but generally working patch.  The problem is that the iteration is
> not compatible to recursion.  Can it be fixed?  Is it worth the
> effort?  IMHO a simple recursion detection would suffice.  I don't
> see how to implement this right now in a way that still works after
> an int_error(), though.
> 
> My use case: I have some more or less generic scripts with a
> differing number of values d0, d1, ...  As I have to construct the
> command line I'm stuck to the evaluate command.  I cannot even put
> the iteration into a set command within the evaluated string.

I'm afraid I don't follow that explaination of intended use.
Could you give an example of how you would use this?

> BTW: AFAICS an int_error() leads to leakage right now as
> check_for_iteration() simply discards (iteration_udv = NULL; ...)
> instead of doing the correct deallocation.

I could be wrong, but I don't think there is a leak.
The udvs are all kept in one linked list.
Setting iteration_udv = NULL doesn't remove the udv from the list.
It is still accessible by name and will continue to be handled
like any other defined user variable.


-- 
Ethan A Merritt

Re: iterate evaluate

[Juergen W. <wie...@fr...>]

> > BTW: AFAICS an int_error() leads to leakage right now as
> > check_for_iteration() simply discards (iteration_udv = NULL; ...)
> > instead of doing the correct deallocation.
>
> I could be wrong, but I don't think there is a leak.
> The udvs are all kept in one linked list.
> Setting iteration_udv = NULL doesn't remove the udv from the list.
> It is still accessible by name and will continue to be handled
> like any other defined user variable.

You are of course right.

> > My use case: I have some more or less generic scripts with a
> > differing number of values d0, d1, ...  As I have to construct the
> > command line I'm stuck to the evaluate command.  I cannot even put
> > the iteration into a set command within the evaluated string.
>
> I'm afraid I don't follow that explaination of intended use.
> Could you give an example of how you would use this?

I have a set of n contour lines at, say, d0 = 1, d1 = 0.1, d2 =
1e-2, ...  and I would like to do something like:

command = 'set cntrparam levels discrete d0'
add_var(i) = sprintf('command = command ., d%i', i)
evaluate for [i=1:3] add_var(i)

Well, it may not be the best style, but there might be other use
cases, too.  Additionally, the simple

set for [i=0:3] cntrparam levels discrete 10**(-i)

Does not work as the levels are replaced instead of appended.

Juergen

Re: iterate evaluate

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

On Tuesday 21 October 2008, Juergen Wieferink wrote:

> I have a set of n contour lines at, say, d0 = 1, d1 = 0.1, d2 =
> 1e-2, ...  and I would like to do something like:
> 
> command = 'set cntrparam levels discrete d0'
> add_var(i) = sprintf('command = command ., d%i', i)
> evaluate for [i=1:3] add_var(i)
> 
> Well, it may not be the best style, but there might be other use
> cases, too.  Additionally, the simple
> 
> set for [i=0:3] cntrparam levels discrete 10**(-i)
> 
> Does not work as the levels are replaced instead of appended.

That seems like a separate issue.
How about a patch to allow
   set cntrparam levels discrete add <foo>
similar to the existing option
   set xtics add ("label" POSITION)




-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: iterate evaluate

[Juergen W. <wie...@fr...>]

> How about a patch to allow
>    set cntrparam levels discrete add <foo>
> similar to the existing option
>    set xtics add ("label" POSITION)

This would make sense.

Something different: In my opinion it's more natural to put the
'for' right before the 'set' command:

for [i=1:10] set xtics add ("label" POSITION)

The iteration feature would still have to be recursivly callable,
though.  This could be done by an iteration context (or ID) which is
returned by check_iteration() and possibly cleaned along with

	load_file_error();	/* if we were in load_file(), cleanup */
	reset_eval_depth();     /* reset evaluate command recursion counter 
*/

in plot.c.

Maybe I just file a feature request and we will see if anyone is
interested.


Juergen

Re: iterate evaluate

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

On Sunday 26 October 2008, Juergen Wieferink wrote:
> In my opinion it's more natural to put the
> 'for' right before the 'set' command:
> 
> for [i=1:10] set xtics add ("label" POSITION)

That is a logical syntax, but I would wager that users will immediately
assume that 
  for [i=1:N] ....
can be placed in front of any command (not just "set").
In fact maybe it _should_ apply to any command, but as of now it doesn't.

Furthermore, there is a logical difference between the two forms, as easily
seen for "plot", because
  for [i=1:N] plot ...
would create N separate plots, whereas
  plot [i=1:N] ...
creates 1 plot with N lines on it.

I now remember that "set for [i=1:N] xtics <foo>" makes this same distinction.
Because the iteration is _inside_ the set command, it is not required to explicitly
say "add".  So the two commands below (2nd is only hypothetical) are equivalent:

  set for [i=1:N] xtics (label(i), i)
  set xtics (); for [i=1:N] set xtics add (label(i), i)

The second (hypothetical) form requires both that you manually clear the list
initially and that subsequent list entries contain an explicit "add" keyword.
The first form (currently implemented) does both for you automatically.

Anyhow, getting back to the original question,
 set for [i=1:N] cntrparam levels discrete <foo>
should act analogously to the first form of the iterated 'set xtics' above.
It should all by itself do the initial clear and subsequent implicit "add".


-- 
Ethan A Merritt

Re: iterate evaluate

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

On Sunday 26 October 2008, Ethan A Merritt wrote:

> Anyhow, getting back to the original question,
>  set for [i=1:N] cntrparam levels discrete <foo>
> should act analogously to the first form of the iterated 'set xtics' above.
> It should all by itself do the initial clear and subsequent implicit "add".

Applied to cvs.  It was a one-line change.

   if (!iteration) {
      ... clear and initialize list of contour levels ...
   }


-- 
Ethan A Merritt