On Thu, Mar 11, 2010 at 12:51:51PM -0800, Søren Hauberg wrote: > tor, 11 03 2010 kl. 11:55 +0100, skrev Olaf Till: > > On Wed, Mar 10, 2010 at 08:28:13PM -0800, Søren Hauberg wrote: > > > No thoughts on this? > > > > > > Søren > > > > > > tor, 25 02 2010 kl. 22:07 -0800, skrev Søren Hauberg: > > > > Hi All > > > > > > > > I tried to have a look at removing the scripts from the 'optim' package > > > > and integrate them with the functions using %!demo and %!test blocks. I > > > > was, however, not able to make the scripts run in the development > > > > version of Octave as lists has been completely removed (they have been > > > > deprecated for years). It seems the 'optim' package uses lists quite a > > > > bit. > > > > > > > > The general solution is to replace lists with cell arrays. I can just > > > > replace all lists by cell arrays, but I guess this will lead to API > > > > changes in the functions. My question is now: should we do other API > > > > changes at the same time? > > > > Do you mean other API changes in the affected functions or in other > > functions also? > > I don't know as I haven't studied the code closely. I just observed that > the 'optim' package will not work with Octave 3.4, which I consider a > problem (I believe this is one of the more important packages as it is > useful in so many fields). One way of getting rid of the usage of lists > is simply to disallow extra input arguments to the functions being > optimised. This would force people into using anonymous functions, which > would be fine by me as long as it is properly documented. > > > This touches the question of whether we should have common interfaces > > for the nonlinear optimization functions, as Matlab has with > > 'lsqnonlin' and 'lsqcurvefit'. They could be implemented as > > wrappers. I think common interfaces are reasonable, but possibly > > copying those of Matlab is not ideal. This would require much > > thinking, however ... > > Why would it be bad to copy the Matlab interfaces (I've never used them > so I'm asking out of ignorance) ? Are they simply poor interfaces?
I just meant that we should think that over. (One issue that occurs to me immediately is the name: 'lsq...' seems to stand for 'least squares', which is too special since one could have optimizers which optimize with respect to other things than least squares). To your original question, I'd now think that just the necessary change should be made (your suggestion of disallowing extra arguments since we have anonymous functions seems fine to me), and additional interface changes are not necessary so much since (IMO) there should be general wrappers anyway sometime. How to implement the latter could be discussed separately from the original problem. > In general it seems to me like 'optim' doesn't blend in as well with > more recent versions of Octave as it really should. The main problem > seems to be that both Octave and 'optim' comes with an implementation of > 'fminbnd'. I don't know which is better, but I don't like the > duplication. > > Søren > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
