At this conference, novel applications and breakthroughs made in the pursuit of science using Python are presented. Attended by leading figures from both academia and industry, it is an excellent opportunity to experience the cutting edge of scientific software development.

The conference is followed by two days of tutorials and a code sprint, during which community experts provide training on several scientific Python packages.

Talk/Paper Submission

We solicit talks and accompanying papers (either formal academic or magazine-style articles) that discuss topics regarding scientific computing using Python, including applications, teaching, development and research. We welcome contributions from academia as well as industry.

Saturday, October 9, 2010

[NOTE: I wrote this in January 2009, but didn't publish it. Originally, I planned to provide a short discussion about each of the potential solutions listed below, which I never got around to doing. Anyway I just noticed my draft and decided to go ahead and publish it without adding any more discussion. The code snippets seem fairly self explanatory. If anyone has any comments on the various solutions, I would be very interested in hearing them.]

Until early 2009, I had to add the following site.cfg file to build numpy or scipy on my 64-bit Fedora Linux box:

[DEFAULT]
library_dirs = /usr/lib64

To make numpy aware of the default location required me to add /usr/lib64 to default_lib_dirs (which I will refer to as lib_dirs for brevity) in numpy/distutils/system_info.py.

Where do 64-bit libraries belong?

The lib64 directory is the default location for 64-bit libraries on Red Hat-based system. Unfortunately, not all Linux distributions conform to this convention; but, fortunately, most distributions that don't use lib64 as the default location for 64-bit libraries at least create a lib64 symlink pointing to whatever their default location happens to be. So it appears I can assume that if I am on a 64-bit machine, looking in lib64 before lib should work in most cases.

Since I only wanted to add the lib64 path on 64-bit machines, I changed the assignment to:

lib_dirs = libpaths(['/usr/lib'], platform_bits)

where libpaths returns ['/usr/lib'] when platform_bits is 32 and ['/usr/lib64', '/usr/lib'] when it is 64. I used the platform module to set platform_bits:

So we finally arrive at the motivation for this post. At this point, I started thinking that if I had two equal-sized lists that there should be a simple function for interleaving the elements of the two lists to make a new list. Something like zip. But zip returns a list of tuples. After discussing this with several people (Fernando Pérez, Brian Hawthorne, and Stéfan van der Walt), we came up with several different solutions.

While we were looking for a solution, Fernando and I came up with the following recipe:

from itertools import cycle,imap
def fromeach(*iters):
"""Take elements one at a time from each iterable, cycling them all.
It returns a single iterable that stops whenever any of its arguments is exhausted.
Note: it differs from roundrobin in the itertools recipes, in that roundrobin continues until all of its arguments are exhausted (for this reason roundrobin also needs more complex logic and thus has more overhead).
Examples:
>>> list(fromeach([1,2],[3,4]))
[1, 3, 2, 4]
>>> list(fromeach('ABC', 'D', 'EF'))
['A', 'D', 'E', 'B']
"""
return (x.next() for x in cycle(imap(iter,iters)))

Friday, September 24, 2010

At this conference, novel applications and breakthroughs made in the pursuit of science using Python are presented. Attended by leading figures from both academia and industry, it is an excellent
opportunity to experience the cutting edge of scientific software development.

The conference is followed by two days of tutorials and a code sprint, during which community experts provide training on several scientific Python packages.

We solicit talks and accompanying papers (either formal academic or magazine-style articles) that discuss topics regarding scientific computing using Python, including applications, teaching, development and research. Papers are included in the peer-reviewed conference proceedings, published online.

Please note that submissions primarily aimed at the promotion of a commercial product or service will not be considered.

Tuesday, December 15, 2009

Today is the fourth day of the 2009 SciPy India conference. Although the first SciPy conference in the US was held in 2002, 2008 was the first time the conference was held in Europe and this year is the first time the conference was held in India. It is a sign of the growing interest in using Python for scientific computing that there are now three annual conferences.

Starting at the end of May 2009, Prabhu very quickly gathered together an amazing team that immediately created a significant amount of documentation and training materials including tutorials, audio/video demonstrations, written material, and lectures. They've created a great two-day hands-on introductory tutorial to scientific programming with Python and have all ready conducted several of these tutorials all across India. Now they are working on creating a couple of semester long college courses and will be offering the first one next semester at IIT Bombay.

At the end of the SciPy 2009 conference in August, Prabhu proposed that we put together a SciPy conference in India and I immediately agreed. Not wanting to delay, we decided to have the conference before the end of the year. After all putting together an international scientific conference in less than four months was keeping with the overall ambition of the FOSSEE project. As soon as Prabhu returned to Mumbai, he contacted Vimal Josef at SPACE Kerala about hosting the conference in Thiruvananthapuram. Shortly after that we announced the first international on Scientific Computing with Python (Scipy.in 09) from December 12th to the 17th at Technopark, Thiruvananthapuram sponsored by FOSSEE, IIT Bombay and SPACE Kerala.

Once we finalized the dates for the conference, I called Travis Oliphant, the president of Enthought, and asked him to deliver the keynote address, which he quickly agreed to do. Among his many accomplishments, Travis is one of the original authors of SciPy and the primary developer of NumPy. David Cournapeau (one of the core NumPy and SciPy developers) and Chris Burns (one of the core developers of the neuroimaging in Python project) also agreed to deliver invited talks.

The FOSSEE and SPACE teams were invaluable in organizing the conference. In particular, Madhusudan.C.S from the FOSSEE team worked very closely with me on the conference website and putting together the conference program. I will write another blog post in the next day or so with a description of the actual conference. For now, you can read a short write-up from one of the local newspapers.

Sunday, November 29, 2009

I spent most of today working on the SciPy 2009 proceedings with Gael and catching up on sleep and email. For dinner, Gael, Emmanuelle, and I meet Jean-Baptiste Poline at the Denfert-Rochereau station and found a very traditional french wine bar called Au Vin des Rues, which is on rue Boulard just off of rue Daguerre and was open on a Sunday evening. (I had a delicious slow-roasted leg of lamb with potatoes au gratin and rum baba for dessert.) The rue Daguerre has a wonderful pedestrian street market I often seem to visit when I am in Paris. Here is a picture of looking down the rue Daguerre (the street market is closed, of course) toward rue Boulard (you can see JB just right of center with Gael peeking over Emmanuelle's shoulder):

PJ Toussaint, who just flew back from a conference in Greece, joined us just in time for dessert.

Just thought I'd try to keep a little journal of my trip. We'll see how long this lasts. Anyway, I landed at Charles de Gaulle at about 6:30am on Saturday morning and took the RER to Bourg-la-Reine to stay with Gael and Emmanuelle. Here is the entrance to where I am staying:

And the view from my window:

Once I arrived I took a short nap and then went out with Gael to hunt and gather in the market above the passage he lives on. Here are a two pictures I took at the local market (they had all kinds of things, but cheese and meat are, of course, the things that attracted me most):

After lunch, Gael and I headed to Paris. Over the last five years, I've tried to visit the catacombs numerous times. Unfortunately, every time I've visited, they've been closed. This time turned out to be no different. The picture on the left is Gael standing in front of the entrance to the catacombs (you can see a sign on the door, which states that they will be closed for the next month) and the picture on the right is of the road behind me:

Since I couldn't visit the catacombs, we decided to head to the Montmarte district to walk around for the afternoon. Here are a couple of pictures of the Sacre Coeur at the summit of Montmarte:

I forgot to take pictures for the rest of the day, but after Montmarte we headed back to the Latin Quarter to spend a couple hours talking about the SciPy proceedings (which we hope to finish today) in a cafe with wireless internet. And we grabbed an early dinner at 8pm with Emmanuelle and a couple of colleagues from Neurospin.

Wednesday, November 18, 2009

Nearly eight months after NumPy 1.3, NumPy 1.4 will be released well before the holidays. This release comes with the usual raft of bug fixes, performance improvements, new features, and improved documentation.

In addition to all the work David's done for the 1.4 release, some of his recent work won't be included until the 1.5 release. Once David branches for 1.4, he has all ready promised to merge his Python 3 support for numpy.distutils into the trunk. While we are just beginning to plan migrating to Python 3, this is an important early step.

Unfortunately I am not sure the new datetime dtype support for dealing with dates in arrays will be included in the 1.4 release. This useful functionality was developed over the summer by Travis Oliphant and Marty Fuhry. Marty was my Google Summer of Code student; although, I was pretty busy so Pierre Gerard-Marchant did most of the day-to-day mentoring. Despite the fact that this code was merged with the trunk at the end of the summer, there is a reasonable chance that it will be pulled before the 1.4 release due to the lack of documentation for the public C API.

I've only touched on a few of the many improvements you can expect to see with NumPy 1.4. For more details about the upcoming release, please see the release notes. Thanks to everyone who worked on this release and to David in particular.