Re: 3.2 status report

[Jaroslav Hajek]

On Wed, Aug 6, 2008 at 4:26 AM, John W. Eaton <address@hidden> wrote:
> On 30-Jul-2008, Jaroslav Hajek wrote:
>
> | I intend to handle this as part of the project to implement 
> Matlab-compatible
> | fzero, fminbnd, fsolve and lsqnonlin:
> | 
> http://www.nabble.com/List-of-most-highly-used-matlab-functions.-to18693110.html
>
> OK.
>
> Some code that I help to support uses fsolve fairly extensively and
> for various reasons needs to also run properly with the other leading
> brand.  I don't need 100% compatibility, just enough so that the code
> I have can work without change in that other program too.  I think all
> I really need is for Octave's fsolve to handle an options argument
> (the struct returned by optimset) and, as much as possible, to return
> compatible INFO values.  So those are probably the only changes I will
> make.  Unfortunately, these changes may break some existing Octave
> code, but I think compatibility is more important in this case.
>
> jwe
>

OK, I'll make this a priority. I'm currently in the process of
rewriting the HYBRJ driver from MINPACK into an m-file. It should not
be that hard, because QR factorization and QR rank-1 update are
readily available in Octave. The remaining building block is dogleg,
which could possibly be wrapped (libcruft/minpack/dogleg.f) but I have
a feeling that a m-file rewrite should also be simple, since the loops
in there are only employed for backsubs and level-1 ops. I'll try
submit first changesets to my repo soon, hopefully tomorrow or
tonight.
What we win by the rewrite is better clarity and maintainability,
automatic ability to work in single precision, and reentrancy. We lose
some memory efficiency (instead of compact QR storage, normal QR will
be used) and probably suffer a negligible performance loss
(there might be even a win for big dense problems because we call
LAPACK's blocked QR instead of the minpack's unblocked version).

If you just want a quickfix for the existing code, then go ahead.
Perhaps it is too late to get such a big change into 3.2.x - I intend
to get rid of the whole libcruft/minpack, for example.

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