Norbert Nemec | 1 Sep 11:35
Picon
Picon

Re: 0.6.x branch created

Ondrej Certik wrote:
>> This hasn't happened again, so I mention it just in case anyone else
>> sees the problem (perhaps a test with random data that happened not to
>> converge?)
>>     
>
> I think there shouldn't be any random data in the tests, for exactly
> the reason above, that you will not able to reproduce the bug anyway.
>   

To be exact: whereever pseudo-random data is used, it should be seeded
deterministically.
(I'm pretty sure that true random data is not used anyway)
Ondrej Certik | 1 Sep 18:59
Picon
Gravatar

Re: Documentation to SciPy

> I like the direction you are going with the Documentation page.  I
> completely agree that we need to move toward simplification and
> streamlining the documentation.  Please go ahead, update it, and make
> your new Documentation page the official one.  I added a TOC to the
> page, which doesn't look particularly attractive.  It would be great
> if you could tidy up what I did.

I didn't find a way how to make the contents nice at the moment, so I
deleted it (it can of course be put back at any time).

>
> If you are willing to do it, I would like to ask you to become the
> official maintainer of this page.  I think that this page should be
> aimed at the new user.  This means that when someone comes to it for
> the first time they shouldn't be overwhelmed with information.  It
> should also be easy to find everything you need.  Obviously, this
> trade-off will involve careful consideration.

I think it's quite polished already. If I find time, I'll try to make
it even simpler.

How is the new release going? In the meantime, I updated the Debian
package to 0.5.2.1 and it should be finally working.

Ondrej
Nils Wagner | 5 Sep 19:17
Picon
Favicon

NameError: global name 'sp' is not defined in r3302

Hi all,

A name error was introduced with the recent changes.

======================================================================
ERROR: check_get_submatrix 
(scipy.tests.test_sparse.test_csr)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sparse/tests/test_sparse.py", 
line 645, in check_get_submatrix
     a = sp.csr_matrix( array([[1,2,3],[1,2,3],[0,2,0]]) )
NameError: global name 'sp' is not defined

Cheers,
          Nils
Nathan Bell | 5 Sep 19:38
Picon
Gravatar

Re: NameError: global name 'sp' is not defined in r3302

On 9/5/07, Nils Wagner <nwagner <at> iam.uni-stuttgart.de> wrote:
> Hi all,
>
> A name error was introduced with the recent changes.

Thanks for the report.  It's been fixed in r3303

--

-- 
Nathan Bell wnbell <at> gmail.com
Ryan Krauss | 6 Sep 04:52
Picon

numpy.float64*poly1d = array

I filed a ticket for this and I guess it is technically a numpy
problem, but I am curious about it.  One line recreates the problem
for me:

numpy.float64(10.0)*poly1d([1,-1])

returns
array([ 10., -10.])

I went in and added a little debugging print statement to the __mul__
and __rmul__ methods of poly1d, and neither is called when the
numpy.float64 instance is on the left.

poly1d([1,-1])*numpy.float64(10.0)
calls __mul__ and works fine.

10.0*poly1d([1,-1])
calls __rmul__ and works fine.

I got myself in this situation by multiplying a poly1d by a constant
taken from an array, which is a numpy.float64 instance.

This seems to indicate that
numpy.float64(10.0)*poly1d([1,-1])

is handled entirely by the float64 __mul__ method without calling
__rmul__ of poly1d.  Does that seem possible?  I think that is what is
happening because my cheesy
print('in rmul')  statement isn't triggered.

(Continue reading)

dmitrey | 6 Sep 20:00
Favicon

openopt (prelimenary) announce

Hi all,
here's a message that I intend to publish in Python and scipy-user mail lists, some changes were made by Alan Isaac.
If you don't mind I want to publish it before in scipy-dev mail-list, maybe you would like to propose some changes.
Regards, D.

Announcing: OpenOpt (a SciPy scikit)
====================================

OpenOpt is new open source optimization framework, provided as a SciPy scikit.

Goal: provide an essential open source alternative to TomOpt TOMLAB <http://tomopt.com/tomlab/>
(optimization framework for MATLAB) and related commercial optimization frameworks and solvers.

key features are: a unified calling interface for all solvers,
a variety of pure Python solvers, graphic output
<http://openopt.blogspot.com/2007/09/examples-of-openopt-graphics-output.html> and
connections to 
numerous external solvers.

Example::

    from scikits.openopt import NLP
    p = NLP(lambda x: (x-1)**2, 4)
    r = p.solve('ralg')

In this example,
the objective function is (x-1)2,
the start point is x0=4,
and 'ralg' specifies the name of solver involved.

(Continue reading)

Matthieu Brucher | 6 Sep 20:41
Picon

Re: openopt (prelimenary) announce

Hi,

Excellent preliminary announce, but this can be confusing :

The OpenOpt project was sponsored by Google throught the GSoC program (Google Summer of Code). Most of code was written by GSoC student Dmitrey Kroshko (Optimization Department, Cybernetics Institute, Ukrainian Science Academy, and the dept staff suggestions were very useful) under the mentoring of SciPy developers Alan G Isaac and Jarrod Milman.

I don't know exactly how much you wrote (in terms of number of caracters), but I don't think that "most of the code" is the right locution. You can perhaps write that it was written by both of us ?

Matthieu
_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Alan G Isaac | 6 Sep 20:55
Picon
Favicon
Gravatar

Re: openopt (prelimenary) announce

On Thu, 6 Sep 2007, Matthieu Brucher apparently wrote:
> I don't know exactly how much you wrote (in terms of 
> number of caracters), but I don't think that "most of the 
> code" is the right locution. You can perhaps write that it 
> was written by both of us ? 

