Jaroslav Hajek wrote:
> On Wed, Jul 22, 2009 at 5:54 PM, Jonathan Stickel<jjstic...@vcn.com> wrote:
>> I just checked in a small bug fix to the nelder_mead_min function
>> regarding some trouble with parsing the list or cell arguments.  Someone
>>  more familiar with the function might want to check that I didn't
>> break anything.  I did check that the test script test_nelder_mead_min_1
>> passes all tests.

I found that my fix was not quite right.  I have checked in another change.

>>
>> Many of the minimization functions make use of lists in their argument
>> passing.  This results in the warning
>>
>> warning: list objects are deprecated; use cell arrays instead
>>
>> It would be helpful if the authors of these functions could clean the
>> functions up to use exclusively cell arrays.
>>
>> One last note: I noticed that someone ('highegg') recently changed the
>> names of fminunc and fzero to fminunc_compat and fzero_compat.  Why the
>> name change?  Wouldn't Matlab compatibility be better achieved by using
>> exactly the same name used in Matlab?  I use fminunc in some of work,
>> including the data smoothing functions I contributed to the data
>> smoothing package.
>>
> 
> the change is due to the fact that fminunc and fzero are now in core
> Octave, so to avoid a name clash.
> I think Octave's fzero is more Matlab compatible than the one in
> OctaveForge, but otherwise roughly equivalent in functionality, so
> maybe fzero_compat can be dropped. fminunc_compat (former fminunc) is
> a mere wrapper to minimize.
> 

OK, good to know about fminunc and fzero in octave proper.  I know that 
the old fminunc was a wrapper for minimize, but I preferred the user 
interface of fminunc.  I seem to have found a bug for the new fminunc 
that I will report on the bugs list.

BTW, I find it confusing that optimization functions are split between 
Octave and the octave-forge package.  At one point, I thought there was 
a plan to keep associated functions together, either all in Octave or in 
the appropriate octave-forge package.  I guess the split remains more 
development oriented: polished functions make it to Octave where as 
rough contributions remain in octave-forge.

Regards,
Jonathan

------------------------------------------------------------------------------
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev

Reply via email to