Category Archives: General

Implied Volatility with Python’s Pandas Library AND Python in Excel

Authors: Brett Murphy and Aaron Waters

The March 6 New York Quantitative Python User’s Group (NY QPUG) Meetup included presentations by NAG (Numerical Algorithms Group), known for its high quality numerical computing software and high performance computing (HPC) services, and Enthought, a provider of scientific computing solutions powered by Python.

Brian Spector, a technical consultant at NAG, presented “Implied Volatility using Python’s Pandas Library.” He covered a technique and script for calculating implied volatility for option prices in the Black–Scholes formula using Pandas and nag4py. With this technique, you can determine for what volatility the Black–Scholes equation price equals the market price. This volatility is then denoted as the implied volatility observed in the market. Brian fitted varying degrees of polynomials to the volatility curves, then examined the volatility surface and its sensitivity with respect to the interest rate. See the full presentation in the video below:

Continue reading

Python at Inflection Point in HPC

Authors: Kurt Smith, Robert Grant, and Lauren Johnson

We attended SuperComputing 2013, held November 17-22 in Denver, and saw huge interest around Python. There were several Python related events, including the “Python in HPC” tutorial (Monday), the Python BoF (Tuesday), and a “Python for HPC” workshop held in parallel with the tutorial on Monday. But we had some of our best conversations on the trade show floor.

Python Buzz on the Floor

The Enthought booth had a prominent “Python for HPC: High Productivity Computing” headline, and we looped videos of our parallelized 2D Julia set rendering GUI (video below).  The parallelization used Cython’s OpenMP functionality, came in at around 200 lines of code, and generated lots of discussions.  We also used a laptop to display an animated 3D Julia set rendered in Mayavi and to demo Canopy.

Many people came up to us after seeing our banner and video and asked “I use Python a little bit, but never in HPC – what can you tell me?”  We spoke with hundreds of people and had lots of good conversations.

It really seems like Python has reached an inflection point in HPC.

Python in HPC Tutorial, Monday

Kurt Smith presented a 1/4 day section on Cython, which was a shortened version of what he presented at SciPy 2013.  In addition, Andy Terrel presented “Introduction to Python”; Aron Ahmadia presented “Scaling Python with MPI”; and Travis Oliphant presented “Python and Big Data”. You can find all the material on the website.

The tutorial was generally well attended: about 100–130 people.  A strong majority of attendees were already programming in Python, with about half using Python in a performance-critical area and perhaps 10% running Python on supercomputers or clusters directly.

In the Cython section of the tutorial, Kurt went into more detail on how to use OpenMP with Cython, which was of interest to many based on questions during the presentation. For the exercises, students were given temporary accounts on  Stampede (TACC’s latest state-of-the-art supercomputer) to help ensure everyone was able to get their exercise environment working.

Andy’s section of the day went well, covering the basics of using Python.  Aron’s section was good for establishing that Python+MPI4Py can scale to ~65,000 nodes on massive supercomputers, and also for adressing people’s concerns regarding the import challenge.

Python in HPC workshop, Monday

There was a day-long workshop of presentations on “Python in HPC” which ran in parallel with the “Python for HPC” tutorial. Of particular interest were the talks on “Doubling the performance of NumPy” and “Bohrium: Unmodified NumPy code on CPU, GPU, and Cluster“.

Python for High Performance and Scientific Computing BoF, Tuesday

Andy Terrel, William Scullin, and Andreas Schreiber organized a Birds-of-a-Feather session on Python, which had about 150 attendees (many thanks to all three for organizing a great session!).  Kurt gave a lightning talk on Enthought’s SBIR work.  The other talks focused on applications of Python in HPC settings, as well as IPython notebooks on the basics of the Navier-Stokes equations.

It was great to see so much interest in Python for HPC!

PyQL and QuantLib: A Comprehensive Finance Framework

Authors: Kelsey Jordahl, Brett Murphy

Earlier this month at the first New York Finance Python User’s Group (NY FPUG) meetup, Kelsey Jordahl talked about how PyQL streamlines the development of Python-based finance applications using QuantLib. There were about 30 people attending the talk at the Cornell Club in New York City. We have a recording of the presentation below.

