Mailman 3 January 2008 - SciPy-Dev

Trouble with different python installations
by Nils Wagner Jan. 11, 2008

Jan. 11, 2008

Hi all, I have two different python versions on my linux box- python2.3 (global installation) and python2.5 (local installation without root privileges). I have removed the build directory and tried to install numpy for python2.5 ~/local/bin/python setup.py install --prefix=$HOME/local If I try to import numpy I get ~/local/bin/python Python 2.5.1 (r251:54863, Dec 21 2007, 09:21:07) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/data/home/nwagner/local/lib64/python2.3/site-packages/numpy/__init__.py", line 44, in <module> import core File "/data/home/nwagner/local/lib64/python2.3/site-packages/numpy/core/__init__.py", line 5, in <module> import multiarray ImportError: /data/home/nwagner/local/lib64/python2.3/site-packages/numpy/core/multiarray.so: undefined symbol: Py_InitModule4 >>> How can I resolve the conflict between 2.3 and 2.5 ? Nils

2 3

Nose testing branch - call for - er - testing
by Matthew Brett Jan. 11, 2008

Jan. 11, 2008

Hi, I've been working for a bit on replacing numpy testing with the nose testing framework: http://somethingaboutorange.com/mrl/projects/nose/ Fernando and the guys started this at the recent Berkeley sprint, and I've since been slogging through. I've now done most of the work, and I was hoping some of you would check out the branch and see what you find: http://projects.scipy.org/scipy/scipy/browser/branches/testing_cleanup/ As before, you can run module level tests with (e.g) scipy.io.test() Now the arguments are a bit different, and select the tests using the nose framework, such as: scipy.io.test('bench') select the tests labelled with the benchmark decorators, this: scipy.io.test('fast') corresponds to the default, and this scipy.io.test('full', verbose=10) to the usual test(10, 10) idiom. You'll see hints on the nose stuff in the scipy.testing module, and the scipy.sandbox.exmplpackage module. Any thoughts from the bravest out there? Matthew

7 9

Pending tickets and roadmap 0.7
by Nils Wagner Jan. 8, 2008

Jan. 8, 2008

Hi all, The tickets 572, 575 and 576 can be closed. http://projects.scipy.org/scipy/scipy/query?status=new&status=assigned&stat… Cheers, Nils

2 2

Sage/Scipy Days 8 at Enthought: Feb 29/March 4 2008
by Fernando Perez Jan. 7, 2008

Jan. 7, 2008

