Mailman 3 August 2007 - SciPy-Dev

SciPy 0.6.0 release planned for August 31st
by Jarrod Millman Aug. 22, 2007

Aug. 22, 2007

Hello everyone, Now that SciPy 0.5.2.1 is out the door it is time to get a new feature release done as well. SciPy 0.5.2 was released over 8 months ago (2006-12-07) and a lot of things have been improved and fixed since then. After talking with Travis Oliphant and Robert Kern (as well as quite a few other people at the SciPy conference), we decided to overhaul the release process. On Monday, August 27th, I will make a 0.6.x branch. I would like to release 0.6.0 on Friday, August 31st. Continued development will occur on the trunk and will lead to a 0.7.x branch 3 months later on Monday, November 26th. If there are any important bugs in the 0.6.0 release we will make a 0.6.1 release and so on. I have started putting together a 0.6 roadmap here (it should mostly be a list of major things that have already been added or fixed): http://projects.scipy.org/scipy/scipy/milestone/0.6 Please don't make any major changes to the trunk between now and next Monday. If you can I would like to ask everyone to look through the open tickets and close anything that has already been fixed. Even better if you see something that you can easily fix without breaking something else, please do so. If you find a ticket that should be a release blocker, please let me know ASAP. Currently, there are 4 release blockers that I want fixed before making the 0.6.0 tag: http://projects.scipy.org/scipy/scipy/ticket/238 http://projects.scipy.org/scipy/scipy/ticket/401 http://projects.scipy.org/scipy/scipy/ticket/406 http://projects.scipy.org/scipy/scipy/ticket/482 I wanted to get this timeline out ASAP, but there has been a lot of discussion recently about packaging. I agree that we need to get packaging sorted out as well. I will send out my thoughts about packaging later today. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

3 2

problems with scikits svn
by dmitrey Aug. 21, 2007

Aug. 21, 2007

svn: PROPFIND request failed on '/svn/scikits/trunk/openopt/scikits/openopt/solvers/optimizers/line_search/tests' svn: PROPFIND of '/svn/scikits/trunk/openopt/scikits/openopt/solvers/optimizers/line_search/tests': Could not read status line: Connection reset by peer (http://svn.scipy.org)

2 2

optimizers module
by dmitrey Aug. 21, 2007

Aug. 21, 2007

hi all, I'm trying to connect a new optimizer (line-search via cubic interpolation) to Matthieu's code. Here are some things that should be discussed, I guess in wide circle. I have already committed ./solvers/optimizers/line_search/qubic_interpolation.py tests/test_qubic_interpolation.py the problems: 1. I have implemented stop tolerance x as self.minStepSize. However, isn't it more correct to observe |x_prev - x_new| according to given by user xtol, than to observe |alpha_prev - alpha_new| according to xtol? If the routine is called from a multi-dimensional NL problem with known xtol, provided by user, I think it's more convenient and more correct to observe |x_prev - x_new| instead of |alpha_prev - alpha_new| as stop criterion. 2. (this is primarily for Matthieu): where should be gradtol taken from? It's main stop criterion, according to alg. Currently I just set it to 1e-6. 3. Don't you think that maxIter and/or maxFunEvals rule should be added? (I ask because I didn't see that ones in Matthieu's quadratic_interpolation solver). It will make algorithms more stable to CPU-hanging errors because of our errors and/or special funcs encountered. I had implemented that ones but since Matthieu didn't have them in quadratic_interpolation, I just comment out the stop criteria (all I can do is to set my defaults like 400 or 1000 (as well as gradtol 1e-6), but since Matthieu "state" variable (afaik) not have those ones - I can't take them as parameters). So should they exist or not? regards, D.

2 5

SciPy 0.5.2.1 release
by Jarrod Millman Aug. 21, 2007

Aug. 21, 2007

I'm pleased to announce the release of SciPy 0.5.2.1 This a minor bug fix release. Bug-fixes =============== * Replaces ScipyTest with NumpyTest * Fixes mio5.py as per revision 2893 * Adds missing test definition in scipy.cluster as per revision 2941 * Synchs odr module with trunk since odr is broken in 0.5.2 * Updates for SWIG > 1.3.29 and fixes memory leak of type 'void *' Thank you to everybody who contributed to the recent release. Enjoy, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

1 0

NumPy 1.0.3.1 released
by Jarrod Millman Aug. 21, 2007

Aug. 21, 2007

