Re: GSoC 2015: Optimization Package: Non-linear and constrained least squares lsqcurvefit, lsqlin, lsqnonlin

[Olaf Till]

On Wed, Feb 25, 2015 at 10:58:55AM +0100, Julien Bect wrote:
> <snip>
> I say this both as a developer of a toolbox/package [1, 2] that
> strives to remain compatible with both Octave (>=3.2.2, currently)
> and Matlab (>= R2007a, currently) and as someone who has seen
> several times how details of this kind (for instance, octave not
> having a function named fmincon, compatible with Matlab's one), when
> they accumulate (and they do), are able to prevent people from
> adopting Octave.

I'm curious, what relation have these people to Matlab -- have they to
buy Matlab privately, are they students whose University can't give
them licenses, ... ? What do they do after rejecting Octave, pay for
Matlab? My experience is that people with free access to Matlab don't
think of adopting Octave anyway, except they are personally interested
in Free Software.

That's no rethorical question only to object to you, I'm really
curious about the above.

> Take for instance fmincon. I am perfectly aware that it is not
> possible to get a 100%-similar implementation of this function,
> which is actually an umbrella over several types of complicated
> algorithms (sqp, active-set, interior-point), even with Matlab's
> documentation and all the textbooks and research papers in the
> world. Yet, I think that having a similar umbrella in Octave, with
> the same name, a compatible syntax and set of options, would be very
> useful. For instance, when fmincon is called with "Algorithm" set to
> "sqp", perhaps should we fall back on the sqp function as an
> optimizer. In other cases, if no solver of the same type is
> available, a warning could be issued that Octave's fmincon will
> switch to a different type of optimizer.

That's already 2:1 against me ... maybe there will be further votes,
but I've the feeling that the direction of the odds won't change.

If that'll be so, the project could indeed be to implement these
functions as wrappers:

1. 'lsqnonlin' wraps 'nonlin_residmin',

2. 'lsqcurvefit' wraps either 'nonlin_curvefit', 'nonlin_residmin', or
   even 'lsqnonlin',

3. 'fmincon' wraps 'nonlin_min',

and maybe

4. 'lsqlin' wraps ... (?).

One could state in the application that all the optimization
functionality is already there (don't know it for 'lsqlin'), but
careful mapping of Matlabs interface, in particular of the
optimization options, is necessary. (I've no notion on how
labour-extensive a gsoc project should be.)

To answer Nirs question: if it comes to it, I could help with 1., 2.,
and 3.. I'm currently not competent for 4.. But I wouldn't like to be
named at google as a mentor.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature