[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A few questions about Octave plotting o/p
From: |
Madhusudan Singh |
Subject: |
A few questions about Octave plotting o/p |
Date: |
Wed, 7 Sep 2005 15:32:20 -0400 |
User-agent: |
KMail/1.7.2 |
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
-------------------------------------------------------------
- A few questions about Octave plotting o/p,
Madhusudan Singh <=