Mailman 3 September 2015 - SciPy-Dev

vectorized scipy.integrate.quad
by Christoph Groth 08 Oct '15

08 Oct '15

Dear SciPy experts, We would like to speed-up some numerical integrations that we do by parallelizing them with MPI (our integrands take a very long time to evaluate). Looking at the implementation of QAGSE (that is performing the work for scipy.integrate.quad) I see that there is potential for 21-fold vectorization in the first pass and subsequently for 42-fold vectorization of the evaluation of the integrand. That’s quite good! Once a vectorized scipy.integrand.quad is available, any parallelization technique can be used in the integrand can use. But even without parallelization a vectorized integrand could already provide significant speedups. On the Python level, I think that the interface to the new function could remain the same as that of the existing quad routine, with the only difference that the first argument of the integrand will be not a number, but a 1d-array of numbers. Would such a vectorized quad be a welcome addition to SciPy? I imagine proceeding as follows: (1) Download the relevant parts of QUADPACK and convert them to C using f2c. (2) Vectorize the C code. (3) Add Python bindings. (4) Write a test that verifies that the vectorized routine evaluates the same points and gives the same results as the sequential one. Cheers Christoph

5 11

Fwd: ANN: SfePy 2015.3
by Robert Cimrman 30 Sep '15

30 Sep '15

FYI: resending due to mailing list problems last week, apologies if you already got this. -------- Forwarded Message -------- I am pleased to announce release 2015.3 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - preliminary support for parallel computing - unified evaluation of basis functions (= isogeometric analysis fields can be evaluated in arbitrary points) - (mostly) fixed finding of reference element coordinates of physical points - several new or improved examples For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman on behalf of the SfePy development team --- Contributors to this release in alphabetical order: Robert Cimrman Vladimir Lukes

1 0

Numpy 1.10.0rc2 released
by Charles R Harris 29 Sep '15

29 Sep '15

Hi all, I'm pleased to announce the availability of Numpy 1.10.0rc12. Sources and 32 bit binary packages for Windows may be found at Sourceforge <https://sourceforge.net/projects/numpy/files/NumPy/1.10.0rc2/?upload_just_c…>. There have been a few fixes since rc1. If there are no more problems I hope to release the final in a week or so. Cheers Chuck

1 0

New version of "scipy lecture notes"
by Gael Varoquaux 29 Sep '15

29 Sep '15

Dear Pythonistas, We have just released a new version of the "scipy lecture notes": http://www.scipy-lectures.org/ These are a consistent set of materials to learn the core aspects of the scientific Python ecosystem, from beginner to expert. They are written and maintained by a set of volunteers and published under a CC-BY license. Highlights of the latest version includes: * a chapter giving a introduction to statistics in Python * a new layout with emphasis on readability including on small devices * fully doctesting for Python 2 and 3 compatibility We hope that you will find these notes useful, for you, your colleagues, or your students. Gaël

1 0

The new scipy central site is live
by Surya 29 Sep '15

29 Sep '15

Hello everyone, I'm excited to announce the new SciPy Central website is live at central.scipy.org. The URLs from the old domain scipy-central.org hosted by Kevin will be redirected to the latest. Major improvements on front-end ------------------------------- 1. New UI using Twitter Bootstrap 2.3 2. Comments system for submissions 3. Preview during submission is simplified 4. RSS/Atom feeds for submissions, comments 5. ACE Editor to show code snippets, and highlight syntax Possible future improvements ---------------------------- 1. OpenID integration to login. I'm thinking of Google Identity Toolkit <https://developers.google.com/identity/toolkit/web/> now 2. Up/down voting submissions. Its great if someone wants to improve this <https://github.com/ksurya/SciPyCentral/tree/thumbs> 3. Cookbooks integration + iPyNb support. Any ideas on how to integrate iPython Notebooks would be great. Possibly, we may want to rethink different submission types. Thanks to Clever Cloud for kindly providing hosting services to our open source project at no cost. Help + Contributions by [1] thanks, Surya [1] In alphabetic order: Allen (Enthought), Julien (Clever Cloud), Kevin, Pauli, Ralf, Sebastian

2 2

Numpy 1.10.0rc2 coming Monday, Sep 28.
by Charles R Harris 28 Sep '15

28 Sep '15

Hi All, Just a heads up. If you have encountered any unreported errors with rc1, please let us know. Chuck

1 0

Mailing list working?
by Surya 26 Sep '15

26 Sep '15

Hi, I've sent emails last week but, weren't delivered. Is there any problem? Thanks Surya

4 3

The process I intend to follow for any proposed changes to NumPy
by Travis Oliphant 14 Sep '15

14 Sep '15

Hey all, I just wanted to clarify, that I am very excited about a few ideas I have --- but I don't have time myself to engage in the community process to get these changes into NumPy. However, those are real processes --- I've been coaching a few people in those processes for the past several years already. So, rather than do nothing, what I'm looking to do is to work with a few people who I can share my ideas with, get excited about the ideas, and then who will work with the community to get them implemented. That's what I was announcing and talking about yesterday --- looking for interested people who want to work on NumPy *with* the NumPy community. In my enthusiasm, I realize that some may have mis-understood my intention. There is no 'imminent' fork, nor am I planning on doing some crazy amount of work that I then try to force on other developers of NumPy. What I'm planning to do is find people to train on NumPy code base (people to increase the diversity of the developers would be ideal -- but hard to accomplish). I plan to train them on NumPy based on my experience, and on what I think should be done --- and then have *them* work through the community process and engage with others to get consensus (hopefully not losing too much in translation in the process --- but instead getting even better). During that process I will engage as a member of the community and help write NEPs and other documents and help clarify where it makes sense as I can. I will be filtering for people that actually want to see NumPy get better. Until I identify the people and work with them, it will be hard to tell how this will best work. So, stay tuned. If all goes well, what you should see in a few weeks time are specific proposals, a branch or two, and the beginnings of some pull requests. If you don't see that, then I will not have found the right people to help me, and we will all continue to go back to searching. While I'm expecting the best, in the worst case, we get additional people who know the NumPy code base and can help squash bugs as well as implement changes that are desired. Three things are needed if you want to participate in this: 1) A willingness to work with the open source community, 2) a deep knowledge of C and in-particular CPython's brand of C, and 3) a willingness to engage with me, do a mind-meld and dump around the NumPy code base, and then improve on what is in my head with the rest of the community. Thanks, -Travis