FPUG Meetup Presentation Screenshot

QuantLib is a free, open-source (BSD-licensed) quantitative finance package. It provides tools for financial instruments, yield curves, pricing engines, creating simulations, and date / time management. There is a lot more detail on the QuantLib website along with the latest downloads. Kelsey refers to a really useful blog / open-source book by one of the core QuantLib developers on implementing QuantLib. Quantlib also comes with different language bindings, including Python.

So why use PyQL if there are already Python bindings in QuantLib? Well, PyQL provides a much more Pythonic set of APIs, in short. Kelsey discusses some of the differences between the original QuantLib Python API and the PyQL API and how PyQL streamlines the resulting Python code. You get better integration with other packages like NumPy, better namespace usage and better documentation. PyQL is available up on GitHub in the PyQL repo. Kelsey uses the IPython Notebooks in the examples directory to explore PyQL and QuantLib and compares the use of PyQL versus the standard (SWIG) QuantLib Python APIs.

PyQL remains a work in progress, with goals to make its QuantLib coverage more complete, the API even more Pythonic, and getting a successful build on Windows (works on Mac OS and Linux now). It’s open source, so feel free to step up and contribute!

For the details, check out the video of Kelsey’s presentation (44 minutes).

And here are the slides online if you want to check the links in the presentation.

If you are interested in working on either QuantLib or PyQL, let the maintainers know!

Exploring NumPy/SciPy with the “House Location” Problem

Author: Aaron Waters

I created a Notebook that describes how to examine, illustrate, and solve a geometric mathematical problem called “House Location” using Python mathematical and numeric libraries. The discussion uses symbolic computation, visualization, and numerical computations to solve the problem while exercising the NumPy, SymPy, Matplotlib, IPython and SciPy packages.

I hope that this discussion will be accessible to people with a minimal background in programming and a high-school level background in algebra and analytic geometry. There is a brief mention of complex numbers, but the use of complex numbers is not important here except as “values to be ignored”. I also hope that this discussion illustrates how to combine different mathematically oriented Python libraries and explains how to smooth out some of the rough edges between the library interfaces.

Advanced Cython Recorded Webinar: Typed Memoryviews

Author: Kurt SmithWebinar_screenshot

Typed memoryviews are a new Cython feature for accessing memory buffers, such as NumPy arrays, without any Python overhead. This makes them very useful for manipulating blocks of memory in Cython directly without calling into the Python-C API.  Typed memoryviews have a clean declaration syntax and have a NumPy-like look and feel, supporting slicing, striding and indexing.

I go into more detail and provide some specific examples on how to use typed memoryviews in this webinar: “Advanced Cython: Using the new Typed Memoryviews”.

If you would like to watch the recorded webinar, you can find a link below (the different formats will play directly in different browsers so check to see which one works for you, and you won’t have to download the whole recording ahead of time):

“venv” in Python 2.7 and how it Simplifies Life

Virtual environments, specifically ‘venv’ which we backported from Python 3.x, are a technology that enables the creation of multiple, lightweight, independent Python environments. Each virtual environment appears to be a self-contained Python installation, but loads the Python standard library and other common resources from a common base Python installation. Optionally, a virtual environment can also load packages from its base Python environment, whether that’s Canopy Core itself or another virtual environment.

What makes virtual environments so interesting? Well, they reduce disk space by not having to duplicate the full Python environment each time. But more than that, making Python environments far “lighter” enables several interesting capabilities.

First, the most common use of virtual environments is to allow separate projects to run in separate environments with different packages requirements. Each Python application runs in a separate virtual environment so package updates needed for one application don’t break the others. This model has long been used by web developers as well as a few scientific software developers.

The second case is specifically enabled by Canopy. Sharp-eyed readers will have noted in the first paragraph that we said that a virtual environment can have Canopy Core or another virtual environment as the base. But virtual environments can’t be layered, right? Now they can.

We have extended venv to support arbitrary numbers of layers, so we can do something like this:

'venv' in Canopy

‘venv’ in Canopy

‘Project1’ can be created with the following Canopy command:

