[SciPy-dev] [scikits] openopt SVN instable for the moment

dmitrey dmitrey.kroshko@scipy....
Wed Apr 9 13:40:50 CDT 2008


Alan Isaac wrote:
> On Wed, 09 Apr 2008, dmitrey wrote:
>   
>> If you want, I could propose you once again keeping 
>> (and/or installing from openopt installation) GenericOpt 
>> in separate scikit 
>>     
>
> We have just experienced some of the *advantages* of the 
> current structure and have not discovered any need to change 
> it, especially since Matthieu's most recent contribution.
> I suspect in the long-run some of Matthieu's work on generic 
> optimizers may migrate to SciPy proper, but right now it is 
> great to have it packaged with OpenOpt, since this withill 
> offfer substantial functionality even to those who install 
> no other solvers.
>   
Afaik Matthieu's optimizers have some unconstrained NLP solvers only 
(+mb some box-bound solvers for single-variable problems like golden 
section). OO has it as well w/o any additional sources (ralg, lincher, 
moreover, ralg with all constraints, lincher with box-bound).

As for my comment, I just propose to *install* genericopt as separate 
scikit, so users will have choice to use GenericOpt solvers from OO or 
directly (in last case it will be no any problems with importing python 
modules). It is much more good to have possibility to write "from 
scikits.genericopt import ..." than each time have to write "from 
scikits.openopt.solvers.optimizers import ...".

I still continue to think that openopt and genericopt intended audiences 
are very different + they serve different goals (BTW Matthieu by himself 
had said he not see his GenericOpt being served to wide audience).

I had already said long time ago (during GSoC 2007) that I want other 
solvers to remain their own API, to have no strict dependence on OO (so 
being OO-independent, and no problems like this one will be encountered 
anymore) - BTW it's better for solvers developer(s) by themselves, when 
there is always choice - to have more or less dependences, or, moreover, 
to remain absolutely independent on side packages.
And IIRC you not rejected the idea.

D.



More information about the Scipy-dev mailing list