Invited talk on Python as the glue of the modern scientific workflow, from robotic-telescope automation and real-time transient-discovery pipelines to machine learning in astronomy.
Listed on PyVideo; verify YouTube ID at build time.
“We are not, in some sense, portrait artists of the sky; we are celestial cinematographers, and time is a very important component of us understanding what's happening out there in this vast and dynamic universe.” – Joshua Bloom
“We can't be listening to all of our data, we can't be observing all of our data as a person, we can't scale Jodie Foster to ten-to-the-six people; that just doesn't make sense at all.” – Joshua Bloom
“My view of doing probabilistic classification with machine learning is that the way you find needles is that you get very good at identifying hay.” – Joshua Bloom
“Python is this incredibly wonderful super glue. And I think, although I haven't heard it said here yet, I think it's poised to become the de facto engine for modern science, and I think we should all be very excited and very proud about that.” – Joshua Bloom
Thanks for the introduction, Fernando, and I want to thank the organizers and the sponsors, but mostly I want to thank all of you for your efforts in making Python really the engine of modern science. This talk is really meant to highlight the top of the stack of Scientific Python and to show you that many of the results that make it to the popular press are actually results that are based on Python. So a lot of the science that you're seeing, that your parents are asking you about, that you're reading about in the papers and seeing on the news, so much of that has Python inside, and I thought it'd be useful for everyone here to hear about that. My name is Josh and I'm an astronomer.
I'm certainly not as badass as the most famous and outspoken astronomer, so I apologize for that, Neil deGrasse Tyson. And I'm definitely nothing like Vermeer's astronomer. He's unlike any scientist I know. Actually, first, he's clean-shaven. Second, optical astronomers really don't do a lot of their best work during the daytime; you'll notice this is the middle of the day. But most important, this Eureka moment is something that he's having because it's been handed to him on a silver platter, in this case the celestial globe that's been constructed by monks, probably. I think the important thing to recognize with modern science is that we're really working in the muck. We're knee-deep in data and we're throwing every tool that we have at it. This quaint view doesn't really cut it anymore.
Python, I think it's fair to say, is in every component of my scientific life, and rather than tell this story and form this talk from the perspective of toolkits, from what's under the hood, I think it makes sense to present this in some sense anchored by the scientific challenges and results that have been coming out because of Python. Because fundamentally it's the scientific interests that drive our need for solutions. Science is the reason why this community does what it does. Why build and optimize an application if there is no application at the end of it? So what is it that I use Python for? Well, I'm not going to talk about everything, of course, but I will talk about the automation of data collection and inference in my group's work, and in particular talk about robotic telescopes and data reduction, talk about communication, logistics and visualization, talk about machine learning with an eye towards Big Data and astronomy, and then touch on a couple of different aspects of dissemination and education, and in particular mention some of the teaching that we've been doing at Berkeley.
The idea here, of course, is that Python is making science happen through this whole stack, as I said. So I think the thing to do, of course, is show you how we do that in a Python file, and you can get this on GitHub and you can fork it. I guess, are you allowed to say fork here? Is this public? Okay, anyway. So first we have to do some exploration and discovery. So we try to get a new idea; that doesn't work out, take somebody else's idea, try to get some funding. You have to make a proposal, you've got to wait six months, probably won't get funded, you keep on looping until you get that funding. And when you get the funding you instantiate a bunch of grad students, postdocs, undergrads, etc., throw them into a pool, and then you just have them write that up. You have to get the data, find the results, make a paper, submit it to Science, and of course you don't have to go through any iterations there because it gets accepted without revision. And then of course you have to get some credit, stick it on your CV, and that's it. Right? That's all we should be doing here.
This is not quite Import Flying from XKCD, but it's close. Obviously this is not at all like what we do in astronomy and science in particular, but Python is there at the nitty-gritty, and I hope to show you different aspects of that. My interest as an astronomer is in the changing universe, the time-domain universe, the so-called dynamic universe, the idea that everything in the universe is moving or changing its color or changing its brightness, and with enough sensitivity, even on human time scales, that kind of change is now accessible to us and becoming more so. We are not, in some sense, portrait artists of the sky; we are celestial cinematographers, and time is a very important component of us understanding what's happening out there in this vast and dynamic universe.
So we'll go through some examples of all those different types of changes. One is motion in space, and this is perhaps the most important three-frame movie you've ever seen in your life. You didn't realize that, but here it is. Why is this so important? Well, you see, first of all, the noise; you see a bunch of different stars, but there's an object that's moving in here. Who can find that? Yes, I see people pointing in the general direction. It's somewhere over there. Yeah, right there. There, you see that thing right there. That is the discovery of Eris, the object which turned out to be larger than Pluto and killed Pluto as a planet. It was taken with a half-century-year-old telescope, 20-second exposures, and was a massive needle-in-the-haystack effort, but obviously paid off in spades. This is a composite of two Hubble Space Telescope images showing the motion of what is now believed to be the images of the first extrasolar planet.
So motion in space obviously is teaching us a great deal about our universe around us. What's amazing, of course, is that if you have that precision to be able to see and notice things changing and moving on the sky, you can actually not only measure their velocity with respect to Earth, but you can also start to make measurements of distance. Finding the position of an object on the sky is pretty easy in two dimensions, but getting its distance is incredibly hard, and so much of what astronomers do at some level can be boiled down to finding distance. That back-and-forth wobbling that you see on this one object right here, and this is a model fit to a bunch of data, is called parallax, and the motion across from top to bottom is what's called proper motion. And you see a bunch of different data points here. Just to give you a sense of scale, that motion is Guido at about 16 times the distance to the International Space Station. So it's an incredibly difficult set of measurements to make; it's very fine motion. Yes, I just did a star wipe, Guido away.
So how do we make those measurements? Well, we take images of the sky, but of course the images that we take are imperfect, and so when we try to align those images and find how these objects are changing in the sky with respect to the other stars, you have to make maps of how all these different stars line up on top of other stars in other frames. And this distortion map is something that people have been doing for years, if not decades or centuries, but what's remarkable is that people have been doing this in a fairly frequentist way. Measuring the rotation and scale is something that should obviously be a Bayesian framework for doing this, but this hasn't been done yet. So my group has started working on this problem, trying to do essentially very good astrometry, as it's called, measurements of positions of stars with respect to other stars, and we've been using SciPy for that. Because we have to invert essentially a large matrix, a covariance matrix of the position of every star with respect to every other position of the star. And so here's an image of two different covariance matrices, and your job here is to figure out which one of these is going to wind up being invertible. The one on the left. The point here is that when you want to do an inversion of a matrix, if your matrix is not positive definite or positive semi-definite, then you've got a big problem.
What we do here is we essentially change the matrix a little bit and find all the very small and negative eigenvalues and set them to a very small positive number. And there's some good theoretical constructs for why this makes sense to do, but the nice thing is we can then just go ahead and invert that matrix and get the solution that we need, and then we run this through a big MCMC chain to be able to get posterior distributions of the locations of stars with respect to other stars. And this code is now up on GitHub as well; the paper on this we hope to hit the archives in the next week or so. So that's motion. Stars are also changing their brightness. Here's six stars from the Kepler Mission, launched several years ago, and this just looks like stars burbling along, and then when you start looking at what the y-axis is and the scale of the y-axis, you realize how unbelievable the photometric precision we have now is. This is one part, or a few parts, in a million, and this burbling is obviously of great interest to a number of groups. And the Kepler mission is poised to find the first extrasolar planets that live in the habitable zone that have a mass and radius similar to Earth, and they'll be doing that by looking at these extreme subtleties in this data.
My interest is really in things that go boom, and so not one part in a million, but things that get brighter by a factor of a million or a hundred thousand or a hundred million. In some sense those are easier to work with. One of the things that I've been working on recently is understanding how black holes gobble up gas and grow, and we have a number of different light curves, as they're called, brightness as a function of time, from a number of different surveys. And one of the questions we asked is, if we have a representative light curve over several years in a couple of different bandpasses, it turns out that every black hole grows and burps and belches in different ways, but they all do it in a way that's statistically similar. So there's this interesting question: in irregularly time-sampled and noisy data, how do you make a statement about whether some change or sets of changes are similar to another set of changes? And so we have a sample of something like a hundred thousand light curves of sources, and we want to find out which one of these things are like quasars or massive black holes that are putting on lots of light. And so we do this also with SciPy, some of the linear algebra programs, maximizing a posterior probability of a damped random walk, which is the model that people have found best describes the statistical behavior of these light curves. And then when we have new light curves, we essentially ask, is this data consistent with being drawn from this model? And this is a nice code; it works very fast, and it's all basically due to some of the great modules that we can find within SciPy.
And how good is it? Well, this is a bit of a busy plot, but if you focus on the red and you look at the x-axis, you wind up noticing that we have very good separation between the red, which are known quasars, and the blue, which are known stars in the same field. And this is the sort of separation that people have been dreaming about for a long time, because once you find these quasars, you then need to go follow them up with precious spectroscopic resources. So we were able to produce what we think is a 99% complete catalog of this large data set, and something which was very pure, so very little contamination from non-quasars. And instead of looking in the traditional color space, we're able to look in the time-domain space and pull these things out. So that was, I think, a very exciting result. The point about the time domain, in some sense, is that we have lots of things changing in the sky. It's not just quasars, it's not just twinkling stars. The extragalactic explosive systems are of great interest. Many of you probably know about Type 1a supernovae and Type 2p supernovae; those are the most common types of supernovae in the universe. But there's also theoretical constructs of what other types of stars might do when they blow up. There's a so-called pair-production supernova, which are very bright, and then there's the neutron-star neutron-star merger models, which may be related to gravitational waves. And you can see these things are different brightnesses, they happen on different time scales, and the goal here in time-domain astronomy is to be able to find these things and then follow them up very rapidly.
So we have, in some sense, a Rumsfeldian view of the universe. We've got the known knowns in the Type 1a supernovae and the Type 2p supernovae, the unknown unknowns, which I obviously can't put on this plot, and the known unknowns, and we're trying to look for all of these things at the same time. What's obviously incredibly preposterous is the idea that we would actually be communing with our data in the way that you read about in the popular press or watch on movies. We can't be listening to all of our data, we can't be observing all of our data as a person, we can't scale Jodie Foster to ten-to-the-six people; that just doesn't make sense at all. And the important thing here is that even if you're able to find objects that are going bump in the night, how do you know what they are, and how do you decide what to do with the resources that you have at your disposal for following those up and getting the real science out?
The exciting thing for us is that we are entering an era of great exploration in the time domain. There are a number of surveys that have come before, that are happening now, but the thing that's very exciting for many of us is the so-called Large Synoptic Survey Telescope, which, it was announced yesterday by the National Science Foundation that they've been given the green light to essentially get funding, starting with construction in fiscal year 2014. So this is really this massive discovery engine waiting to happen. Just to give you some indication of the types of numbers we're looking at, we're talking about light curves for order 800 million sources that will be updated every three days, something like a million supernovae a year, and something like 20 terabytes per night of raw imaging data that we're going to have to go through. And then there are other surveys at other wavebands happening: LOFAR and SKA, and the Gaia space astrometry mission, which will be the mission that finds those little astrometric wobbles to get distances. And so while we're very excited about this changing and dynamic universe, one of the things we're obviously worried about is how we're going to deal with all of this data.
So this is the data deluge challenge that we have in front of us, and let me pose it in this way, this question: how do we do discovery, follow-up and inference when the data rates and requisite time scales preclude human involvement? The obvious answer to this, of course, is that we have to automate what used to be that workflow that had scientists in that loop, but we need to get those scientists out of that loop and abstract them from their traditional roles. So, automating the scientific workflow. This is a bit of a cheeky slide, but I thought it'd be useful to show. We've got this barrier to automation on the y-axis, and how difficult is this to do on the x-axis, and we've got a chain here of observing and finding and discovery and classification and follow-up and then the scientific inference. And each one of these aspects require and demand their own specialized sets of codes, their own specialized sets of algorithms. There's, on the observing side, robotization and queue scheduling; finding, that is essentially taking the data and actually sticking new objects from raw data into databases; doing discovery, perhaps using computer vision and image recognition; classification, there we're using machine learning techniques; follow-up, there you have again robotic telescopes that are going to help you, and making sure that you're not spending all of your resources on things that aren't going to have scientific payout.
This should be, I think, fairly intuitive for all of you. One of the things I wanted to point out is this distinction between finding and discovery, the idea that you have data in your database and you have discovered that object or that data is preposterous, right, especially when your databases are large. Just because you know that that object exists doesn't mean that you've made that recognition that that object is interesting. And the classic example from astronomy is Galileo and Neptune. While Galileo was looking at his more nearby object, it was Jupiter's moons, he happened to jot down in his notebook a star that happened to be moving a little bit, and it turned out about 200 years later was discovered to be Neptune. So Galileo had in his notebook Neptune, but he's not credited as being the discoverer of Neptune, and I argue he would have been very famous if he had been.
So let me talk about automating discovery and the robotization of telescopes, and this really brings me to my personal story with Python. In 2002 I started my postdoc at Harvard and recognized that there weren't a lot of telescopes, in fact no telescopes out there, that were going to be able to follow up on new gamma-ray burst positions, essentially very large exploding stars, at infrared wavelengths. And there was a telescope that had been used by the so-called 2MASS survey for almost a decade that had been essentially mothballed in Arizona, and I asked for some funding to basically roboticize it, bring it back from the dead, modernize it, and get into all the different subsystems so that we could respond quickly to new alerts, but also so we could basically get the observer out of that loop and have a fully functioning system that could do this by itself. So in 2002 I asked my hacker friend at Los Alamos, Mark Galassi, which language should I use, and I was thinking he was going to say Tcl/Tk, which I'd used before, and he said use Python. And I said, what the hell is that? And he said, just try it out. So I decided this was going to be my first Python project and started ramping up from there. And we got first light in 2003, and we were up and running at the time that the new satellite from NASA called Swift was launched in 2004.
So what we did is we basically created a fully autonomous telescope out of what had been a 10-, 15-year-old project that had a lot of people in that loop. We had autonomous scheduling based on complex prioritization, detailed weather sensing, quick reactions to new events without any of these humans in the loop. So essentially it was listening to some TCP/IP socket waiting for new alerts to come through, and then it would just slew over and start taking data. We also had the telescope tweeting where it was looking so people could follow this, and we tried to bring robotic transient astronomy into the 21st century with this. So I'll do a little demo of the facility, which is still working on a nightly basis. I was going to try to open up for you and show you the sky, but it turns out it's pretty cloudy and rainy in Arizona right now, so I'm a little bit worried about opening up on a several-million-dollar facility just for shits and giggles. Sorry, we can bleep that out later. What you're looking at here is basically a video feed from inside the dome, and you can see this little crack here of light because it's daytime, obviously, in Arizona. And what I can do, if things work out — who, don't do this, exit on me — oh no, we're good — is try to turn the light on. Okay, so we can see inside, you can see inside the dome now, and there's the telescope, and there's the camera right there.
And what I can also do is I can start moving this telescope. First of all, let me show you the Python code that we're using. Might be a little bit hard to see here; I'll try to do a which version of Python. Am I using 2.3.3? Basically we got this whole thing working, and it was working, and then we said, hell no, we are not upgrading at all. So we're stuck back in the Dark Ages, but the point here is that Python has been working almost now for eight years and running this robotic telescope. So we can try to see if we can move this thing. It's hard for me to see. Okay, so we're going to send some low-level commands through a serial port. I'm going to tell it which elevation and azimuth to go to. Let's see if that actually works. Question mark there. Yeah, watch the screen. There's no sound, sorry; you can think about whatever music you have in your head. The thing I wanted to point out here is that we run this thing as a state machine, and so every few seconds this little GUI that we have shows us what the telescope is doing. And each one of these different cells here is run by a different daemonized Python code which is essentially writing little states, and we have a master daemon which is overlooking all of these and knows how to make changes. When it says, oh, it just went from nighttime to dusk or nighttime to dawn, let me now close down the telescope and go through these various sets of operations. And then we can see where that telescope is pointing at any time, we can get a last on what the telescope was doing in any one of these cells, and this thing has basically been unchanged for eight years or so. I better put the telescope back to where it should be instead of 70. What should I write, elevation of 90? Point back to zenith. Okay, so that didn't fail horribly.
So I guess the point here again is that essentially everything here has got Python under the hood, and it's not just the automation of the telescope and all of its different subsystems, it's the data reduction of all that data that's coming off. There's obviously a number of different results to highlight from here, but I wanted to show you one of my favorite movies of a gamma-ray burst afterglow which was observed one minute after it was detected by a satellite, which then sent down essentially an alert to the world, which got broadcast out from Goddard Space Flight Center, made its way up to the mountain, telescope slewed over, started taking data. And so we have a number of sub-one-minute responses, and you can figure out which object it is that's changing very rapidly. You can also see that if you get on with a large telescope later on, this source is fading out very quickly, you might be able to catch it, but even with a small telescope — and this is a 1.3-meter telescope, I think it is the largest robotic telescope still in the world — you can actually see these things when they're fantastically bright and do some very interesting science at early times. I have a grad student working on that right now for his PhD thesis.
Robotic telescopes are really all the rage, and one of the things here is that it's not just telescopes which know how to open and close themselves and respond to weather, but can then also start talking to each other and start making federated decisions about what it is to observe. It's an interconnected and very exciting ecosystem, and it's only getting bigger and bigger. Okay, I want to talk a bit now about automated discovery, and again this idea that just because you've got something in your database doesn't mean that you've actually found it or actually identified it as being interesting. And the way that we do discovery on transient or changing objects is essentially something called difference imaging, where you have a deep reference image and you have a new image, and you basically subtract the two. And doing the alignment is hard, and obviously with all the defects in the detectors and in the optics, this is an imperfect process. You see a pretty good subtraction on the top panel and a not-so-good subtraction on the bottom panel. These are actually two very well-known now supernovae found in the Palomar Transient Factory, both found by our codes. The top one I'll talk about in just a bit, but the thing I want to point out are these red boxes in this bottom panel on the far right with 11kx. Those are detections in a sense that they show up in the database, but they're obviously spurious because it was an imperfect subtraction.
So we have again a needle-in-the-haystack problem that we've been thinking about how to handle, and what we did is in 2008 we built a website to allow a bunch of experts to basically say whether they thought the subtraction was real or bogus, and then weigh in on a couple hundred or a couple thousand of these initial images from this survey. And we built this on the Google App Engine, and it made it very easy to get up and running and to essentially get lots of feedback from people on these various subtractions. So people would essentially slide this bar from bogus to real and things that are definitely real. So, to the trained eye, the object on the bottom is pretty real, the stuff in the middle is probably bogus, and the stuff at the top is almost certainly a bogus subtraction. But we have a thousand objects that we don't really care about, or spurious detections, to every one that we do. And when we start talking about the massive amount of data that we're getting just with this precursor survey called the Palomar Transient Factory to LSST, we obviously have a major bottleneck where we can't be throwing real human eyes at this problem all the time. So what the machine learning codes basically do is act as surrogates, and they try to say what they think this subtraction is, to mimic what experts would say.
And to put some numbers to this, in the Palomar Transient Factory we have about 1.5 million candidates a night. Only about a thousand of those are bona fide sources, and maybe only 300 of those are variable stars, and 10 of those are perhaps real interesting transients that we want to follow up. Most of the real things that we find are actually asteroids, and what you see is a distribution of pretty much what the machine said about 20 million candidates from the first month of data. And we're now reaching, I think we're basically at a billion candidates in that survey, and machines have essentially weighed in on all this to make sure that we don't have an asteroid and start throwing our resources at things that none of us in our survey care about. We built a parallelized minor planet checker called PIMP Checker, and it runs on an eight-core machine, and it's about 10 times faster than the Minor Planet Center's MPChecker, which is essentially what everyone has been using. This is a web service that we've exposed, again it's Django, and it's using an astronomy package called PyEphem, and it was written by a grad student about two months in the first summer when he arrived to start his PhD at Berkeley. And we're getting a lot of traction on this; there's a number of other groups around the world who are starting to ask questions of whether their source is actually an asteroid or not. So that allows us to weed out the bad sources and then get down to the really nitty-gritty.
And here's the visualization of all the thousand new variable stars and transients that were found by the Palomar Transient Factory in its first two years, and this was done with matplotlib. The red circle which is coming around is Andromeda, and we obviously spent a lot of time on top of Andromeda. We try to look at lots of nearby galaxies in the hope that there is something really interesting happening, and that really interesting thing happened, actually, wonderfully, at the end of last summer. An object called PTF 11kly was detected within the Pinwheel Galaxy, which is one of the most nearby beautiful spirals, and it's well observed by amateurs. And we think we caught this thing 11 hours after explosion, and we wound up getting a spectrum within 24 hours after the explosion occurred, which is unprecedented for any type of supernova but especially for a Type 1a supernova, and it turned out to be the nearest Type 1a supernova in more than three decades. And the important thing here is that it was promoted to the top of our candidate list by our machine-learned codes, which again have basically a lot of Python inside. This got a lot of press, of course; the Huffington Post quoted me as saying this was the supernova of a generation, which I like to show to my family and now I'm showing to you, because you're my family in some way.
But more importantly, obviously the press stuff is very interesting and very important for outreach, but more importantly, because it was the most nearby Type 1a supernova, we were able to get the best constraints by a factor of 100 on what makes these things. Type 1a supernovae are incredibly important for cosmology, they really touch all aspects of astrophysics, so having an object that's this close by allowed us to really rule out a number of so-called progenitor possibilities, and this is really the first time we've been able to do something like that. This is a plot that I made in matplotlib and used PySynphot from HST, and it took me a long time to make this plot, so I hope you like it. This showed up in Nature at the very end of last year. Okay, so just because you've discovered something doesn't mean that you actually know what to do with it or you understand what it is. And so this is the end of the line, at some level, of how do you do classification, how do you do human levels of cognition, where you used to show to somebody, hey, what is this object, and they say, ah, that looks like a Type 1a supernova to me. Now you need machines to be able to do that.
But there's considerable complications with time-series data that we deal with. First of all, it's noisy and irregularly sampled, we often have spurious data in our databases, so we have to be able to handle that, and sometimes, if we're thinking about follow-up, the main event, the thing, let's say in this case the thing that's getting brighter, hasn't even happened yet, so you might need to have theoretical constructs to help you decide where to spend your energies. And so, without going into details about feature-based machine learning, what we do on all of these light curves that we spend time with is we homogenize this very noisy data into a large space of essentially real number lines, and we derive metrics off of these light curves. And everything in blue are the typical metrics that you would think about using if you were given a time series of data and you wanted to pull out the essence of what was in that time series. And in red are these so-called context metrics, the idea that even in the absence of lots of time-series data, if you just tell me the location on the sky and I can then go and query the web and find out what's around there, I may be able to make a very interesting case for what that type of object is. Obviously if it's in the ecliptic plane, it has a high probability of being an asteroid or a minor planet; if it's in the galactic plane, it's some type of stellar activity; if it's near a galaxy, it's probably a supernova; if it's in the center of a galaxy, it's probably some quasar. So without telling you the nature of the time variability, just from context alone, I can tell you something about this.
And so we've been pushing with historical catalogs on trying to get very good automated machine learning classification. This is one of our more recent error matrices that shows us how well we're doing relative from the training set — sorry, the true class — to what we would say in the training set. And you can see we have a lot of power in the diagonal, and that's good, but you can see we also have a lot of off-diagonal power here. And I'm not going to go into obviously all the different of these whatever 25 classes of variable objects, but the thing that's interesting here is that if you draw a box around these big-picture classes — the pulsational variables, eruptive variables and multi-star variables — what you wind up noticing is that a lot of the off-axis power remains in these boxes. And so at some level, even though we haven't told the machine anything about the physics of these objects, it started recognizing that it can't really distinguish between these large classes. But what's exciting is that we're now getting the global classification errors that are at the 15% level over order two dozen classes of variable stars, and if you just look at those large classes, basically if you think about the classification as a hierarchy, we're getting down to five percent error rates, which is very exciting.
We've found a random forest is outperforming pretty much any of the other machine learning techniques that we've been able to spend time with. We started this project before scikit-learn was as mature as it is today, and so we've basically been using RPy2 for all of our work, but we're starting to think about scikit-learn. And what we did is we went back into an old catalog that had been published a number of years ago, and we started to try to classify all that old data, and we built up the first probabilistic classification catalog and made this basically available on the web. We built this also with Google App Engine, and we put these very large tables into Google Fusion Tables, so Google is basically doing all the hard work for us. And you can inspect each one of these different sources, look at the classification probability vector; we've got a social component, so maybe we'll get bought by Facebook. But that's it, you can check it out, it's called bigmacc.info, and this is again using Python for all the web work; it's got Python under the hood.
What's exciting is that when you start trying to build science out of these probabilistic catalogs, you have to do things in a different way. You can't just say, give me all the objects that are classified as this and go off and write a paper about that. You have to ask the question, how pure do you need your sample, and how efficient do you need that? So if you're doing demographic surveys, perhaps you want a very high-purity sample, but you don't really care about missing a whole bunch of other objects if you're getting that high purity. But if you're doing novelty discovery, so you're actually going to try to find some anomalous source that doesn't really fit the mold, you might want to actually go off and take spectra and spend a lot of your resources following up objects that turn out to be more mundane, but you're willing to trade that high efficiency for low purity. And so you get to dial in what your science is when you have these probabilistic catalogs. And we're also very excited about the fact that we were able to find some very nearby, very bright, very rare objects that have great interest for understanding Type 1a supernovae, in this catalog that had been published essentially 10 years ago. So it's a massive needle-in-the-haystack problem, but in some sense my view of doing probabilistic classification with machine learning is that the way you find needles is that you get very good at identifying hay.
So we're not just looking back in retrospect at old catalogs, we're also now running our machine learning codes essentially in real time on real data through the Palomar Transient Factory. And you can see that the robot essentially logged in and saved this candidate and discovered it, and then said it thought it was a supernova, and then you can see all the chatter that happened after that, and this indeed turned out to be a very interesting supernova. So it's not a toy idea that machine learning is interesting and useful in astronomy; it's actually happening, and we're very excited that it's happening on real functioning systems. I want to change gears here just for the last couple of slides and talk a bit about education. This came up in one of the mini-symposia questions last evening, about what's happening on various campuses and how are we getting people trained to be able to do science with Python. And we started essentially a seminar class called Python Computing for Physical Science, and we were basically teaching all the different aspects of how Python can be used in a scientist's daily workflow. We had guest lecturers speak about these various different topics, and it's obviously dynamic, as we wind up realizing that different code bases are potentially more and more interesting or more and more useful, more and more core for people's work, we wind up introducing them into these various sessions. And at the very end we asked people to basically write a large Python code base and check it in and deal with all the software carpentry that they need that is going to help them with their own research. And we wind up getting grad students and even upper-division undergrads to go through this full, very intensive course, and we've obviously gotten some good feedback from that.
Leading up to that, we also teach a three-day boot camp at Berkeley. In 2010 when we taught it for the first time we had 85 campers, and then just in January of this past year we had 135, and we're planning now for next month to get something like 200 just on the Berkeley campus. And this is free and open to anyone who's at Berkeley, and we make most of our materials also available on the web. The other thing — and I don't want to steal too much of Fernando's thunder, he'll be talking about the notebook in just a bit — is that we're also seeing the IPython notebook as incredibly important for teaching. It's a great didactic tool, and I'm sure all of you who have been using it know that already, so I'm preaching to the choir. But we're also starting to check our notebooks into git repos, and it's becoming part of our scientific workflow, and even in the paper-writing process as well. But one of the things that I don't think is mentioned all that often — I'm sorry I missed the high-performance computing session yesterday — is that IPython is in some sense a gateway to doing parallelism with Python. And obviously a large part of what we're talking about with parallelism here is embarrassingly parallel, but I think this is a very important aspect of what Python can do in a way that some of the competitors of Python are having a hard time dealing with.
This leads me to some of my parting thoughts. First, I think the drive to get native machine learning and statistical packages competitive with R is very crucial, and I think once we have the benchmarks that show that we're doing as well or outperforming some of the same exact modern algorithms as can be found in R, then there's going to be this phase transition where people who have been resistant are going to start coming over to that. And in the era of Big Data, as evidenced by the Large Synoptic Survey Telescope coming online in several years from now, I think open-source parallelism is a key selling point for Python. People may be very comfortable with MATLAB or IDL, and it might work very well for them on a single core or single machine, but then when they have to start doing lots of jobs, and then they start having to worry about large licenses to be able to do even embarrassingly parallel projects, I think that's going to be a major stumbling point, especially for those of us in academia where money is not as easy to come by these days. So I think we need to tout that as a community, that open-source parallelism is very important. And when we're starting to teach our students, teaching them in another language that doesn't have the free and open-source view of the world really doesn't make sense anymore.
And of course, Python scientific computing isn't just SciPy, it isn't just NumPy, it isn't just dealing with arrays and doing things efficiently. I hope you've seen here that Python is really part of the entire ecosystem, the entire workflow of a modern scientist. We're using PySerial, PyParallel, we're doing web interfaces, we're interfacing with NoSQL, we're interfacing with everything out there, and Python is this incredibly wonderful super glue. And I think, although I haven't heard it said here yet, I think it's poised to become the de facto engine for modern science, and I think we should all be very excited and very proud about that. So I come back to this slide with Vermeer, and maybe we can see this in a slightly different way than we had before. Maybe we want to look at Vermeer's astronomer as a very modern scientist who is now sitting, of course, during the day, even though he's an optical astronomer, but because he's looking not at a globe made by monks but at a view of the universe that was created by this automated workflow, and with Python inside. So with that, I'll say thank you, and happy to take a few questions.