Octave C++ libs ported to Borland C++ for OS/2

[Petr Mikulik]

    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 
files. 

  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 
stack. 

   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



***  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.                                                                |
------------------------------------------------------------------------