[SciPy-dev] Proposal for more generic optimizers (posted before on scipy-user)

Matthieu Brucher matthieu.brucher@gmail....
Sun Mar 11 13:43:41 CDT 2007

2007/3/11, Alan G Isaac <aisaac@american.edu>:
> I don't really have time to look at this for the
> next week, but a couple quick comments.

Thanks for the comments, I hope other people will help be with it :)

1.  Instead of::
>             if 'stepSize'  in kwargs:
>               self.stepSize = kwargs['stepSize']
>             else:
>               self.stepSize = 1.
>     I prefer this idiom::
>              self.stepSize = kwargs.get('stepSize',1)

Yes, true, I'll make the changes.

2. All optimizers should have a maxiter attribute,
>    even if you wish to set a large default.  This needs
>    corresponding changes in ``optimize``.

OK, it can be done, in fact in the C++ implementation I use, the maxiter is
a variable of the optimizer, not of the criterion.

3. It seems like ``AppendList`` is an odd and specific
>    object.  I'd stick in in the example file.

Yes, it can be put there, it was there for modularization.

4. I understand that you want an object that provides
>    the function, gradient, and hessian.  But when you
>    make a class for these, it is full of (effectively)
>    class functions, which suggests just using a module.

It's not only a module, it is a real class, with a state. For instance, an
approximation function can need a set of points that will be stored in the
class, and a module is not enough to describe it - a simple linear
approximation with a robust cost function for instance -

   I suspect there is a design issue to think about here.
>    This might (??) go so far as to raise questions about
>    the usefulness of the bundling.

Perhaps a more precise example of the usefullness is needed ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-dev/attachments/20070311/8eb9ea63/attachment.html 

More information about the Scipy-dev mailing list