[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnuplot image code

From: Quentin Spencer
Subject: Re: gnuplot image code
Date: Wed, 25 Oct 2006 12:09:36 -0500
User-agent: Thunderbird (X11/20060913)

John W. Eaton wrote:
On 20-Oct-2006, Quentin Spencer wrote:

| function version = __gnuplot_version__
| | persistent __version__ = 0; | | if !__version__
|     ## If the function hasn't been called before, use this code to get
|     ## the version from gnuplot.

What should happen if gnuplot_binary is called to specify a different
version of Octave?  Should we expect that to work without restarting

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.

|   ## Gnuplot reads binary files very quickly.  However, the 'fwrite' below
|   ## is much slower than using the current '__gnuplot_plot__' command.
|   fwrite(fid, A', "float", 0, "ieee-le");

Octave's fwrite function was written to handle skip, but it is not
done very efficiently, and the simple case of writing contiguous
blocks of data with one function call is not done at all (I was more
concerned with handling skip correctly).  If someone would like to
work on this project, the place to start is the function

  template <class T>
  octave_stream::write (const Array<T>& data, octave_idx_type block_size,
                        oct_data_conv::data_type output_type,
                        octave_idx_type skip, oct_mach_info::float_format 

in src/oct-stream.cc.

Also, why not just write in the native format?

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]