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

[Matthieu Brucher]

2007/3/11, Alan G Isaac <aisaac at 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 ?

Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070311/8eb9ea63/attachment.html>