[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.2 status report
From: |
John W. Eaton |
Subject: |
Re: 3.2 status report |
Date: |
Wed, 06 Aug 2008 10:17:45 -0400 |
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