[SciPy-user] OpenOpt svn broken on Windows

dmitrey dmitrey.kroshko@scipy....
Wed Jul 16 13:19:26 CDT 2008

Matthieu Brucher wrote:
>>> Algecan2 is supposed to have a clear interface, isn't it ? So you only
>>> have one wrapper per major version. This is done in other packages as
>>> well. And it is clearer that this is for algecan 2.x and not for
>>> algecan 1.x.
>> I meant not 2.0.1 vs 2.0.3 but 2.x vs 3.x vs ... as well
> algecan 3 will break your current model. I think that the fft wrappers
> for scipy are also named fftw2 and fftw3, so why not using it as well
> ?
I don't think ALGENCAN 3 will have other than ALGENCAN 2 API. If it will 
be different, I'll change algencan_oo.py once again. In any way I don't 
intend to maintain several ALGENCAN versions.
>>> It wasn't the case some time ago. But you still can do what I mean.
>>> I see that you can't register a new solver in OO on the fly and use
>>> your wrappers. Why didn't you make __solverPaths__ directly a
>>> dictionary that you populate then ? This way, you always have one
>>> __solverPaths__ that is not different accross modules, as it could be
>>> expected to be.
>> Because the solution you propose turn out to be a headache, especially
>> for me - and that's the main reason why I have removed your dictionary
>> __solverPaths__.
>> Each time I created solvers like "ralgELS", "ralg2" etc (with some
>> modifications to compare results with origin ralg) I have got a error
>> during execution and have to go to runProbSolver.py file to fix the
>> issue (as well as for connecting a new solver). Also, I was not fond of
>> those dozens of additional lines of code in rPS.py
> I didn't say that you shouldn't have done this, you obviously can, you
> have done it and it works. What I'm saying is that there were several
> purposes for this registry :
> - not polluting sys.path
> - allow a clean way of adding a solver
Adding a solver have been never more clear than current style: just add 
_oo file to any directory from /solvers, and it will work. Also, it was 
the way it works before your changes.
> For the moment, I think you have two places where you can do the second part :
> - ooMisc.py
> - runProbSolver.py
> Each time, it uses __solverPaths__. The funny thing is that
> __solverPaths__ in ooMisc is in fact never used or modified. 

> If it
> were a dictionary, it would be of some use.
> If you modify ooMic.__solverPaths__ after loading OO, you can't add a
> new solver, as it equals None. And you cannot add it before, as you
> have to load OO to get access to it. So I think it is
> runProbSolver.__solverPaths__ that should be used, but then,
> ooMic.__solverPaths__ really is just junk code that is of no use. Or
> have I missed something ?
__solverPaths__ is exported by runProbSolver.py, and than converted from None to
dict. I intended to init it in runProbSolver.py but some issues had
appeared (Python reported of bugs) so I had moved it to ooMisc.py

>>> Of course ;) but you should try to reuse your code at the beginning as well ;)
>> I don't know what code do you mean here, I had already moved some code
>> from ALGENCAN_oo.py to algencan_oo.py.
> It is one of the basis of agile development. Never copy code. What is
> cool with Python is that you can import the pieces you want. For
> instance, you can factor these code lines in a new package that you
> will import in each solver. This is especially important when you find
> a bug in one wrapper and you forget to apply it in the second wrapper.
> And it will work great with algecan3 if you can also reuse the same
> parts, as you will have a much shorter file to modify (and thus less
> headhache ;))
I understand the DRY issue, in fact, there is some code related to 
CVXOPT that is used by several solvers. But I when I created 
algencan_oo.py I intended to remove ALGENCAN_oo.py as soon as new file 
will be ready. However, I decided to remain it in repository for some 
more time, because old ALGENCAN passes some tests better than new ver. 
In anyway, soon it will be removed and the problem will gone away.
> Also, only 1 version of algencan
>> can be used with OO because both versions produce pywrapper.so file, and
>> only 1 can be used from PYTHONPATH. Of course, I can create a workaround
>> but I have lots of other things to do, especially to complite my GSoC
>> assigned tasks.
> I didn't know that there was only one filename. Is it something you
> build or is it something algecan provides ?
latter. pywrapper.so it generated by ALGENCAN. As I had mentioned, I 
could create a workaround but I have lots of other things to do.

More information about the SciPy-user mailing list