[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Eaton
Subject: Octave C++ libs ported to Borland C++ for OS/2
Date: Thu, 9 Nov 1995 11:36:01 -0600

Petr Mikulik <address@hidden> wrote:

: --  I should say now that I had to use the GNU complex.h, 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

: -- I had to rename all files with "-" in the name to "_"
: (e.g. to:, 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:
: -- 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

: 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 ( 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]