I'm pleased to announce the release of NumPy 1.0.3.1 This a minor bug fix release, which enables the latest release of SciPy to build. Bug-fixes =============== * Add back get_path to numpy.distutils.misc_utils * Fix 64-bit zgeqrf * Add parenthesis around GETPTR macros Thank you to everybody who contributed to the recent release. Best regards, NumPy Developers http://numpy.scipy.org

1 0

scipy and scikits tracs use the same password file now
by Jeff Strunk Aug. 20, 2007

Aug. 20, 2007

Since Dmitrey was unable to login to the scikits trac, I realized that the scikits new users were actually registered on the scipy trac's password file. However, the webserver was authenticating from the scikits password file. I changed the webserver settings so the scikits trac authenticates from the scipy password file. If you find you can't login to the scikits trac, please try your scipy trac password. Thank you. I'll be more responsive when I return from my vacation on Monday. Jeff

1 0

Re: [SciPy-dev] NumPy 1.0.3.x and SciPy 0.5.2.x (Fernando Perez)
by Joe Harrington Aug. 20, 2007

Aug. 20, 2007

As someone who is teaching a new course in numpy starting tomorrow, I want to echo Fernando's email, and add a quick request. I'll take the risk that the same thing was decided a different way at the conference, but if it was, please just let me and the other list readers know. First, a major thanks to everyone who works on making numpy and scipy a turn-key install. Though there is a ways yet to go, things have come a long way. Perhaps the most pleasing thing for me as an early advocate has been the rise in the percentage of list traffic devoted to packaging and releasing for the masses. I would very much like to see the "use SVN" instruction banished forever from the download page. But, the goal of a no-brainer install for Mac, PC, and the major Linux flavors does not seem unachievable anymore, and of course we're there for many of the Linux systems. My request is in the direction of transparency on the release cycle. I know the release of NumPy 1.0.3.1 and SciPy 0.5.2.1 is imminent, and I look forward to it very much. How does it go from a tarball to, say, a .deb in the Ubuntu repo? How long does it take for that process and who does it? How much of that is in "our" control and how much of it is in the OS vendor's/distro's control? I would favor this being part of a "Release Status" page linked off the Download page. The top item would be a chart showing the release steps across the top and the names of the distros we build for down the side. There would be one such chart for each active release of numpy and of scipy. They would contain green checks for done items, a black X for not doing, a green dash for not necessary, a red exclamation point for a problem, etc. Below that, there would be a short description of how a release goes from tarball to OS packages. The page should also include the names of people or lists to which to send questions like the inevitable "Version XXX of YYY has been out for weeks now, when will I be able to get it with my OS's installer?" This would also act as a way to connect potential helpers with problems to solve on the release side of the house. I'd make it and populate it, in the wiki way, except I have essentially none of the necessary information for the page. So, I'll leave it at that and hope someone who does takes interest. Either way, if someone could let us know what to expect in terms of the new releases getting out to the repos, that would be greatly appreciated, even if it's just a rough guide. Thanks again for all the hard work on packaging! --jh-- Prof. Joseph Harrington Department of Physics MAP 420 University of Central Florida Orlando, FL 32816-2385 (407) 823-3416 voice (407) 823-5112 fax (407) 823-2325 physics office jh(a)physics.ucf.edu (direct) jh(a)alum.mit.edu (permanent forwarding address, will work forever)

1 0

NumPy 1.0.3.x and SciPy 0.5.2.x
by Jarrod Millman Aug. 20, 2007

Aug. 20, 2007

Hello, I am hoping to release NumPy 1.0.3.1 and SciPy 0.5.2.1 this weekend. These releases will work with each other and get rid of the annoying deprecation warning about SciPyTest. They are both basically ready to release. If you have some time, please build and install the stable branches and let me know if you have any errors. You can check out the code here: svn co http://svn.scipy.org/svn/numpy/branches/1.0.3.x svn co http://svn.scipy.org/svn/scipy/branches/0.5.2.x Below is a list of the changes I have made. NumPy 1.0.3.1 ============ * Adds back get_path to numpy.distutils.misc_utils SciPy 0.5.2.1 ========== * Replaces ScipyTest with NumpyTest * Fixes mio5.py as per revision 2893 * Adds missing test definition in scipy.cluster as per revision 2941 * Synchs odr module with trunk since odr is broken in 0.5.2 * Updates for SWIG > 1.3.29 and fixes memory leak of type 'void *' Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

