Re: I would like to collaborate

[Jaroslav Hajek]

On Mon, Feb 23, 2009 at 11:17 AM, Alfredo Esteban <address@hidden> wrote:
> 2009/2/22 Jaroslav Hajek <address@hidden>:
>>
>> Btw, right now, a major release is coming soon, so we're in a sort of
>> bug-fixing state (and discussing what's a bug and what isn't :)
>> There'll be plenty of room for new projects afterwards. I can share
>> some of my plans if you're interested.
>>
>
> Yes, I am interested. This way I could start working with something
> specific. I think this is the better way to learn.
>

OK. What I've been thinking about for 3.2 include:

1. Clean-ups and design simplification in liboctave (the "core"
computational library). Especially the Array class tree I see as
overly complicated - things like ArrayN really add no functionality
when Array<T> itself has multidimensional capabilities. Also, there's
a lot of code duplication amongst NDArray/Matrix. Ideally, I think we
should end up with something close to
Array -> MArray -> *NDArray (of various types) -> *Matrix (of various types).
This is a mostly programmatical task, but it's probably a great way to
practice and learn C++.
Also, I would like to start incrementally documenting liboctave by
using doxygen or something similar,
and drive it towards thread-safety.

2. Lazy indexing expressions.
With this I intend to answer the "last Matlab indexing defect",
concerning the hardcoded one-based indexing
and using real type as default for index vectors returned from
functions like find, min etc. I would like these functions to instead
return a value of class lazy_index, that would be able to hold an
idx_vector object plus an optional integer offset,
and would only convert itself to a real matrix when needed.
Currently, doing stuff like
`i = find (y); a = x(i)' involves the overhead of converting a
zero-based index vector (returned internaly from find) to a one-based
real vector, and then back again. Since index vectors are typically
used again for indexing, the lazy scheme would avoid such overheads. I
have yet, however, investigate how much can be saved.

3. Lazy boolean expressions.
Observing various m-file sources, I'm convinced that typically the
most complex vector expressions are found
in logical expressions passed into functions such as "find" or "all".
For instance, "all (x > 0 & x < 1) involves
creating 2 temporary logical vectors, while in principle the
expression could be computed in a single pass, thus reducing
memory consumption and speeding up the operation due to better
locality of reference.
It would be nice to create again a lazy evaluation mechanism.

4. Write high-quality m-file implementations of fminbnd and fminunc,
improve the existing fzero and fsolve. For 3.2, I created m-file
implementations of fzero and fsolve, to deal with single nonlinear
equations or a system of those. fminbnd (univariate optimization) and
fminunc (multivariate unconstrained local optimization) are, in a
certain sense, their natural counterparts, so I would like them to be
part of Octave to complete the capabilities. More sophisticated
methods like Nelder-Mead search (fminsearch) will probably stay in
OctaveForge.
The implementations should have a mostly Matlab compatible interface
where possible, and should use the new optimset/optimget system. Some
code can maybe be ported from OctaveForge.
fminunc should probably use a trust-region (or, optionally, line
search) BFGS (Quasi-Newton) algorithm, and should be
able to exploit cholupdate for the BFGS update, or, optionally, the
Nocedal's limited-memory approach (which can probably be taken from
OctaveForge). fminbnd should use some inverse interpolation method
combined with a golden section search (the current OctaveForge version
does only golden section search), as described e.g. in Numerical
Recipes.

5. Find a way to optionally employ QR and/or Cholesky updating
procedures in qp/sqp to increase performance. This has been successful
with lsqnonneg and therefore I'm optimistic about the possibility,
though I now know little about quadratic programming.

6. Optimize accumarray, erfinv and some other functions.


>> I think a good way to start is
>> to find something you'd wish to improve, then discuss that on the
>> mailing list. That's how I started anyway.
>>
>> Another great way to help Octave is to write high quality packages for
>> OctaveForge.
>>
>
> I think something related to optimization should be suitable for me. I
> will find anything in this area.
>

This is an interest we share, apparently.



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