[SciPy-dev] Proposal for more generic optimizers (posted before on scipy-user)
Sun Mar 11 13:43:41 CDT 2007
2007/3/11, Alan G Isaac <firstname.lastname@example.org>:
> 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']
> 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...
More information about the Scipy-dev