I think Dmitrey makes a conceptual distinction
between the OpenOpt framework and the optimizers
it relies on. Your project he referred to here as 
GenericOpt. (Your name?) I think this distinction
captures well where the two of you put your main efforts?
I realize now that I made that distinction as well, so I did 
not "stumble" where you did in reading it.  This in fact may 
be a bit confusing, so a proper rephrasing is needed.  Sorry 
for missing that.

Cheers,
Alan Isaac
dmitrey | 6 Sep 22:18
Favicon

Re: openopt (prelimenary) announce

Alan G Isaac wrote:
> On Thu, 6 Sep 2007, Matthieu Brucher apparently wrote:
>   
>> I don't know exactly how much you wrote (in terms of 
>> number of caracters), but I don't think that "most of the 
>> code" is the right locution. You can perhaps write that it 
>> was written by both of us ? 
>>     
>
> I think Dmitrey makes a conceptual distinction
> between the OpenOpt framework and the optimizers
> it relies on. Your project he referred to here as 
> GenericOpt. (Your name?) I think this distinction
> captures well where the two of you put your main efforts?
> I realize now that I made that distinction as well, so I did 
> not "stumble" where you did in reading it.  This in fact may 
> be a bit confusing, so a proper rephrasing is needed.  Sorry 
> for missing that.
>
> Cheers,
> Alan Isaac
>
>   
so, despite I insisted optimizers remain also as separate package, the 
idea of merging optimizers(/GenericOpt) to openopt, as I suppose from 
the very beginning, wasn't the best one, partially because they serves 
different goals and different motivations.

Maybe we should handle these packages separately (providing connection, 
of course)?
Then we could make 2 announcements: one of openopt release and one of 
optimizers/GenericOpt.

As another solution, we could announce in one message 2 scikit modules - 
OpenOpt and GenericOpt (or optimizers), where GenericOpt is supplied 
with connection to OpenOpt. Also, afaik, it's possible to implement in 
setuptools automatic download of GenericOpt while installing openopt (in 
any way, I don't mind if Matthieu want to continue host a part or all 
his code in /solvers/GenericOpt and /solvers/optimizers directories as 
it is now).

The problem of "openopt" word is not 100% mine - the problem is that I 
discussed the term with our dept, and they were quite agree to provide 
quite good maintain to "our openopt project" (at least with their 
advices), but what should I say them that now, when they will ask like 
"what? we discussed to be single author and now we are just one of lots, 
with undefined exactly rights - for name ("What?! Our OpenOpt is no 
longer our?!" - would it be scipy-owned, I could so-so silently avoid 
the (one of biggest) question, but real humans is much more big 
problem), for sponsor's income sharing (if it will be), etc, so each 
time we intend to do something we should discuss (and maybe even more - 
take agree) from foreign language speaker(s)? nope, we are not 
interested anymore..." :(

As for names, we could (as one of possible solutions) don't mention them 
at all.

Regards, D.
P.S. Maybe Alan or someone else will remind me once again - scipy team 
decided to get all rights of the GSoC code to itself, and all those my 
words that I had wrote to my mentors doesn't matter. Ok, I don't mind, 
you really have the right, the only thing I would say is that I hadn't 
know it from the very beginning (it's very unlikely that I would cease 
openopt development because of this, but at least I would reorganize 
some openopt tasks priorities, that would simplify openopt maintenance 
by someone else, should I cease maintenance because of my dept's demand 
to switch to other projects and/or other reasons).
As someone from scipy dev team said like "GSoC project is just a way to 
deter is a student appropriate for work in a team" (so it sounds like 
they don't care very much about results obtained and who is their 
owner), and, as
 http://code.google.com/support/bin/answer.py?answer=60327&topic=10728