canopy_cli  setup  ./Project1

Canopy constructs Project1 with all of the standard Canopy packages installed, and Project1 can now be customized to run the application. Once we’ve got Project1 working with a particular Python configuration, what if we want to see if the application works with the latest version of NumPy? We could update and potentially break the stable environment. Or, we can do this:

./Project1/bin/ venv  -s  ./Project1_play

Now ‘Project1_Play’ is a virtual environment which has by default all of Project1’s packages and package versions available. We can now update NumPy or other packages in Project1_play and test the application. If it doesn’t work, no big deal, we just delete it. We now have the ability to rapidly experiment with different (safe) Python environments without breaking our stable working area.

Canopy makes use of virtual environments to provide a protected Python environment for the Canopy GUI application to run in, and to provide one or more User Python environments which you can customize and run your own code in. Canopy Core is the base for each of these virtual environments, providing the core Python components and several common, large packages such as Qt and PySide. This structure means that the Canopy GUI can be updated without impacting your code, and any package updates you install won’t destabilize the Canopy GUI.

Canopy Core can be updated if you want, such as to move to a new version of Python, and each of the virtual environments will be updated automatically as well. This eliminates the need to install a new Python environment and then re-install any third-party packages into that new environment just to update Python.

For more information on how to set up virtual environments with Canopy, check the online docs, or get Canopy v1.1 and try it out.

Our next post will detail how to use Canopy and virtual environments to set up multi-user networks and cluster environments.

Canopy v1.1 – Linux, Command Line Interface and More

Final-version-canopy-logo (1)

With version 1.1, Enthought Canopy now:

1) addresses, much more completely, the command line use cases that EPD users and IT managers expect from their Python distributions,

2) makes Linux support generally available,

3) streamlines installation for users without internet access with full, single-click installers,

4) supports multiple virtual environments for advanced users via “venv” backported to Python 2.7, and

5) provides updates like numpy 1.7.1, matplotlib 1.3.0 and more.

It’s been just over 4 months since Canopy v1.0 shipped with the new desktop analysis environment and our updated Python distribution for scientific computing. Canopy’s analysis environment seems to be well-received by users looking for a simpler GUI environment, but the Canopy graphical installation process left something to be desired by our EPD users.

Along with the Canopy desktop for users that don’t want to work directly from a command line, Canopy version 1.1 now provides command-line utilities that streamline the installation of a complete Python scientific stack for current EPD users who want to work from the shell or command line. In addition, IT groups or tools specialists that need to manage a central install of Python for a workgroup or department now have the tools they need to install and maintain Canopy. Version 1.1’s command-line installation and setup (and the 1-click, full installers detailed below) are much better for supporting Canopy installations on clusters as well.

Canopy for Linux is now fully released. We have full, tested support for RedHat5, CentOS5, and Ubuntu 12.04. Linux distros and versions beyond those work as well (anecdotally and based on some in-house use), but those are our tested versions.

With Canopy v1.0 we implemented a 2-step installation process. The installer includes the Canopy desktop, the Python packages needed by Canopy itself, and other core scientific Python stack packages for a minimal install (the libraries in Canopy Express). For those with a subscription, the second step requires downloading any additional packages using the Package Manager. This 2-step process is problematic for users that don’t have easy internet access or need to install centrally for a group. To help, we now provide full installers with all the Python packages we support included. This provides a streamlined 1-step install process for those who need it or want it.

To ensure users can install any package updates they wish without messing up package dependencies for Canopy itself, we use virtual environments under the hood. With v1.1 we now provide command-line access to our backport of “venv”. The new CLI provides utilities to create, upgrade, activate and deactivate your own virtual environments. Now its much easier to try out new Python environments or set up multiple configurations for a workgroup.

Canopy v1.1 ships many updates to packages and many new ones: OpenCV, LLVM, Bottleneck, gevent, msgpack, py, pytest, six, NLTK, Numba, Mock, patsy and more. You can see the full details on the Canopy Package Index page.

We hope you find version 1.1 useful!

SciPy 2013 Cython Tutorial

Author: Kurt Smith

