This looks like a great idea ;-) This would allow to easily combine graphs without "leaving" gretl. And it would also make the relation between gretl and gnuplot more "transparent", giving the right incentives to gretl users (like me!) to better understand the gnuplot language.
If the gretl manual had also some neat examples about the possible interactions between gnuplot and gretl, that would be great ;-) Bye Giuseppe > Gretl has used gnuplot for all its graphical output since the dawn of > time. Some people find gnuplot's output ugly, but that's highly subjective > IMO; as far as I'm concerned, I simply love it; I certainly wouln't trade > the austere beauty of a line graph like gretl produces with a cheap > alternative sporting grossly fatter lines in a tacky light blue frame. > > We also go to great lengths to make gnuplot's output customisable from our > GUI client, and it's a great credit to Allin's committment and ingenuity > that most GUI users don't even realise that their graphs are in fact > produced by a piece of software other than gretl. > > Our relationship with gnuplot, when it comes to scripting, is a bit more > awkward. We have one command (the 'gnuplot' command) for doing most > things, and its syntax has been expanding over time in order to > accommodate more and more flexibility. In fact, now that we have the > --input option, a hansl script writer has at her disposal the potential > for producing masterpieces such as those found at > http://gnuplot.sourceforge.net/demo_4.6/ if necessary. > > However, this implies writing functions in which, basically, we issue > strings into a file that is then re-used as input by gnuplot. The funny > thing is, we already have a "foreign" environment that does basically the > same job for statistical packages. > > 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. > > How do you like the idea? > > ------------------------------------------------------- > 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 > -------------------------------------------------------
