[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Octave C++ libs ported to Borland C++ for OS/2
Octave C++ libs ported to Borland C++ for OS/2
Wed, 8 Nov 95 17:48:40 CST
Dear Octave developers,
I'm discussing here the port (compilation and running) of Octave C++ matrix
libraries under Borland C++ for OS/2.
I'm programming in C++ and I had to perform some matrix calculations.
On Internet, I found two interesting packages that are suitable
for C++ programmers: the source code of Octave and LAPACK++.
I decided to use the Octave math library since all I needed was perfectly
available (matrix multiplication, inversion, eigenvalue problems).
My operating system is OS/2 Warp. I compiled Octave libraries and my
programs that used them without problems using the gcc/emx
(GNU C/C++ 2.6.3) compiler. However, gcc makes rapid code, but it has
no IDE nor good debugging environment. so I decided to port Octave
libraries under Borland C++ for OS/2, version 2.0, which is the
fastest C++ compiler and has very nice IDE.
I compiled libcruft smoothly, but some problems occurred when compiling
the liboctave files. I had to make several changes to them, but not all
of them were Borland dependent. I think it would be interesting for you
to see and use the patched sources. Please, let me know where and whom
I can send these files.
Just these two points apply here:
-- I should say now that I had to use the GNU complex.h, complex.cc files
instead of these by Borland; it's strange that the complex routines are not
invariant and Octave uses some non-ANSI features(?).
-- I had to rename all files with "-" in the name to "_" (e.g. lo-error.cc to
lo_error.cc), since Borland's linker tlib cannot manage them.
-- I had to rename all files with the dash character to the same name
with underscore character, since tlib cannot manage them (e.g.
ren lo-error.cc lo_error.cc).
Next, it seemed that all worked (matrix multiplication, inversion),
until I calculated eigenvalues. The results were mysterious,
and the info variable returned from eigen(A,info,rcond) equaled 2 for
my testing 2x2 matrix. (gcc/emx compilation of the same code passed
all right). I spent a lot of time searching for the reason of the wrong
behaviour. So I found that the problem is in the f2c compilation.
Please, look to the code produced by the transformation f2c blas/lsame.f
You can see the dummy parameters ca_len, cb_lean of type ftnlen,
which are never used! Such dummy params are within a lot of transferred .f
In order to get rid of the wrong behaviour, I had to:
-- EIG.cc: comment out ", long, long" and ",1L, 1L" strings from
the declaration and call of dgeev and zgeev routines,
-- f2c.h: replace typedef long int integer by typedef int integer ,
since in the .f files the variable info is declared as integer, but
it is declared as int in liboctave .cc files
(so I wonder that it works in gcc! -- probably the dummy params are some
kind of buffer),
-- put EIG.obj into liboctave.lib manually (after that was done by
transfer from IDE to tlib -- that's mysterious, don't ask me why),
-- switch off "Local common expressions" optimizer switch.
As I declared above, the f2c translation is not optimal and it should be
manually corrected to achieve better performance. That has been already
done, and the optimized .c code of blas and lapack can be found in
netlib archive (netlib.att.com) in the directory clapack
(and that is the version it is recommended to use with LAPACK++ if no
fortran-compiled library is available for the machine one uses). That code
is C readable and really C optimized, no dummy parameters go through the
I would recommend you to replace the appropriate .f files in Octave's
libcruft by the corresponding .c from clapack. I suppose that it would
solve the problems described above. Moreover, I would advise you to compile
octave by different compilers, not just by gcc , since I found myself that
it is a good way to write a reliable C++ program. (I solely wrote a big program
that worked immediately under different compilers and different OSs).
Please, let me know who would be interesting to receive my patched sources,
Borland project files etc.
Unfortunately, after finishing the debugging of the Octave code, I made some
transformations on my matrices and found them to be symmetric. And their
eigenvalue problems are not supported by Octave, so I should take LAPACK++
or make it myself. That's bad luck...
By the way, the LAPACK++ documentation includes graphs comparing the
numerical power of it with respect to the original Fortran Lapack.
They are both equal. Have you performed similar tests using Octave's
C++ codes and Octave's macro (interpreter) language?
Good luck in programming,
*** Petr Mikulik ***
*** Department of Solid State Physics, Masaryk University ***
*** Kotlarska 2, 611 37 Brno, Czech Republic ***
*** tel: (42-5-)41129378 fax: (42-5-)41211214 ***
*** e-mail: address@hidden http://www.sci.muni.cz/~mikulik/ ***
| ... and a little bit of the theory of fun ... |
| Quantisation Revision of Murphy's Law: Everything goes wrong all at |
| once. |
- Octave C++ libs ported to Borland C++ for OS/2,
Petr Mikulik <=