1 0

Fwd: Pre-release of reentrant Qhull on github
by Cantwell Carson 14 Sep '15

14 Sep '15

Can we update the Qhull on Scipy with 2015? The vertex_id and ridge_id fields have increased from 24 bits to 32 bits, which solves an issue with data sets larger than 2^24 points. There are other issues that appear to be addressed, but this is the one that I was excited about. Cantwell ---------- Forwarded message ---------- From: Brad Barber <bradb(a)shore.net> Date: Mon, Aug 31, 2015 at 11:32 PM Subject: Pre-release of reentrant Qhull on github To: Alejandro.LindeCerezo(a)dlr.de, axhiao(a)gmail.com, bakgenc(a)tamu.edu, carsonc(a)gmail.com, Chaim.Dryzun(a)sarine.com, colonel(a)monmouth.com, david.c.sterratt(a)ed.ac.uk, drum(a)gwu.edu, eric.perim(a)duke.edu, keith.briggs(a)bt.com, L1101801(a)qub.ac.uk, matteo.ragaglia(a)polimi.it, michael.guyonnet(a)gmail.com, noe.alvarado(a)upc.edu, pshafer(a)lbl.gov, robert.rambo(a)diamond.ac.uk, schwehr(a)gmail.com, shrikant.mehre(a)gmail.com, tomilovanatoliy(a)gmail.com, zachrg(a)gmail.com [Sent to recent contacts regarding Qhull] Hi all, The pre-release of reentrant Qhull 2015.0.2 is available on github. git clone git@github.com:qhull/qhull.git It features a new reentrant library qhull_r which replaces the current qhull library. The old libraries (w/ and w/o qh_QHpointer) remain available. qhull_r does not use global variables. Instead, a qhT pointer is the first argument to each procedure. This approach was pioneered by Pete Klosterman in 2010. The C++ interface is redone using qhull_r. It should be easier to use. Comments, errors, suggestions are welcome. --Brad P.S.: [Kurt] It does not include your edits. They're next.

1 0

Looking for a developer who will work with me for at least 6 months to fix NumPy's dtype system.
by Travis Oliphant 13 Sep '15

13 Sep '15

Hi all, Apologies for cross-posting, but I need to get the word out and twitter doesn't provide enough explanation. I've been working on a second edition of my "Guide to NumPy" book. It's been a time-pressured activity, but it's helped me put more meat around my ideas for how to fix NumPy's dtype system -- which I've been contemplating off an on for 8 years. I'm pretty sure I know exactly how to do it --- in a way that fits more cleanly into Python. It will take 3-6 months and will have residual efforts needed that will last another 6 months --- making more types available with NumPy, improving calculations etc. This work will be done completely in public view and allow for public comment. It will not solve *all* of NumPy's problems, but it will put NumPy's dtype system on the footing it in retrospect should have been put on in the first place (if I had known then what I know now). It won't be a grandiose rewrite. It will be a pretty surgical fix to a few key places in the code. However, it will break the ABI and require recompilation of NumPy extensions (and so would need to be called NumPy 2.0). This is unavoidable, but I don't see any problem with breaking the ABI today given how easy it is to get distributions of Python these days from a variety of sources (including using conda --- but not only using conda). For those that remember what happened in Python dev land, the changes will be similar to when Guido changed Python 1.5.2 to Python 2.0. I can mentor and work closely with someone who will work on this and we will invite full participation and feedback from whomever in the community also wants to participate --- but I can't do it myself full time (and it needs someone full time+). Fortunately, I can pay someone to do it if they are willing to commit at least 6 months (it is not required to work at Continuum for this, but you can have a job at Continuum if you want one). I'm only looking for people who have enough experience with C or preferably the Python C-API. You also have to *want* to work on this. You need to be willing to work with me on the project directly and work to have a mind-meld with my ideas which will undoubtedly give rise to additional perspectives and ideas for later work for you. When I wrote NumPy 1.0, I put in 80+ hour weeks for about 6 months or more and then 60+ weeks for another year. I was pretty obsessed with it. This won't need quite that effort, but it will need something like it. Being able to move to Austin is a plus but not required. I can sponsor a visa for the right candidate as well (though it's not guaranteed you will get one with the immigration policies what they are). This is a labor of love for so many of us and my desire to help the dtype situation in NumPy comes from the same space that my desire to work on NumPy in the first place came. I will be interviewing people to work on this as not everyone who may want to will really be qualified to do it --- especially with so many people writing Cython these days instead of good-ole C-API code :-) Feel free to spread the news to anyone you can. I won't say more until I've found someone to work with me on this --- because I won't have the time to follow-up with any questions or comments. Even if I can't find someone I will publish the ideas --- but that also takes time and effort that is in short supply for me right now. If there is someone willing to fund this work, please let me know as well -- that could free up more of my time. Best, -Travis -- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io

1 0