Re: [Nlisp-developer] on `save-plot' name and save-plot feature

[Mirko V. <mir...@gm...>]

On Wed, Feb 25, 2009 at 5:45 PM, Leigh Smith <le...@le...> wrote:

> Thanks Mirko for your feedback on save-plot. While the default format is
> postscript, the :format keyword parameter to SAVE-PLOT allows specifying any
> of the formats that gnuplot supports.
>
>  We should have a routine to save all the plot data (and hopefully
>> formatting parameters) into a file that can be read at a later date and used
>> to restore a plot.  I would find such a feature tremendously useful.
>>  Especially if the data in the restored plot can be read into a lisp
>> session.
>>
>
> I tend to feel that there are already routines in nlisp-io for saving the
> data that is used to form the plot, .SAVE allows writing the data out in a
> number of binary and text formats. There is a long standing plan to
> implement saving to HDF5 format which can also benefit plotting. I find
> writing a postscript file which is then converted to PDF (or using aquaterm
> to directly write PDFs) in effect achieves that plot archiving for my
> purposes. This could be achieved for those platforms that don't do PDF
> plotting natively by SAVE-PLOT checking if the :format parameter is "PDF",
> and if so, running a ps2pdf converter.


Two points here:
1) There is definitely a need for documentation, which a long time ago I
volunteered to write.   I may start collecting your replies to my emails for
that purpose.

2) My comment was driven by experience with software such as excel, which,
paltry as it may be, saves the state of an analysis, and can then pick off
from that point.  I am not trying anything that ambitious.  But my
experience with IDL's iTools was very positive.  The iTools were versatile
plotting utilities.  One could save the plot, and then open it later for
further processing of the data. I liked that very, very much.  In some
sense, the later session would be much cleaner, because it consisted of only
the data that I cared about at that later moment.

Again, I am not shooting for anything that ambitious, but a basic save plot,
and open it for further playing would be an improved experience.  This is
really a usability layer on top of basic nlisp.

>
>
> Likewise, if the :format parameter was "archive", this would just cause
> SAVE-PLOT to call .SAVE to write the data to some files. These could be read
> back again with the standard file I/O routines (.LOAD).  I personally don't
> favour that approach since the idea of plot functions archiving data mixes
> the two behaviours and I think this will just complicate the code. To me,
> what we need is to slightly extend .SAVE to also handle lists of NARRAYs:
>
> (plot (list n-data1 n-data2) (list x-axes1 x-axes2))
> (save-plot :format postscript)
>
> can be:
>
> (.save (list (list n-data1 n-data2) (list x-axes1 x-axes2)) file :format
> :binary)
> then
> (apply #'plot (.load file))
>

I will look into .save

>
>
>  I am not sure how to implement that.  As a start, each window should have
>> an associated variable (object) that stores the names of the data files used
>> by gnuplot, and the list of plot commands.  Upon a (save-plot file-name) the
>> files should be zipped into an archive and an additional file with plot
>> commands stored in it as well.
>>
>
> The problem I see is how to ensure the gnuplot commands that generate the
> plot are archived properly such that they can recreate the plot you want.
> Most gnuplot commands probably can just be replayed with the right data
> filenames, but it means dealing with directories that will change between
> when the plot is originally drawn and when they are replayed.
>

Again, harking back,to my idl experience, some 10 years ago I wrote an OO
plotting application.  The data and all the plot settings were part of an
object.  The main method, generating the plot, would build the command line
out of the stored plot settings, and apply it to the stored data.

This could be applied here to, using the already existing functionality.  A
plot object that would store the data and the plot settings.  As noted
above, this is one level above the basic nlisp, and would use much of the
existing functionality.  This of course, does not address your next issue,
that of plots with huge numbers of data.  For that, another approach might
be necessary.

>
>
>
>> As for saving plots in other formats, how about using names such as
>> `render' or `export'.  `Dump' which I used is too hackerish.
>>
>> Maybe there is a better name than save-plot for saving plots.
>>
>
> I'm certainly open to renaming SAVE-PLOT, but in naming it that, the
> semantics were considered as that the plot itself is being saved (after it
> has been displayed). So I don't have a problem with the concept of saving
> the plot data and gnuplot commands, but I think it might be quite a bit of
> work to get it running transparently. I also suspect the approach may not
> scale all that well, recreating small plots from the original data is
> practically the same amount of work as redrawing the image, but for large
> complicated data sets, the plot is often downsampling and projecting to 2-D
> the data to produce the image and so will be slower than drawing the PDF
> whenever the plot is redrawn within gnuplot.


Here I have to disagree with you.  My understanding of the semantics is
following:
`save' & `restore' are kind of a pairing: you save a plot, and you read it
back in.
`export' or `convert' transforms a plot to a different format or display
device.

Here are some examples that I have on my computer:
GhostView uses convert when saving into file formats and save-as when saving
into file formats it can read back. Gimp uses save-as, but that is because
it can read back all the formats that it saves into.
Inkscape is similar to Gimp.  But in addition it can `export' a bitmap.

I think we should follow conventions used in other packages.  Until nlisp
learns to read back in .svg and .ps formats (entirely possible), we should
be exporting to them and not saving to them.

my 2 pennies (this issue is not the dealbreaker for me)

Mirko