Re: I would like to collaborate

[Alfredo Esteban]

2009/2/23 Jaroslav Hajek <address@hidden>:
>
> 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 point 4 is interesting and suitable for my background.

Since now I will send my messages from this new address: aetoctave at
gmail dot com

Thanks,

Alfredo