On Wed, Feb 22, 2012 at 10:09 AM, Olaf Till <olaf.t...@uni-jena.de> wrote:
> On Tue, Feb 21, 2012 at 12:40:57PM -0800, muhali wrote:
> > I stumbled upon this issue before, see e.g. here:
> >
> > http://sourceforge.net/mailarchive/message.php?msg_id=25650593
> >
> > My question is: Are there any plans to make the optim package use options
> > structures (as opposed to arrays), such as from the optimset function?
>
> "The optim package" is heterogenous. There are some functions whose
> authors do not participate anymore and where maintanance is currently
> restricted to more or less trivial fixes. This applies to the direct
> search algorithms (nelder_mead_min, adsmax, mdsmax, nmsmax) which
> would be an alternative to fminsearch which your refer to.
>
> There are some functions in optim which use the optimset
> mechanism. But AFAIK there are currently no plans to convert the above
> functions to optimset. There could be the problem of breaking existing
> code when doing this. The best way IMO would be to split out the
> actual algorithms of adsmax, mdsmax, nmsmax and maybe nelder_mead_min
> (I cannot say if one of nmsmax or nelder_mead_min could replace the
> other) into extra private functions, which can be called by adsmax
> (mdsmax, ...) providing the original interface, but can also be called
> by an interface based on optimset. (One could also simply wrap adsmax,
> (mdsmax, ...) by an optimset-based interface, but then one would
> always be limited by the features of the internally used old
> interface.)
>
> > This way one could actually use optimization code originally written for
> > matlab.
>
> If you give the interface the same name and make it behave the same
> way. Personally, I think it is not so important to be able to execute
> code calling Matlab optimization functions without changing these
> function calls. You cannot expect the same results anyway; the
> algorithms are different and optimization is potentially
> problematic. But I think that being able to use the optimset mechanism
> could be good.
>
> If you, desiring Matlab compatibility, should rewrite fminunc to use
> optimset, you probably should include a further option to choose
> between the different direct search agorithms available in optim.
>
> Regards,
>
> Olaf
>
>
I'm the original author and occasional maintainer of samin and bfgsmin.
These functions don't use the proposed interface. The reason for this is
that they are written to optimize functions that may be computed using
parallel processing on multiple cores or over a cluster. At the time I
wrote them, putting all arguments in a cell array seemed like a good
solution, and apart from its idiosyncrasy, I still think it's a reasonable
solution. If the Matlab interface could still allow for objective functions
that might be computed in parallel, I wouldn't mind using it. However, I
don't have time to work on the change. If anyone would like to try it, I
could provide an example of the type of code that I would like to avoid
breaking beyond repair.
Michael
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
