gnuplot-beta

Any simple way to create for loops?

[Mojca M. <moj...@gm...>]

Hello,

Is there some way to do something like this in gnuplot apart from
using external script?

    for [i in "0.01 0.1 1 2 3 10"]
        filename=sprintf("name-%g.png", i)
        command=sprintf("./script %g", i)
        set output filename
        plot command using 1:3 with lines
    endfor

I've read about reread, but I don't know how to apply it here except
if gnuplot supports some array data structure which I think it doesn't
(but maybe I'm wrong), or if I create a function with a long series of
    f(x) = (x==1) ? 0.01 : (x==2) ? 0.1 : (x==3) ? 1 ...
but in that case I would probably prefer to use external script for that.

Thanks,
   Mojca

Re: Any simple way to create for loops?

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

Hello,

> Is there some way to do something like this in gnuplot apart from
> using external script?
>
>     for [i in "0.01 0.1 1 2 3 10"]
>         filename=sprintf("name-%g.png", i)
>         command=sprintf("./script %g", i)
>         set output filename
>         plot command using 1:3 with lines
>     endfor

There is a patch at sourceforge (2652184):

  
https://sourceforge.net/tracker/?func=detail&aid=2652184&group_id=2055&atid=302055

It allows something like:

for [str in "0.01 0.1 1 2 3 10"] {
  i = real(str)
  filename=sprintf("name-%g.png", i)
  command=sprintf("./script %g", i)
  set output filename
  plot command using 1:3 with lines
}

I haven't had too much feedback, though.

> I've read about reread, but I don't know how to apply it here except
> if gnuplot supports some array data structure which I think it doesn't
> (but maybe I'm wrong), or if I create a function with a long series of
>     f(x) = (x==1) ? 0.01 : (x==2) ? 0.1 : (x==3) ? 1 ...
> but in that case I would probably prefer to use external script for that.

Well, something like (untested):

if (!exists('values')) values = "0.01 0.1 1 2 3 10"
if (!exists('i')) i = 1; else i = i + 1
val = real(word(values, i))
filename=sprintf("name-%g.png", val)
command=sprintf("./script %g", val)
set output filename
plot command using 1:3 with lines
if (i < words(values)) reread

Would probably also work.


Juergen

Re: Any simple way to create for loops?

[Bastian M. <bma...@we...>]

There's also a patch on sourceforge which implements general scripting 
support with a language called Rexx.
(This had been only available on OS/2 previously).

In your case you could use the word() function and reread as follows, 
though:
In a file called sth. like main.gp do:

  # we use a string to simulate an array
  filenumbers = "0.01 0.1 1 2 3 10"
  # initialize loop counter
  index = 1
  # start loop
  load "loop.gp"

In loop.gp then do:

 # use filenumbers string as array
 i = word(filenumbers, index)

 # construct a new data pipe command
 command=sprintf("< ./script %s", i)

 filename=sprintf("name-%s.png", i)
 set output filename

 plot command using 1:3 with lines

 # increase loop counter
 index = index + 1
 # iterate
 if (index <= words(filenumbers)) reread


Not sure the above stuff is free of errors - I did not test it. But you 
should get the idea  for the looping bit... :)
I have not used strings with pipe commands before (the "< ./script" bit) 
so no guarantee that the plot command actually works.

Bastian

Mojca Miklavec schrieb:
> Hello,
>
> Is there some way to do something like this in gnuplot apart from
> using external script?
>
>     for [i in "0.01 0.1 1 2 3 10"]
>         filename=sprintf("name-%g.png", i)
>         command=sprintf("./script %g", i)
>         set output filename
>         plot command using 1:3 with lines
>     endfor
>
> I've read about reread, but I don't know how to apply it here except
> if gnuplot supports some array data structure which I think it doesn't
> (but maybe I'm wrong), or if I create a function with a long series of
>     f(x) = (x==1) ? 0.01 : (x==2) ? 0.1 : (x==3) ? 1 ...
> but in that case I would probably prefer to use external script for that.
>
> Thanks,
>    Mojca
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>   

Re: Any simple way to create for loops?

[Mojca M. <moj...@gm...>]

On Fri, May 22, 2009 at 16:27, Juergen Wieferink wrote:
> Hello,
>
>> Is there some way to do something like this in gnuplot apart from
>> using external script?
>>
>>     for [i in "0.01 0.1 1 2 3 10"]
>>         filename=sprintf("name-%g.png", i)
>>         command=sprintf("./script %g", i)
>>         set output filename
>>         plot command using 1:3 with lines
>>     endfor
>
> There is a patch at sourceforge (2652184):
>
>
> https://sourceforge.net/tracker/?func=detail&aid=2652184&group_id=2055&atid=302055
>
> It allows something like:
>
> for [str in "0.01 0.1 1 2 3 10"] {
>  i = real(str)
>  filename=sprintf("name-%g.png", i)
>  command=sprintf("./script %g", i)
>  set output filename
>  plot command using 1:3 with lines
> }
>
> I haven't had too much feedback, though.

I'm sorry that it took me so long to answer this, but I'm a bit
confused. Two different solutions have been offered which has confused
me even more.

If there's a patch on sourceforge - what does that imply? What should
I do upon it?

The syntax of both patches looks fine to me and I would be glad to use
it, but I'm afraid to use it for the reports that I need to write if I
cannot be sure if that code will still work once I update gnuplot or
once I change the computer.

The problem is that I cannot tell:
- if code has a potential to break anything since I don't know the
source code well enough
- what the guidelines for extending gnuplot syntax are
Those two questions that are probably the most important when deciding
about accepting or rejecting a patch both need to be addressed by main
developers.

-----
Unrelated to original question, but related to the two patches that
have been proposed:

Approximately one half of patches on sourceforge have no resolution
(neither accept nor reject). Often something like "won't fix" or "will
fix, but needs some more testing" would help a lot.

It's a bit demotivating for authors of patches to get no feedback from
main developers and what's worse: as time passes those patches become
obsolete and probably stop working anyway because the original source
code changes. This mailing list often helps a lot to resolve problems,
but it would be great if someone with a clear vision of gnuplot future
development could review the patches and say one of the following for
each unresolved patch:

- accept it and close it
- likely to fix, needs more thinking/testing
- please provide more info/description (I don't understand what this
patch is supposed to do)
- unlikely to fix unless this or that happens
- won't fix (with explanation) and close it

(Long ago I wanted to fix and improve one of existing (almost broken)
terminals and add another one, but neither rejection nor acception of
patches or bugfixes made me lost any interest.)

Mojca

Re: Any simple way to create for loops?

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

On Sunday 24 May 2009, Mojca Miklavec wrote:

> I'm sorry that it took me so long to answer this, but I'm a bit
> confused. Two different solutions have been offered which has confused
> me even more.
> 
> If there's a patch on sourceforge - what does that imply? What should
> I do upon it?

The purpose of the patch tracker on SourceForge is to float ideas for
possible additions to gnuplot.  If people show interest in a patch,
then it may be refined and improved by additional discussion and 
contribution, and moved into CVS when there seems to be a consensus.

Sometimes there are patches from multiple people that address the same
or related ideas, but using different approaches.  Then the discussion
helps to settle which approach is better.  Right now there are multiple
patches illustrating different approaches to adding block-structured
syntax.  There has beeen some discussion, but not a lot.  None of the
patches is a complete solution, so more work would be needed in any case.

> The syntax of both patches looks fine to me and I would be glad to use
> it, but I'm afraid to use it for the reports that I need to write if I
> cannot be sure if that code will still work once I update gnuplot or
> once I change the computer.

It would be helpful if you were to look at both, whether or not you 
actually build and test them, and report back something like 
"Patch A would be better for my use because ....,  but I like the
idea of <foo> from Patch B".  We need to hear feedback from a variety
of users in order to guide the choice of implementation.

> The problem is that I cannot tell:
> - if code has a potential to break anything since I don't know the
> source code well enough
> - what the guidelines for extending gnuplot syntax are
> Those two questions that are probably the most important when deciding
> about accepting or rejecting a patch both need to be addressed by main
> developers.

Exactly. That is why we need the discussion. 

> -----
> Unrelated to original question, but related to the two patches that
> have been proposed:
> 
> Approximately one half of patches on sourceforge have no resolution
> (neither accept nor reject). Often something like "won't fix" or "will
> fix, but needs some more testing" would help a lot.

I think you may be confusing items from two separate trackers.
"Won't fix" applies to bug reports, not to patches.  The great majority
of bug reports are dealt with relatively rapidly and then closed.

Patches are a different thing, and are rarely rejected outright.
They are collected on the tracker site in the hope that they will
generate discussion and additional  contributions. The tracker item is
closed only when the patch itself or some equivalent functionality has
been added to CVS.  

Some patches are quite old, but it is still very useful to have them
available for reference.  Sometimes there will be a request for feature X,
and we can say "So-and-so offered a patch #XYZ to implement something like
that. Please take at look and see whether that approach would provide what
you want."  In other words, often there needs to be discussion by the
potential users before a patch can be evaluated, and that discussion may
not happen until a long time has passed since the first version of the
patch was posted.

> It's a bit demotivating for authors of patches to get no feedback from
> main developers 

I can assure you that being a developer does not mean that I am familiar
with all parts and uses of gnuplot.  If someone offers a patch to part of
the program I have never used, what useful comment can I offer?
Feedback from the user community is equally, or even more, important for
evaluation of the patch's utility. Technical feedback about implementation
details can wait until there is evidence that the feature will be
generally useful.

> and what's worse: as time passes those patches become
> obsolete and probably stop working anyway because the original source
> code changes. This mailing list often helps a lot to resolve problems,
> but it would be great if someone with a clear vision of gnuplot future
> development could review the patches and say one of the following for
> each unresolved patch:
> 
> - accept it and close it

 This sometimes happens.  Particularly if the patch addresses something that
 one or more of the developers can evaluate directly.  For instance, if
 a patch adds a feature that I can see immediately would be useful for
 application in gnuplot-based tools I am already using, I can evaluate
 for myself whether it works as advertised.  

> - please provide more info/description (I don't understand what this
> patch is supposed to do)

 That should be the default state.  Although more often the issue is not
 "what does it do?", but "why would you want to do that?".  

> - unlikely to fix unless this or that happens
> - won't fix (with explanation) and close it
> - likely to fix, needs more thinking/testing

 If the word "fix" is appropriate, then the code should probably not be 
 submitted to the patch tracker at all, but rather attached to the
 corresponding bug report.

> (Long ago I wanted to fix and improve one of existing (almost broken)
> terminals and add another one, but neither rejection nor acception of
> patches or bugfixes made me lost any interest.)

 If you are talking about the context terminal, to the best of my
 recollection (a) it could not be used with the distributed version of
 context, so basically no one was in a position to try it out.
 Maybe for that reason, (b) no one ever spoke up to say "yes, it works" or
 "I would use it if it work", or best of all "this is great, but it would be
 even better if X, Y, and Z".  If my recollection is wrong, I apologize.
 Please point me to any discussion or  indications of general interest by
 other gnuplot users.  If nothing else, in the intervening time the distro I 
 use has switched to using texlive, which includes some version of context.
 If your driver now works with a common tex distribution, maybe you'll get
 more feedback now than you did the first time around?