Hi all, below is the full text of the announcement, which has also been posted here: http://wiki.sagemath.org/days8 Many thanks to Enthought for the generous support they've offered! We really look forward to this meeting being a great opportunity for collaboration between the Scipy and Sage teams. Cheers, Travis Oliphant William Stein Fernando Perez ================================ Sage/Scipy Days 8 at Enthought ================================ ------------------------------------------------------- Connecting Pure Mathematics With Scientific Computation ------------------------------------------------------- .. Contents:: .. 1 Introduction 2 Location 3 Costs and Funding 4 Contacts and further information 5 Preliminary agenda 5.1 Friday 29: Talks 5.2 Saturday 1: More talks/code planning/code 5.3 Sunday 2: Coding 5.4 Monday 3: Coding 5.5 Tuesday 4: Wrapup .. Introduction ============ The Sage_ and Scipy_ teams and `Enthought Inc.`_ are pleased to announce the first collaborative meeting for Sage/Scipy joint development, to be held from February 29 until March 4, 2007 at the Enthought headquarters in Austin, Texas. The purpose of this meeting is to gather developers for these projects in a friendly atmosphere for a few days of technical talks and active development work. It should be clear to those interested in attending that this is *not* an academic conference, but instead an opportunity for the two teams to find common points for collaboration, joint work, better integration between the projects and future directions. The focus of the workshop will be to actually *implement* such ideas, not just to plan for them. **Sage** is a Python-based system which aims at providing an open source, free alternative to existing propietary mathematical software and does so by integrating multiple open source projects, as well as providing its own native functionality in many areas. It includes by default the NumPy and SciPy packages. **NumPy and SciPy** are Python libraries whose focus is high-performance numerical computing, and they are widely accepted as the foundation of most Python-based scientific computing projects. **Enthought** is a scientific computing company that produces Python-based tools for many application-specific domains. Enthought has a strong commitment to open source development: it provides support and hosting for Numpy, Scipy, and many other Python scientific projects and many of its tools_ are freely available. The theme of the workshop is finding ways to best combine our strengths to create something that is significantly better than anything ever done so far. .. _Sage: http://sagemath.org .. _Scipy: http://scipy.org .. _`Enthought Inc.`: http://enthought.com .. _tools: http://code.enthought.com Location ======== The workshop will be held at the headquarters of `Enthought Inc.`_:: Suite 2100 515 Congress Ave. Austin, TX 78701 (512) 536-1057, voice (512) 536-1059, fax .. _`Enthought Inc.`: http://enthought.com Costs and Funding ================= We can accomodate a total of 30 attendees at Enthought's headquarters for the meeting. There is a $100 registration fee, which will be used to cover coffee, snacks and lunches for all the days of the meeting, plus one group dinner outing. Attendees can use the wiki_ to coordinate room/car rental sharing if they so desire. Thanks to Enthought's generous offer of support, we'll be able to cover the above costs for 15 attendees, in addition to offering them housing and transportation. Please note that housing will be provided at Enthought's personal residences, so remember to bring your clean pajamas. We are currently looking into the possibility of additional funding to cover the registration fee for all attendees, and will update the wiki accordingly if that becomes possible. If you plan on coming please email Fernando.Perez(a)colorado.edu to let us know of your intent so we can have a better idea of the total numbers. Please indicate if you could only come under the condition that you can be hosted. We will try to offer hosting to as many of the Sage and Scipy developers as possible, but if you can fund your own expenses, this may open a slot for someone with limited funds. If the total attendance is below 15, we will offer hosting to everyone. We will close registration for those requesting hosting by Sunday, February 3, 2008. If we actually fill up all 30 available slots we will announce it, otherwise you are free to attend by letting us know anytime before the meeting, though past Feb. 1 you will be required to pay the registration fee of $100. .. _wiki: http://wiki.sagemath.org/days8 Contacts and further information ================================ For further information, you can either contact one of the following people (in parenthesis we note the topic most likely to be relevant to them): - William Stein (Sage): wstein(a)gmail.org - Fernando Perez (Scipy): Fernando.Perez(a)colorado.edu - Travis Oliphant (Enthought): oliphant(a)enthought.com or you can go to our wiki_ for up to date details. Preliminary agenda ================== Friday 29: Talks ---------------- This is a rough cut of suggested topics, along with a few notes on possible details that might be of interest. The actual material in the talks will be up to the presenters, of course. Some of these topics might just become projects to work on rather than actual talks, if we don't have a speaker available but have interested parties who wish to focus on the problem. Speakers are asked to include a slide of where they see any chances for better collaboration between the various projects (to the best of their knowledge). There will be a note-taker during the day who will try to keep tabs on this information and will summarize it as starting material for the joint work panel discussion to be held on Saturday (FPerez volunteers for this task if needed). - Numpy internal architecture and type system. - Sage internal type system, with emphasis on its number type system. - A clarification of where the 'sage language' goes beyond python. Things like ``A\b`` are valid in the CLI but not the notebook. Scipy is pure python, so it would help the scipy team better understand the boundaries between the two. - Special methods used by Sage (foo._magical_sage_method_)? If some of these make sense, we might want to agree on common protocols for numpy/scipy/sage objects to honor. - Sage usage of numpy, sage.matrix vs numpy.arrays. Smoother integration of numpy arrays/sage matrices and vectors. - Extended precision LAPACK. Integration in numpy/sage. The extended precision work LAPACK work was done by Y. Hida and J. Demmel at UC Berkeley. - Distributed/Parallel computing: DSage, ipython, Brian Granger's work on Global arrays for NASA... - Scikits: these are 'toolkits' that use numpy/scipy and can contain GPL code (details of how these will work are being firmed up in the scipy lists, and will be settled by the workshop). Perhaps some of SAGE's library wrappers (like GMP, MPFR or GSL) could become scikits? - Cython: status (inclusion in py2.6?), overview, opportunities for better numpy integration and usage. - Enthought technologies: Traits, TVTK, Mayavi, Chaco, Envisage. - User interface collaboration: 'sage-lite'/pylab/ipython code sharing possibilities? Saturday 1: More talks/code planning/coding ------------------------------------------- 9-11 am: Any remaining talks that didn't fit on Friday. Only if needed. 11-12: panel for specific coding projects and ideas, spill over into lunch time. 12-1: lunch. Rest of day: start coding! Organize in teams according to the plans made earlier and code away... Sunday 2: Coding ---------------- Work on projects decided above. 5-6pm: brief (5-10 minutes) status updates from coding teams. Problems encountered, progress, suggestions for adjustment. Monday 3: Coding ---------------- Same as Sunday. Tuesday 4: Wrapup ----------------- 9-11 am: Wrapup sessions with summary from coding projects. 11-12 am: Panel discussion on future joint work options. Afternoon: anyone left around can continue to code!

1 0

planet.scipy.org
by J. Ryan Earl Jan. 4, 2008

Jan. 4, 2008

