Mailman 3 July 2012 - SciPy-Dev

Algorithm for butterworth filter implementation
by Bogdan Cristea July 22, 2012

July 22, 2012

Hi Could someone provide me with some hints about the algorithm used to compute the coefficients for the butterworth filter found in scipy ? I am interested in the passband version of this filter since concatenating a low pass and a high pass filter does not produce the same frequency response as the passband filter provided by scipy. thanks -- Bogdan

2 1

Segfaults building against numpy / scipy on OSX Lion
by Matthew Brett July 21, 2012

July 21, 2012

Hi, Please forgive the half-baked question, but, I'm trying to build our package nipy (nipy.org) against stock downloaded numpy-1.6.2-py2.7-python.org-macosx10.6.dmg scipy-0.10.1-py2.7-python.org-macosx10.6.dmg I'm using latest XCode 4.3.3 $ clang --version Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn) Target: x86_64-apple-darwin11.4.0 Thread model: posix on Lion: $ uname -a Darwin pis-macbook-air 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:33:05 PDT 2012; root:xnu-1699.26.8~1/RELEASE_I386 i386 I believe the correct incantation for the build is: http://scipy.org/Installing_SciPy/Mac_OS_X CC=clang CXX=clang FFLAGS=-ff2c python setup.py build_ext -i This does build, but during the tests, and only on this platform, segfaults (report attached). Is this build / link expected to work? Did I get the right flags? Thanks a lot, Matthew

3 7

ANN: PyTables 2.4.0 released
by Anthony Scopatz July 20, 2012

July 20, 2012

========================== Announcing PyTables 2.4.0 ========================== We are happy to announce PyTables 2.4.0. This is an incremental release which includes many changes to prepare for future Python 3 support. What's new ========== This release includes support for the float16 data type and read-only support for variable length string attributes. The handling of HDF5 errors has been improved. The user will no longer see HDF5 error stacks dumped to the console. All HDF5 error messages are trapped and attached to a proper Python exception. Now PyTables only supports HDF5 v1.8.4+. All the code has been updated to the new HDF5 API. Supporting only HDF5 1.8 series is beneficial for future development. Documentation has been improved. As always, a large amount of bugs have been addressed and squashed as well. In case you want to know more in detail what has changed in this version, please refer to: http://pytables.github.com/release_notes.html You can download a source package with generated PDF and HTML docs, as well as binaries for Windows, from: http://sourceforge.net/projects/pytables/files/pytables/2.4.0 For an online version of the manual, visit: http://pytables.github.com/usersguide/index.html What it is? =========== PyTables is a library for managing hierarchical datasets and designed to efficiently cope with extremely large amounts of data with support for full 64-bit file addressing. PyTables runs on top of the HDF5 library and NumPy package for achieving maximum throughput and convenient use. PyTables includes OPSI, a new indexing technology, allowing to perform data lookups in tables exceeding 10 gigarows (10**10 rows) in less than a tenth of a second. Resources ========= About PyTables: http://www.pytables.org About the HDF5 library: http://hdfgroup.org/HDF5/ About NumPy: http://numpy.scipy.org/ Acknowledgments =============== Thanks to many users who provided feature improvements, patches, bug reports, support and suggestions. See the ``THANKS`` file in the distribution package for a (incomplete) list of contributors. Most specially, a lot of kudos go to the HDF5 and NumPy (and numarray!) makers. Without them, PyTables simply would not exist. Share your experience ===================== Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. ---- **Enjoy data!** -- The PyTables Team

1 0

Enhancements to scipy.spatial.cKDTree
by Patrick Varilly July 20, 2012

July 20, 2012

Dear all, I've recently been putting together a wrapper around scipy.spatial.KDTree to transparently handle periodic boundary conditions that are common in analyzing the results of molecular simulations ( https://github.com/patvarilly/periodic_kdtree). In the process, I've started enhancing some of scipy.spatial.cKDTree by adding a Cythonized query_ball_point method. A pull request is here https://github.com/scipy/scipy/pull/262 Two things I have noticed are that the interfaces to the KDTree and cKDTree query() methods aren't quite in line, and that it wouldn't take a whole lot of extra effort to Cythonize the rest of KDTree. The innards of the code could also be reorganized a bit to make it easier for other people to extend these classes. For the periodic kd-trees, for example, I had to jump through a few hoops, and ended up with two different codebases for wrapping KDTree's and cKDTree's, which is not ideal. I was writing to gauge if there's actually any interest in cleaning up KDTrees and Cythonizing the rest of the KDTree interface. If so, I'd be willing to put a bit of effort into doing so. A delicate question that comes up is whether anyone relies on the subtle differences between KDTree.query() and cKDTree.query() (e.g., passing k = None), so that bringing the two interfaces exactly in line with each other would break existing code. How is this issue usually dealt with? All the best, Patrick

5 36

update on 0.11.0 status
by Ralf Gommers July 18, 2012

July 18, 2012

