[Top][All Lists]

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

Re: More on binary packages and FFTW/ATLAS

From: John W. Eaton
Subject: Re: More on binary packages and FFTW/ATLAS
Date: Tue, 24 Feb 2004 23:35:18 -0600

On 20-Feb-2004, Paul Kienzle <address@hidden> wrote:

| One caveat --- there is no way to override xerbla in a dll.  We
| better be sure our code doesn't generate any errors!  I believe
| most uses of xerbla in Octave are from other packages in libcruft
| such as slatec, so this shouldn't be too difficult to do.

XERBLA is only used in the BLAS and LAPACK, and then only to report
illegal (sic) values for input parameters.  The only error message it
prints has the format

 9999 FORMAT( ' ** On entry to ', A6, ' parameter number ', I2, ' had ',
     $      'an illegal value' )

so provided that we are sure that we never call a BLAS or LAPACK
subroutine with invalid values, I think it should never be called.

Is it time to remove our private version of XERBLA and use whatever is
provided by the library?  The advantage of doing this is that we won't
need any tricks for trying to load our version instead of the one in
the library.  The disadvantage is that if there is a programming error
that results in an invalid parameter value, Octave will most likely
exit by executing a Fortran STOP statement (or similar -- what does
ATLAS do?) and not try to save the workspace.  But that should not
happen too frequently now.  I originally added the call to XSTOPX
instead of STOP because I wasn't confident that I would get all the
parameters right when calling BLAS and LAPACK routines, and I didn't
want Octave to be so unfriendly as to exit because of an error like

There are still a few other calls to XSTOPX in the following Fortran
files in libcruft:


As I recall, the slatec-err functions can be called for bad input as
well as other errors like failure to converge.  So we probably need
the modified versions of these routines.  I think that should not be
too much trouble.  I don't know of any widely used binary
distributions of these libraries and so I think we always use our own
version of the subroutines that call the slatec error handling
routines.  If some binary distributions of these subroutines do
appear, then maybe we will have to rethink these uses of XSTOPX as
well.  But we can always hope that if someone does start packaging
these routines, they will make them friendly for projects like Octave
that need them to avoid doing stupid things like executing STOP on


Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

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