says, the situation is unclear - and very bad if the question arises in 
a middle or end of program (as for me I think it's not my or mentors 
failure - it's a serious GSOC drawback that should be fixed, the 
question must be discussed between student and organization from the 
very beginning, maybe even when organization only appeared in GSoC 
members list it should inform who will be copyholder of student's code).

Ok, I think I said all my thoughts about the problem, if Matthieu and/or 
mentors team will find my suggestions inappropriate, let mentors (and/or 
scipy dev team, and/or Python GSoC 2007 administrator JamesTauber 
<http://wiki.python.org/moin/JamesTauber> - as you wish) decide which 
text to publish (as code owners you even could do it by yourself if you 
want to (announce your openopt), I don't mind, or you could send final 
text to me to publish).

Regards, D.
Alan G Isaac | 6 Sep 23:50
Picon
Favicon
Gravatar

draft announcement

Hoping Dmitrey and Matthieu (and others) like this ...
Alan Isaac

OpenOpt and GenericOpt
======================

OpenOpt and GenericOpt are 100% Python
with a single dependency: NumPy.

OpenOpt
-------

OpenOpt is new open source optimization framework.
OpenOpt is released under the BSD license.

The primary author and current maintainer of
OpenOpt is Dmitrey Kroshko.
(Optimization Department, Cybernetics Institute, Ukrainian Science Academy)

OpenOpt goal: provide an open source alternative
to TomOpt TOMLAB (optimization framework for MATLAB)
and related optimization frameworks.  Currently OpenOpt
offers connections to a variety of open source solvers,
primarily for unconstrained optimization. (See below.)

OpenOpt provides provides connections a vraity of solvers,
including those in GenericOpt, which are included.
(Users will need to download other solvers;
we provide URLs for download.)

GenericOpt
----------

GenericOpt is a toolkit for building specialized optimizers.
GenericOpt is released under the BSD license.

The primary author and current maintainer of GenericOpt is Matthieu Brucher.

GenericOpt goal: provide an open source, extensible
toolit for "component-wise" construction of specialized
optimizers.  GenericOpt allows users who want detailed control to construct
their own solvers by choosing among a variety of algorithm components
(currently, most choices are among step and line-search algorithms.)

Usage: see Matthieu's tutorial 
<URL:https://projects.scipy.org/scipy/scikits/wiki/Optimization/tutorial>.  

Limitation: currently GenericOpt provides only unconstrained solvers. 

SciKits
-------

The SciPy project is developing a collection of open source packages for
scientific computing which are allowed to have more dependencies and
more varied licenses than those allowed for SciPy proper.
In contrast to SciPy, the related scikits may host any 
OSI-approved licensed code.

OpenOpt and GenericOpt are available together as a
SciPy scikit.  However, neither depends on the other.

OpenOpt Details
---------------

Key feature: a unified calling interface for all solvers,
a variety of pure Python solvers, and connections to 
numerous external solvers.

Example::

    from scikits.openopt import NLP
    p = NLP(lambda x: (x-1)**2, 4)
    r = p.solve('ralg')

In this example,
the objective function is (x-1)^2,
the start point is x0=4,
and 'ralg' specifies the name of solver involved.

See much more detailed example here

<URL:http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nlp_ALGENCAN.py> 

OpenOpt Connected External Solvers
----------------------------------

Non-linear problems (NLP)
~~~~~~~~~~~~~~~~~~~~~~~~~

- ALGENCAN <http://www.ime.usp.br/%7Eegbirgin/tango/py.php> 
  (GPL)
- lincher (BSD) (all types of constraints and 1st derivatives),
- ralg (BSD) (currently unconstrained only)
- scipy_tnc and scipy_lbfgsb (box-bounded, requires scipy 
  installed, BSD)

Non-smooth problems (NSP)
~~~~~~~~~~~~~~~~~~~~~~~~~

- ralg (BSD)
- ShorEllipsoid (BSD)
  (for small-scale problems with nVars = 1..10, former for 
  medium-scaled problems with nVars = 1...1000, requires r0)

Both are unconstrained for now.

Linear problems (LP)
~~~~~~~~~~~~~~~~~~~~

- lp_solve <http://sourceforge.net/projects/lpsolve> (LGPL)
- glpk <http://www.gnu.org/software/glpk/> (GPL)
- CVXOPT <http://www.ee.ucla.edu/%7Evandenbe/cvxopt/> (GPL) 
  (currently glpk requires CVXOPT installed)

Mixed-integer problems (MILP)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- lp_solve <http://sourceforge.net/projects/lpsolve> 

Quadratic problems (QP)
~~~~~~~~~~~~~~~~~~~~~~~
- CVXOPT <http://www.ee.ucla.edu/%7Evandenbe/cvxopt/> (GPL) 
  (please note - NLP lincher solver requires QP solver, and 
  the only one for now is CVXOPT one)

Here you can look at examples for NLP

<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nlp_1.py>, 
NSP

<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nsp_1.py>, 
QP

<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/qp_1.py>, 
LP

<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/lp_1.py>, 
MILP

<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/milp_1.py> 
usage 

Acknowledgements
================

Development of OpenOpt was supported by Google through the 
Google Summer of Code (GSoC) program, with Alan G. Isaac
as mentor.  Additonal mentorship was provided by Jarrod Milman. 
Debts to the SciPy community are many.

Appeal
======

The primary author and current maintainer of OpenOpt is Dmitrey Kroshko.  The
primary author and current maintainer of GenericOpt is Matthieu Brucher.
OpenOpt would profit from additiona intensive development, but this will
require a sponsor.  The use of Python for scientific programming is only
nascent in the Ukraine, so really an outside sponsor is needed.  Ideas or leads
are very welcome.

Gmane