octave-maintainers
[Top][All Lists]
Advanced

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

Re: best way to use new qrupdate version?


From: Jaroslav Hajek
Subject: Re: best way to use new qrupdate version?
Date: Fri, 9 Oct 2009 08:05:51 +0200

On Thu, Oct 8, 2009 at 10:06 PM, John W. Eaton <address@hidden> wrote:
> On  8-Oct-2009, Jaroslav Hajek wrote:
>
> | in version 1.1, which I intend to release later this year, qrupdate
> | will be able to compute rank-1 updates of LU and pivoted LU
> | factorizations. The SVN version already has the functionality. I want
> | to make the feature again available to Octave via a "luupdate"
> | function. The bulk of the code for Octave is already upstream:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/6f3ffe11d926
> |
> | Because there is 100% backward compatibility, I would like Octave stay
> | buildable with qrupdate 1.0, which by now has already spread to
> | several distros. The approach I've taken in the above patch is simply
> | check for one of the new functions after qrupdate was detected, and
> | define an additional macro. But maybe that is not the best idea? Does
> | anyone see a better way?
> | qrupdate uses a F77-style implicit interface, so there is no header
> | file, which could define a versioning symbol.
>
> Couldn't you define a function that returns a version string?  But
> even if you did that, I think a version test is not really a
> desirable thing to do in a configure script, and doing it with a
> function requires running a program, not just linking, so that can
> cause trouble for cross compiling (if that even matters for us).
>
> | An alternative is to make qrupdate 1.1 a requirement for Octave 3.4,
> | but it seems nice to support the old version if it's compatible.
>
> I guess the choice is yours.  Qrupdate is small and easy to build
> though, isn't it?  So it would not be a big burden to require the new
> version.  OTOH, if the older version will work (possibly with some
> loss of functionality) then continuing to allow its use would be OK
> with me.
>
> To check in configure, you could do something like this (untested):
>
> save_LIBS="$LIBS"
> LIBS="$BLAS_LIBS $FLIBS $LIBS"
> OCTAVE_CHECK_LIBRARY(qrupdate, qrupdate,
>  [qrupdate not found.  The QR & Cholesky updating functions will be slow.],
>  [],
>  [F77_FUNC(sqr1up,SQR1UP)],
>  [], [don't use qrupdate, disable QR & Cholesky updating functions],
>  [warn_qrupdate=
>   AC_CHECK_FUNCS([F77_FUNC(other_qrupdate_fcn,OTHER_QRUPDATE_FCN)],
>    [AC_DEFINE(HAVE_OTHER_QRUPDATE_FCN, 1)],
>    [warn_qrupdate="other_qrupdate_fcn missing; some loss of functionality"])])
> LIBS="$save_LIBS"
>
> jwe
>

It's close to what I did, except that I split the tests based on
$octave_qrupdate_ok defined from the first test.
If that's OK, I'll leave it as it is.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

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