There was a problem with how the DNS was setup for this site, it has been corrected. There are no known outstanding DNS issues. Please tell me ASAP if you notice any problems. Thanks, J. Ryan Earl IT Administrator Enthought, Inc.

2 1

Trouble with fmin_cg
by Nils Wagner Jan. 4, 2008

Jan. 4, 2008

Hi all, If I run the following script from scipy import * def func(x): return 0.5*dot(x,dot(A,x))-dot(x,b) def monitor(x): res = linalg.norm(dot(A,x)-b) return res n = 10 x0 = zeros(n,float) A = random.rand(n,n)+diag(4*ones(n)) A = 0.5*(A+A.T) b = random.rand(n) x = optimize.fmin_cg(func,x0,callback=monitor(x0)) I get Traceback (most recent call last): File "test_fmin_cg.py", line 16, in <module> x = optimize.fmin_cg(func,x0,callback=monitor(x0)) File "/usr/local/lib64/python2.5/site-packages/scipy/optimize/optimize.py", line 911, in fmin_cg callback(xk) TypeError: 'numpy.float64' object is not callable Is that a bug ? Nils

2 2

matlab5 sparse IO
by Nathan Bell Jan. 4, 2008

Jan. 4, 2008

First let me thank those who have contributed to MATLAB IO in scipy. I noticed that the Matlab4 sparse writer was a little slow, so I sped it up using the coo_matrix format. Anyway, I was going to do the same for the Matlab5 writer, but it seems to be broken. It appears that the V5 code was a copy/paste of the V4 method, which it shouldn't be. http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/io/matlab/mio5.py… Looking at the V5 sparse reader: http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/io/matlab/mio5.py… suggests that the CSC format should be used when writing, but the present code - even if it worked properly - appears to be writing out a triplet format (as is done in V4). I don't fully understand all the magic in the matlab IO code, but I'd be happy to help whomever maintains it in adding sparse V5 support. Here's a simple test that currently fails: from scipy import * from scipy.sparse import * from scipy.io import * from numpy.testing import * A = csr_matrix([[1.0,0.0,2.0],[0,-3.5,0]]) savemat('test4.mat', { 'A': A }, format='4') A4 = loadmat('test4.mat')['A'] assert_equal(A.todense(),A4.todense()) savemat('test5.mat', { 'A': A }, format='5') A5 = loadmat('test5.mat')['A'] assert_equal(A.todense(),A5.todense()) Note that the failure in savemat(... format='5') is currently just a typo (N is used as a variable and for numpy), but I think there are more fundamental issues as well. -- Nathan Bell wnbell(a)gmail.com

3 7

stat.models.robust.scale test failure
by Matthew Brett Jan. 3, 2008

Jan. 3, 2008

Hi, I guess this one's mainly for Jonathan... I'm just moving the scipy testing framework over to nose testing, and came across a couple of test failures in scipy.stats.models in tests that the numpy testing did not appear to pick up. Output appended. Is the fix obvious? I will have a go later today if nothing comes immediately to mind... Thanks a lot, Matthew ====================================================================== ERROR: test_huber (test_scale.TestScale) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mb312/dev_trees/testing_cleanup/scipy/stats/models/tests/test_scale.py", line 35, in test_huber m = scale.huber(X) File "/home/mb312/dev_trees/testing_cleanup/scipy/stats/models/robust/scale.py", line 82, in __call__ for donothing in self: File "/home/mb312/dev_trees/testing_cleanup/scipy/stats/models/robust/scale.py", line 102, in next scale = N.sum(subset * (a - mu)**2, axis=self.axis) / (self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) * Huber.c**2) File "/home/mb312/lib64/python2.5/site-packages/numpy/core/fromnumeric.py", line 866, in sum return sum(axis, dtype, out) TypeError: only length-1 arrays can be converted to Python scalars ====================================================================== ERROR: test_huberaxes (test_scale.TestScale) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mb312/dev_trees/testing_cleanup/scipy/stats/models/tests/test_scale.py", line 40, in test_huberaxes m = scale.huber(X, axis=0) File "/home/mb312/dev_trees/testing_cleanup/scipy/stats/models/robust/scale.py", line 82, in __call__ for donothing in self: File "/home/mb312/dev_trees/testing_cleanup/scipy/stats/models/robust/scale.py", line 102, in next scale = N.sum(subset * (a - mu)**2, axis=self.axis) / (self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) * Huber.c**2) File "/home/mb312/lib64/python2.5/site-packages/numpy/core/fromnumeric.py", line 866, in sum return sum(axis, dtype, out) TypeError: only length-1 arrays can be converted to Python scalars ---------------------------------------------------------------------- Ran 42 tests in 2.012s

2 1