Re: 3.2 status report

[John W. Eaton]

On  6-Aug-2008, Jaroslav Hajek wrote:

| 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).

I don't object to a change like this if the performance hit is not too
large.  If it is, then perhaps we should consider rewriting it as a
template-based C++ function or class?

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

All I'm really interested in at the moment is to make the interface
compatible.  I think that is a separate issue from how the internals
work, so our changes should not be overlapping much.

jwe