Hi all, Here's a short update on the status of the 0.11.0 release. Some of the reported issues for the beta release have been fixed or PRs for them are waiting to be merged. There is one failure not yet fixed (sparse.csgrapg.shortest_path failure) and one blocker also in the sparse.csgraph module: http://projects.scipy.org/scipy/ticket/1681. Once the csgraph issues are fixed we're ready to release the first RC. To be merged and backported: Umfpack failure: https://github.com/scipy/scipy/pull/257 Interpolate failure under Python 3.x: https://github.com/scipy/scipy/pull/258 To not fix: weave error when running the tests under Python 3.x. It's not easy to avoid the printed error, because importing the whole module fails. And in the end the result is the same, weave doesn't work at all for 3.x. Cheers, Ralf

7 19

SSE optimization
by Fode July 16, 2012

July 16, 2012

I would like to add sse optimization to numpy if that is still something the project is interested in. Do you have any suggestions as to where to start optimizing. Fode

4 3

Euroscipy 2012: early bird registration ending soon
by Emmanuelle Gouillart July 10, 2012

July 10, 2012

Hello, early bird registration for Euroscipy 2012 is soon coming to an end, with the deadline on July 22nd. Don't forget to register soon! Reduced fees are available for academics, students and speakers. Registration takes place online on http://www.euroscipy.org/conference/euroscipy2012. Euroscipy 2012 is the annual European conference for scientists using the Python language. It will be held August 23-27 2012 in Brussels, Belgium. Our program has been online for a few weeks now: we're very excited to have a great selection of tutorials, as well as talks and poster presentations. During the two days of tutorials (August 23 and 24), it will possible to attend either the introduction track, or the advanced track, or to combine both tracks (see http://www.euroscipy.org/track/6538?tab=tracktalkslist and http://www.euroscipy.org/track/6539?tab=tracktalkslist). As for the highlights of the two days of conference (August 25 and 26), we are very happy to have David Beazley (http://www.dabeaz.com) and Eric Jones (http://www.enthought.com/company/support-team.php) as our keynote speakers. The list of talks is available on http://www.euroscipy.org/track/6540?tab=tracktalkslist, with subjects ranging from extension programming to machine learning, or cellular biology. We're looking forward to exciting discussions during the talk sessions or around the posters, as happened during the previous editions of Euroscipy! Sprints may be organized at the conference venue during the days following the conference, from Monday 27th on. Since there is a limited number of rooms booked for the sprints, please contact the organizers by July 22 if you intend to organize one. Two sprints are already planned by the scikit-learn and the scikits-image teams. The EuroSciPy 2012 conference will feature a best talk, a best poster and a jury award. All conference participants will be given the opportunity to cast a vote for the best talk and best poster awards while the jury award is selected by the members of the program committee. Each prize consists of a Commercial Use license for Wing IDE Professional, an integrated development environment designed specifically for Python programmers. The licenses are generously donated by Wingware. Financial support may be granted by Numfocus to a small number of eligible students. See http://www.euroscipy.org/card/euroscipy2012_support_numfocus for more details on how to apply. For information that cannot be found on the conference website, please contact the organizing team at org-team(a)lists.euroscipy.org Cheers, Emmanuelle, for the organizing team

1 0

f2py type patch submitted
by pepijn de vos July 9, 2012

July 9, 2012

Hi, This is my first patch to NymPy. Hopefully more is to come this week. http://projects.scipy.org/numpy/ticket/2183 This patch is brought to you by the Hacker School open source week ;-) Pepijn de Vos

1 0

Re: [SciPy-Dev] SciPy-Dev Digest, Vol 105, Issue 9
by Alexander Arsenovic July 8, 2012

July 8, 2012

thanks man. by the way, the docs look really good. the `ggplot` style is great. it would be cool to get journals to participate by making formal style files. i emailed ieee once about this and never heard back. maybe you could get them to endorse mpltools as a way to make an acceptably formatted plot, which would boost your user base. just a thought. alex On Sat, Jul 7, 2012 at 1:00 PM, <scipy-dev-request(a)scipy.org> wrote: > Send SciPy-Dev mailing list submissions to > scipy-dev(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)scipy.org > > You can reach the person managing the list at > scipy-dev-owner(a)scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Re: interp2d bounds checking (Pauli Virtanen) > 2. Re: interp2d bounds checking (Nathaniel Smith) > 3. Enhancements to scipy.spatial.cKDTree (Patrick Varilly) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 06 Jul 2012 20:51:53 +0200 > From: Pauli Virtanen <pav(a)iki.fi> > Subject: Re: [SciPy-Dev] interp2d bounds checking > To: scipy-dev(a)scipy.org > Message-ID: <jt7c4a$97n$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1 > > 06.07.2012 18:19, Ralf Gommers kirjoitti: > > On Sun, Jul 1, 2012 at 8:40 PM, Pauli Virtanen wrote: > [clip] > > I've also been thinking about enlarging the griddata syntax from the > > possibly somewhat unfriendly > > > > griddata((x, y), z, (xi, yi), **kw) > > griddata((x, y, z), u, (xi, yi, zi), **kw) > > > > to the variable argument one > > > > griddata(x, y, z, xi, yi, **kw) > > griddata(x, y, z, u, xi, yi, zi, **kw) > > > > which may be more familiar to users. Thoughts? > > > > That does look easier to use, but having two interfaces will be > > confusing. And deprecating the old one will be painful. What exactly do > > you have in mind to do here? > > I was thinking about making the latter syntax an alias for the former, > keeping both around. But perhaps it's confusing. > > Another issue is that variable arguments don't play too well with > function signatures. This is BTW one thing that is better in Python 3, > which has keyword-only arguments. > > Pauli > > > > ------------------------------ > > Message: 2 > Date: Fri, 6 Jul 2012 20:28:21 +0100 > From: Nathaniel Smith <njs(a)pobox.com> > Subject: Re: [SciPy-Dev] interp2d bounds checking > To: SciPy Developers List <scipy-dev(a)scipy.org> > Message-ID: > <CAPJVwB= > y2MiMdqTX+bOAfBtgDi9SMFkpejtxatPYVb8gXnY3sA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Jul 6, 2012 at 7:51 PM, Pauli Virtanen <pav(a)iki.fi> wrote: > > 06.07.2012 18:19, Ralf Gommers kirjoitti: > >> On Sun, Jul 1, 2012 at 8:40 PM, Pauli Virtanen wrote: > > [clip] > >> I've also been thinking about enlarging the griddata syntax from the > >> possibly somewhat unfriendly > >> > >> griddata((x, y), z, (xi, yi), **kw) > >> griddata((x, y, z), u, (xi, yi, zi), **kw) > >> > >> to the variable argument one > >> > >> griddata(x, y, z, xi, yi, **kw) > >> griddata(x, y, z, u, xi, yi, zi, **kw) > >> > >> which may be more familiar to users. Thoughts? > >> > >> That does look easier to use, but having two interfaces will be > >> confusing. And deprecating the old one will be painful. What exactly do > >> you have in mind to do here? > > > > I was thinking about making the latter syntax an alias for the former, > > keeping both around. But perhaps it's confusing. > > If I had the option I'd use the former ("old") syntax, but then, I'm weird. > > -N > > > ------------------------------ > > Message: 3 > Date: Sat, 7 Jul 2012 00:36:50 +0100 > From: Patrick Varilly <patvarilly(a)gmail.com> > Subject: [SciPy-Dev] Enhancements to scipy.spatial.cKDTree > To: scipy-dev(a)scipy.org > Message-ID: > < > CAHEe8R-y38kBx0an6RmWeVtTegRd2UKPROtyZcCzXLSCSMiviw(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Dear all, > > I've recently been putting together a wrapper around scipy.spatial.KDTree > to transparently handle periodic boundary conditions that are common in > analyzing the results of molecular simulations ( > https://github.com/patvarilly/periodic_kdtree). In the process, I've > started enhancing some of scipy.spatial.cKDTree by adding a Cythonized > query_ball_point method. A pull request is here > > https://github.com/scipy/scipy/pull/262 > > Two things I have noticed are that the interfaces to the KDTree and cKDTree > query() methods aren't quite in line, and that it wouldn't take a whole lot > of extra effort to Cythonize the rest of KDTree. The innards of the code > could also be reorganized a bit to make it easier for other people to > extend these classes. For the periodic kd-trees, for example, I had to > jump through a few hoops, and ended up with two different codebases for > wrapping KDTree's and cKDTree's, which is not ideal. > > I was writing to gauge if there's actually any interest in cleaning up > KDTrees and Cythonizing the rest of the KDTree interface. If so, I'd be > willing to put a bit of effort into doing so. A delicate question that > comes up is whether anyone relies on the subtle differences between > KDTree.query() and cKDTree.query() (e.g., passing k = None), so that > bringing the two interfaces exactly in line with each other would break > existing code. How is this issue usually dealt with? > > All the best, > > Patrick >

1 0

interp2d bounds checking
by Pierre Haessig July 6, 2012

July 6, 2012

Hi, I just have a small question about scipy.interpolate.interp2d I noticed that bounds checking when calling the interpolation instance seems to be ineffective. I found a ticket about this issue, but not much activity around it. http://projects.scipy.org/scipy/ticket/1072 I looked at the code and at the documentation ( http://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.inter… https://raw.github.com/scipy/scipy/master/scipy/interpolate/interpolate.py ) and it seems that the `bounds_error` argument is never used in the initialization of the interp2d object (unlike inter1d). I'm not at all a specialist of 2D interpolation but I guess that bounds checking in 2D is not as easy as in 1D... Maybe, if there is no easy way to check bounds in interp2d, we should just add a "big warning" in the docstring stating that `bounds_error` is not currently used (and therefore `fill_value` as well). What do you think ? Best, Pierre about docstring editing, I didn't find the "Edit page" link on interp2d page. Did I miss something ?

4 5