From owner-help-octave at bevo dot che dot wisc dot edu Thu Nov 9 11:39:10 1995 Subject: Octave C++ libs ported to Borland C++ for OS/2 From: John Eaton To: Cc: help-octave at che dot utexas dot edu Date: Thu, 9 Nov 1995 11:36:01 -0600 Petr Mikulik wrote: : -- 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 don't know what you mean by `invariant' here. You should know that Octave uses the Complex stuff from libg++ because at the time I started writing Octave, there wasn't even a draft for a C++ library standard. I do plan to move to the standard complex classes eventually. : -- 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. Ok, but I'm not likely to change the names of these files just to avoid bugs in some proprietary compiler/linker. : 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 that particular file (lsame.f), it appears that the length parameters are not required. I don't see a problem there. : 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), I suspect that the real problem is the typedef in f2c.h. Perhaps the Octave library should also be more careful about the types it uses for these length parameters. I will see about fixing that. : -- 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), That sounds like a bug in the Borland compiler/IDE. Not much I can do about that. : -- switch off "Local common expressions" optimizer switch. I assume this is a switch for the Borland compiler? If so, perhaps there is a bug in the Borland compiler. Not much I can do about that either. : 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 Thanks for the pointer. : 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). I don't have any other compilers. I would like to make Octave portable, but I don't have time nor am I interested in trying to make Octave work with every broken compiler/OS combination that people might want to try to use. : Please, let me know who would be interesting to receive my patched : sources, Borland project files etc. Yes, I would be interested in knowing exactly what you had to change. Please send any diffs directly to me (see the file SENDING-PATCHES for tips on what is most useful for me). : 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... I've developed Octave's C++ libraries to be useful with Octave. I don't have time to worry about complete coverage of all classes of problems. If someone else does the work though, I'd be willing to consider merging in the changes. If you do want to work on this, please let me know so I can point you toward the latest sources. : 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? No, but I would expect the performance to be about the same as for the Fortran versions of the Lapack routines, since that is what Octave uses. Of course, there is some added overhead in setting up the various classes, but that is not likely to be a big factor for medium to large scale problems. Thanks, jwe