Re: [Gretl-devel] Request for Comments: gnuplot and foreign
Not to get too user-specific on this, but I had a situation not long ago that this idea
could hopefully solve. I was generating plots in a loop, and wanted to title them
"beta 1", "beta 2", etc, based on the value of the loop index. I
generated the title in gretl, no problem, but couldn't get gnuplot to accept it using
the "set title (string generated from gretl)". I had a brief look at the gnuplot
help, but then decided that this was something I could figure out later.
Anyway, my point with this is: I want to spend my time writing gretl scripts, not gnuplot
scripts. If the "new plot"* environment will help with that, then I'm all
for it!
* ;-)
PS
Sent from my iPad
On Oct 8, 2014, at 11:02 AM, Riccardo (Jack) Lucchetti
<r.lucchetti(a)univpm.it> wrote:
> On Thu, 2 Oct 2014, Allin Cottrell wrote:
>
> Sorry it's taken me a while to reply on this, but here are my thoughts.
> I like the idea of using a "block" approach for non-trivial gnuplot
commands within gretl, for two main reasons:
>
> 1) to avoid option-overload and the somewhat fussy syntax we have at present for
appending "literal" lines to a plot specification; and
>
> 2) to streamline the handling of custom plots (i.e. those not supported by
gretl's built-in "gnuplot" options) so that package writers or others
don't have to mess with low-level file I/O.
>
> I think that that these two uses probably call for somewhat different handling --
maybe two distinct modes of a "plot", or perhaps "foreign", block.
I've given this more thinking time, and I now think that we could combine the two
approaches that Allin suggested as follows: we scrap the "gnuplot" command of
most options and we leave it as a quick-n-dirty tool for basic data visualisation: simple
line graphs, xy plots, and the like. Then, we introduce, for more sophisticated jobs,
*two* new constructs:
(1) a "plot" environment like the first one Allin envisaged. That is, a block
inside which we allow for special syntax which translates internally into gnuplot
commands, but basically follows the old "gnuplot" command conventions. In other
words, a pidgin language that is neither hansl not gnuplot. Allin's example
plot
data foo
option with-lines
literal set title "My title"
end plot
exemplifies this quite well. What you get between "plot" and "end
plot" is simple syntax, with only a few rigid commands. Of course, you wouldn't
be able to use the full power of gnuplot, but in return you would have the guarantee that
the subset of gnuplot commands we'd use for producing the output is compatible with
our GUI editor, so that you could save the result to the icon view and modify it via our
gnuplot interaction GUI tool if needed.
(2) a "literal" environment, which IMO could well be just another incarnation
of "foreign", as in
foreign language=gnuplot
...
end foreign
in which you could issue _any_ gnuplot command you want and unleash our graphic engine to
its (enormous) full potential. However, you'd lose the ability to save the result into
a gretl graph and, as fare as data passing is concerned, you'd be totally on your own
with solutions like temporary files (ok, maybe we could envisage some form of string
substitution).
Do you guys like this?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel