Dear Allin, Riccardo, Peter and Giuseppe,

I don't think the use of "foreign" for Gnuplot is the best way to solve our problem with complex graphics (neither to flexibilize the Gnuplot use). The graphical capabilities of an econometric software is, in my opinion, something too much basic. So, when we put the plotting job into a "foreign" way I think users could feel like a weakness of our girl (Gretl).

I like Allin's suggestion for a new syntax. As a matter of fact I already using something near these suggestions. Please take a look at the following example:

<hansl>

open australia.gdt

gnuplot\
  E PUS\
  {set term pngcairo font "Arial,8" size 680,400;\
  set title "GRÁFICO 1\n Taxa de Câmbio Real e Termos de Troca" font "arial,12";\
  set style line 1 lc rgb "#953735" lw 5;\
  set style line 2 lc rgb "#558ED5" lw 5;\
  set key right top;\
  set noxtics;\
  plot "-" using 1:($2) axes x1y2 title "Taxa de câmbio real (R$)" w lines,\
  "-" using 1:($2) axes x1y1 title "Termos de troca (índice 2010=100)" w lines;}\
  --time-series --with-lines --output=display

<hansl>

I think we could use exactly the same syntax used by Gnuplot inside the block "plot - end plot" because it looks like as simple as the (simple and beautiful) Hansl syntax. In that way the user will have all the functionalities of Gnuplot with Gretl making it easier to insert the data.

Additionally, we could replace the gnuplot command (and all the other plot-related commands) by using simply "plot". The kind of the graphic would be determined by the options inside the "plot - end plot" command block.

Um abraço,
Henrique Coêlho de Andrade

Diretoria de Estratégia e Organização

Divisão de Cenários e Estudos Macroeconômicos

Banco do Brasil

henrique.andrade@bb.com.br

Tel.: (61) 3102-6911



-----gretl-devel-bounces@lists.wfu.edu escreveu: -----
Para: r.lucchetti@univpm.it, Gretl development <gretl-devel@lists.wfu.edu>
De: Allin Cottrell
Enviado por: gretl-devel-bounces@lists.wfu.edu
Data: 02/10/2014 15:46
cc: Giuseppe Vittucci <giuseppe.vittucci@gmail.com>
Assunto: Re: [Gretl-devel] Request for Comments: gnuplot and foreign

On Sun, 28 Sep 2014, Riccardo (Jack) Lucchetti wrote:
in http://lists.wfu.edu/pipermail/gretl-devel/2014-September/005285.html

> Gretl has used gnuplot for all its graphical output since the dawn of
> time. [...]
>
> It could perhaps be advisable to extend the "foreign" command to drive
> gnuplot in a more transparent way than we do now, and at the same time
> take advantage of a change scheduled for gnuplot 5.0 (which should be in
> a cinema near you real soon): "Command scripts may place in-line data in
> a named data block for repeated plotting." This would make it possible
> to pass data to gnuplot in a clean and efficient way.
>
> The big difference with other "foreign" environments would be that it's
> highly likely that a script writer might want to pass to gnuplot strings
> as well as data. So, we could imagine a situation in which we pass
> bundles and have something like
>
> <pseudo-hansl>
> bundle to_gp = null
> to_gp["foo"] = X
> to_gp["bar"] = "A string"
> foreign language=gnuplot --data=to_gp
>   ...
> end foreign
> </pseudo-hansl>
>
> Being able to do something like this would reduce the need for
> supporting the rather byzantine syntax we now have for the "gnuplot"
> command, which could be much simplified with some options deprecated.

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.

In the first case I'm thinking of a plot that's of a supported type, and
the user just wants to add a few things (e.g. a specific title, some
labels). With any luck such a plot will be parseable by gretl, so that
editing via the GUI plot dialog should be possible. In the second case, I
have in mind a plot that bypasses gretl's built-in mechanisms and sends a
bunch of literal gnuplot directives.

So for mode 1 you might have something like

a) old-style:

gnuplot foo { set title "My title"; } --with-lines

b) new-style:

plot
   data foo
   option with-lines
   literal set title "My title"
end plot

where "data", "option" and "literal" are supposed to be gretl keywords;
"data" would be followed by the name of a matrix or a list of series,
"option" by an option flag but without the need for "--", and "literal" by
a line that should be passed straight through to gnuplot. You could have
as many option and literal lines as you want.

For mode 2 you might have something like:

plot --data=foo
   <literal line 1>
   <literal line 2>
   ...
   <literal line n>
end plot

with no gretl keywords inside the block. (OK, basically just thinking out
loud here -- I'm not proposing this with any definiteness.)

I'm not sure about using bundles in this context; my first impression is
that it's an unnecessary layer of indirection, but I'm open to persuasion.

On the use of named data blocks in gnuplot input: Yes, that would
certainly facilitate this sort of thing. The trouble is that (as you say)
such blocks are a gnuplot 5.0 feature. We package gnuplot 5.0 with our
Windows and Mac builds but it may be some time before Linux distros catch
up with that. Even Fedora and Arch (which tend to be pretty much
up-to-date on most things) seem to be quite conservative when it comes to
the gnuplot version they package. At present we only require gnuplot 4.4.0
in the gretl build, though perhaps we could bump that forward a bit.

Allin

_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel