On 25-Oct-2006, Quentin Spencer wrote:
| Good point. I assumed it was something that would not likely be changed
| during an octave session, and that calling gnuplot just to get the
| version would be slow and undesirable to repeat. However, I suppose
| plotting is not ususally done in speed critical sections of code, so
| maybe this isn't necessary.
Or, maybe we should arrange for the code that actually invokes the
gnuplot process to run "gnuplot --version" to extract the version
number, then restart gnuplot to actually do the plotting. The version
number could then be stored for each figure, so doing
gnuplot_binary ("gnuplot-4.2");
figure (1)
image (...)
gnuplot_binary ("gnuplot-4.0");
figure (2)
image (...)
figure (1) # switch back to figure 1, which already has gnuplot running
image (...)
would work.
Even on the slowest system I could find (230MHz Pentium MMX), running
"gnuplot --version" only takes .3s the first time, and about .025s
after that, so the overhead should not be too big. How long does it
take on a typical system using Cygwin, where process creation is known
to be slow?
The __gnuplot_version__ function could return the version for the
current figure, or -1 if there is no figure currently open.
| By native format, you mean the text format that is normally used for
| communicating with gnuplot? I suppose that could be done, but eventually
| when gnuplot 4.2 is widely used, I think it would be good for octave to
| use the binary format because it will be noticeably faster for large
| data sets.
No, I meant the native binary floating point format, whatever that
happens to be. Is it necessary to force Octave to write the data in
ieee-le format? Isn't the default for gnuplot whatever the native
format is, or is it necessary to tell it the format?