octave-maintainers
[Top][All Lists]
Advanced

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

Fwd: changeset: fsolve


From: Jaroslav Hajek
Subject: Fwd: changeset: fsolve
Date: Fri, 31 Oct 2008 13:18:10 +0100

---------- Forwarded message ----------
From:  <address@hidden>
Date: Fri, Oct 31, 2008 at 1:17 PM
Subject: Re: changeset: fsolve
To: "John W. Eaton" <address@hidden>


On Oct 31, 2008 12:39pm, "John W. Eaton" <address@hidden> wrote:
> On 31-Oct-2008, Jaroslav Hajek wrote:
>
>
>
> | please consider the attached changeset, reimplementing fsolve as
>
> | m-file function and removing the old fsolve code, including MINPACK.
>
> | The advantages we get using an m-file include:
>
> | 1. more understandable, modifiable and maintainable code (hopefully :)
>
> | 2. reentrancy
>
> | 3. will compute in single precision if given single precision inputs.
>
> | 4. possibly faster for large problems, because it uses blocked QR from
>
> | LAPACK instead of MINPACK's own implementation.
>
>
>
> These are all reasonable advantages.
>
>
>
> One disadvantage that I can see is that we no longer have a simple
>
> interface to use from liboctave, or in standalone programs.  But if no
>
> other parts of Octave other than the fsolve function were using that
>
> anyway, then it is probably not a significant problem for us directly.
>
> But there might be users out there who have been using the NLEqn
>
> class, so they will be surprised when it is missing in 3.2.  I don't
>
> know whether this is a sufficient reason to keep the old code around.
>
> I don't think anyone ever promised that liboctave provided a stable
>
> API.  Also, the code could probably be extracted from an old version
>
> of Octave and used in individual applications if needed.
>

True. There are a number of orphaned algorithm interfaces in liboctave
(NLP.h, FEGrid.h, LP.h, QP.h). Unlike the others,
NLEqn actually did something, but I guess that if we want all
algorithms to be available in liboctave, we should use m-files
as mere wrappers, which I don't think is a good idea. NLP and QP
already have working m-file implementations, so moving
these into liboctave would mean a lot of rewriting, with little
benefit, IMHO. FEGrid doesn't seem to have ever been used.
LP would only be a wrapper to GLPK, yet again that would mean a lot of
rewriting.

Personally, I'll be happy if liboctave only contains interfaces to
manipulation, combinatorial (searching, sorting) and core linear
algebra functions.
These are the "building blocks" for others. For instance, no one seems
to miss interpolation in liboctave, though IMHO it's more low-level
than fsolve.

>
>
> What happened to the doc string for fsolve?
>

I just forgot to add it (convert from the old version & maybe update).
Some internal functions (__fdjac__, __dogleg__) may also be missing
docs, but I guess that can be fixed afterwards. Er, and I should have
warned that this changeset depends on the previous ones I sent (except
fzero).
Should I update the patch, or is adding the missing docs in a separate
patch OK? Fell free to add it if you wish.

>
>
> jwe
>


-- 
RNDr. Jaroslav Hajek
computing expert
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]