A few questions about Octave plotting o/p

[Madhusudan Singh]

Hi

I am sure this issue has been brought up before, but last night, while I was 
scripting with Octave (btw. octave is a surprisingly good product, an equal 
of Matlab in most (not all) ways as far as I am concerned), I realized that 
there are quite a few differences between Matlab and Octave when it comes to 
graphical I/O. Consider the following :

gset term postscript color eps
gset size 2,2
gset output "dev2.eps"
xlabel('Vec')
subplot(2,2,1)
plotcmd2=plotcmd('d2',p2,r2,1,3);
gset size 1,1
gset origin 0,0
eval(plotcmd2);
ylabel('Ic');
subplot(2,2,2)
plotcmd2=plotcmd('d2',p2,r2,1,4);
gset size 1,1
gset origin 1,0
eval(plotcmd2);
ylabel('Ib');
subplot(2,2,3)
plotcmd2=plotcmd('d2',p2,r2,1,5);
gset size 1,1
gset origin 0,1
eval(plotcmd2);
ylabel('Ie');
subplot(2,2,4)
plotcmd2=plotcmd('d2',p2,r2,1,7);
gset size 1,1
gset origin 1,1
eval(plotcmd2);
ylabel('hFE');

where plotcmd is a function that I defined. Initially, I did not have any gset 
directives above, and just tried to o/p print("-depsc","filename.eps") at the 
end of the above series of subplots.

I got an error complaining that I could not change terminal in multiplot. I am 
aware that Octave uses gnuplot for its graphical I/O. While I am quite savvy 
with gnuplot (and hence was able to come up with the above solution), having 
authored the fortran 95 interface to gnuplot 
(http://gnuplotfortran.sourceforge.net), I think that perhaps in the 
interests of proper interoperability with Matlab, gnuplot may not be the best 
solution.

Has thought been given to a standard Octave implementation of plotting 
interface (the Qwt library springs to mind) that strictly follows the Matlab 
way of doing things ?

At the risk of being misunderstood, I would like to say that I have always 
considered/expected Octave to be Matlab plus delta, meaning thereby that it 
can do everything major that Matlab does, and then adds on the excellent 
functions in the form of octave forge (I am currently debugging a function 
that reads data from an arbitrary HP/Agilent 4145 data file, returning 
sensibly extracted data, and hope to submit it to the forge soon). Plotting 
and the user interface is far too big a part of the Matlab experience to be 
ignored.

Maybe Octave can reimplement subplot, plot, etc. to be proper equivalents for 
the Matlab counterparts, and not just be wrappers for gnuplot. Octave can 
then leave gset, gplot, etc. to deal with those older scripts that do use 
gnuplot. Again, Octave = Matlab + delta (in this case, interoperability with 
gnuplot).

In my own research group, I have been trying to get people to use Octave 
instead of sinking money into Matlab and its steeply priced toolboxes, but 
the question of user interface always comes up, and that is something people 
are unable to get past. Seamless interoperability and portability are 
important, and people just do not want to invest time in writing long and 
complicated scripts for analyzing / presenting data, only to find that their 
colleagues using Matlab cannot use it / have to know enough gnuplot to 
translate them (which for all its undeniable merits, is not a very 
universally used plotting tool - *relatively* speaking).

As I stated at the beginning of my email, I imagine this is not the first time 
this issue has been touched upon. I just want to say that, IMHO, it remains 
the single biggest impediment in using Octave instead of Matlab. I do not 
wish to belittle what has been accomplished so far at all. I just wish to 
point out that this is something that needs urgent attention (and maybe it is 
already being considered for an upcoming release, its just that I am unaware 
of it).

On a more personal note, I tried to install octplot but it quits with an error 
that it cannot find Fl/Fl.h. I have every package which provides fltk 
installed :

# apt-get install fltk1.1-doc fluid libfltk1.1-dev libfltk1.1c102
Reading Package Lists... Done
Building Dependency Tree... Done
fltk1.1-doc is already the newest version.
fluid is already the newest version.
libfltk1.1-dev is already the newest version.
libfltk1.1c102 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 511 not upgraded.

locate Fl.h yields nothing of use in this situation :

# locate Fl.h
/usr/share/doc/fltk1.1-doc/HTML/Fl.html

In any case, if octplot is to be the UI of choice, it should be tightly 
integrated into Octave, and not left outside as an optional package.

Thanks.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------