Thanks to everyone who attended the Cython tutorial at this year’s SciPy conference, and thanks to the conference organizers and tutorial chairs for ensuring everything ran smoothly. The enthusiasm of the students came through in their questions, and there were several good conversations after the tutorial throughout the week.

If you want the tutorial experience from the comfort of your couch, you can download the tutorial slides, exercises, and demos, and follow along with the videos. Please read the setup instructions on the tutorial webpage. The easiest way to satisfy the requirements for the tutorial is to download and install an existing scientific Python distribution, such as Enthought Canopy. You will need Cython version 0.19 or greater.

SciPy Talk

Tutorial Highlights

Cython is a language for adding static type information to Python with the objective of improving Python’s performance; it is a compiler (the cython command) for generating Python extension modules; and it helps wrap C and C++ libraries in a nice and Pythonic way with a minimum of overhead. These three aspects of Cython are tightly integrated with each other and shouldn’t be thought about in isolation: it is common to have Cython code that is intended to both speed up a pure-Python algorithm and that also calls out to C or C++ libraries.

Compared with some of the newer Python JIT compilers that are on the rise, Cython is relatively mature — not SWIG mature, but it certainly has been around long enough that it has grown features beyond its core functionality: annotated source files for compile-time performance profiling, runtime profiling that integrates with Python’s profilers, cross-language debugging capabilities, integration with IPython and the IPython notebook via the %%cython magic and other magic commands, the pyximport import hook support, Python 2 and Python 3 support, parallelization support via OpenMP, and others. I wanted this tutorial to touch on several of these extra capabilities that make Cython easier to use.

The tutorial was in the advanced track because I wanted to dive into newer and more advanced Cython features, especially typed memoryviews. Typed memoryviews are Cython’s interface to PEP-3118 buffers, the new buffer protocol for accessing and passing around (possibly strided) blobs of memory without copying. This is of considerable interest to scientific computing audiences for whom non-copying array operations are essential. NumPy arrays support this protocol, and are the primary object used with this protocol. Cython’s syntax for typed memoryviews is nice, and taking a slice of a typed memoryview yields another typed memoryview and, as you would expect, does not copy memory.

I was able to cover typed memoryviews towards the end of the tutorial, but didn’t have quite enough time to demonstrate their full power. Typed memoryviews are in every way superior to the existing numpy buffer support in Cython (the cdef np.ndarray[double, ndim=2] declarations) — they are faster, they are supported in function signatures for every kind of Cython function definition (def, cdef, and cpdef), they are easier to declare and use, and they do not have any external dependencies (i.e., you do not have to cimport anything to use them, and you do not have to add extra include flags when compiling).

Another advanced topic I touched on in the tutorial was wrapping templated C++ classes. Cython’s syntax for wrapping templated C++ is fairly easy to work with if you are wrapping just one template instantiation. Once you need to wrap several template instantiations, I recommend you use a code generation tool like cheetah or jinja2 to avoid manual code duplication. It is often helpful to provide a top-level wrapper class for a more Pythonic experience. Examples of this approach are in the tutorial material zip file. Cython’s fused types can alleviate the need for these workarounds, but can require some gymnastics of their own to use. The “real” solution to wrapping many instantiations of C++ templates is a templating system or macro system in Cython itself, which is hard to get right and is likely beyond the scope of the project.

I also wanted to demonstrate how to wrap modern Fortran: user derived types, assumed shape and assumed size arrays, module procedures, etc. You can accomplish this using the ISO_C_BINDING module that is part of the Fortran 2003 standard and supported by nearly every modern Fortran compiler. Alas, this had to be cut due to time constraints. I want to emphasize that it is possible to use Cython to provide very nice wrappers for modern Fortran, keeping Fortran relevant as a viable performance-oriented language that gains expressivity with Cython-generated Python wrappers.

Cython Webinar

I will be giving a Cython webinar to cover some of the topics that were skipped during the SciPy tutorial. I will likely cover typed memoryviews in more depth, and perhaps give more detail on getting Cython to work with modern Fortran and templated C++. If you have a subscription to Enthought Canopy, you will receive a notification for the webinar, so stay tuned. Or sign up for an Enthought account to get a notification.