4 4

report on some tickets related to scipy.optimize
by dmitrey Aug. 19, 2007

Aug. 19, 2007

hi all, let me inform you about a summary of ticket work, according to Alan Isaac demand. all tickets assigned to me are mentioned here. ====================== Pending ------- http://projects.scipy.org/scipy/scipy/ticket/344 should be closed changeset [3172] <http://projects.scipy.org/scipy/scipy/changeset/3172>, it had been fixed and now all fmin_cg tests known to me, including unittests, pass ok the problem was in _cubicmin func, it used Num.dot([[dc**2, -db**2],[-dc**3, db**3]],[fb-fa-C*db,fc-fa-C*dc]) and it gave incorrect multiply with current numpy version (matrix of shape 2x2x1 times matrix of shape 2x2 or like that) http://projects.scipy.org/scipy/scipy/ticket/384 tnc: TypeError: argument 2 must be list, not numpy.ndarray so the problem was ... = fmin_tnc(func, x, ...) earlier tnc required x to be Python list, not numpy.ndarray. I added line x = asfarray(x).tolist() So now tnc works with both python list (see /optimize/tests/test_optimize.py, funcs test3fg, test4fg and others) and numpy.ndarray (func test38fg from same file) http://projects.scipy.org/scipy/scipy/ticket/390 (bfgs falls) we decided the one should be closed because bfgs solver is used on an non-convex objfun with lots of local minima. So nothing special that sometimes it yields other solution than mentioned by ticket author. the ticket should be closed http://projects.scipy.org/scipy/scipy/ticket/234 suppressing warning in leastsq and fsolve in optimize it's done in the way proposed by ticket author, the ticket should be closed http://projects.scipy.org/scipy/scipy/ticket/285 (enhancement proposition to fmin_powell) So, as it was proposed by Alan Isaac and agreed in scipy mail list, alternative changes to fmin_powell were implemented (object-oriented style, class with some funcs and fields.) //to Alan Isaac: it was Nils who published the comment, not I. // (please clearly summarize the blog comments here; // we cannot assume persistance of the blog) Afaik David intended to continue transformation of other scipy.optimize funcs to new style, but I don't know will he do it or not and is it worth to do or not. Won't Do -------- http://projects.scipy.org/scipy/scipy/ticket/399 OK (won't do) Closed ------ http://projects.scipy.org/scipy/scipy/ticket/296 OK (closed) http://projects.scipy.org/scipy/scipy/ticket/377 OK (closed) http://projects.scipy.org/scipy/scipy/ticket/416 OK (closed) http://projects.scipy.org/scipy/scipy/ticket/389 OK (closed) http://projects.scipy.org/scipy/scipy/ticket/388 OK (closed)

1 0

GSoC weekly report
by dmitrey Aug. 18, 2007

Aug. 18, 2007

Hi all, because of some reasons (including work and study in my dept) I'm a little bit out of my GSOC schedule but I hope I'll have all it done in-time, and/or I will spent some more days after GSoC finish. So, this week I updated openopt documentation, some examples were added (see ./examples/nlp_1.py, nlp_2.py, qp_1.py, milp_1.py, lp_1.py, nsp_1.py) 2 solvers from scipy were connected: l_bfgs_b as scipy_lbfgsb and tnc as scipy_tnc. I tried to connect cobyla, but I encountered some problems described in my blog http://openopt.blogspot.com/2007/08/lbfgsb-from-scipyoptimize-have-been.html I've got another one letter from ALGENCAN developers. They informed me they took into account some my propositions (using numpy.array instead of python list etc) and have already implemented them. However, I informed them of some more proposition, and still there are no answer - will they implement those ones or not. On the other hand, I think it's already pass enough requirements to be implemented as openopt solver, and I guess it will be much more effective than lincher (because sometimes it's more effective than well-known IPOPT). However, it requires several days to connect, and I'm enable to do this without GSoC schedule modification. Read more about the ALGENCAN letter at http://openopt.blogspot.com/2007/08/news-from-algencan.html openopt tickets 33 and 34 filed by Nils Wagner had been fixed (however, I didn't observed problem of 33rd) and should be closed, but I still have troubles with login/register in projects.scikits.org, and Jeff Strunk hasn't answered my letter yet. See http://openopt.blogspot.com/2007/08/openopt-tickets-33-and-34.html for more details. Also, some minor changes to lincher were made (I have no time for major enhancements). Regards, D.

1 0