From owner-help-octave at bevo dot che dot wisc dot edu Wed Nov 8 10:51:07 1995 Subject: Octave C++ libs ported to Borland C++ for OS/2 From: "Petr Mikulik" To: help-octave at che dot utexas dot edu Date: 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 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: mikulik at sci dot muni dot cz 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. | ------------------------------------------------------------------------