 Hey, thanks, Fernando. It is a real pleasure to be here. I'm astonished. I walk around and see so many famous and people I look up to at every turn, and I'm really impressed. It's been a real pleasure to be here. I've actually been in the corporate world now for a little while, so I always love coming back to an academic setting where my roots are, and I really enjoy the camaraderie and the dialogue that's taking place. I think there's a lot of really interesting things that can come out of this engagement. I did want to just let everybody know there is a, some of you are aware, I sort of released NumPy on a little bit funny way to sum. I sold the documentation for a little while. I'm actually coming out with a second edition. A lot of these will be given away for free. It'll be available for anybody who wants to read it. There's some updated reflections, updated ideas, updated thoughts about the NumPy community, as well as just more detail up to NumPy 1.9 covered in the new book, and it's got a new cover. It'll be available on Amazon probably a couple of weeks. So just want to let everybody give everybody a heads up. It was really fun to get back kind of in the heart of NumPy, and in the process realize, NumPy was kind of a lonely affair early on, in the first, probably six to eight months, and then it's been amazing to see just how many people have rallied around and so many contributions, a lot of it happening on GitHub now, and when I was going back in and reviewing just how many hundreds of people are contributing. There's still sort of a core set of 10 or 15 that are doing a whole lot of work, and so we should congratulate them and thank them at every turn, but it was really nice to see that. So I'm going to talk today kind of about what I've been thinking about since then. I've been kind of dreaming and thinking a little bit beyond just NumPy, and really had this idea of kind of a cute little phrase, I'll kind of try to explain it a little bit, but using Anaconda, which to me means the whole PyData ecosystem, the SciPy stack, all the things around Python that we're using and loving to light up what I call dark data, what we're calling dark data, which is an interesting application of the tools we've put together that has, turns out, a lot of interest to a lot of people. They don't necessarily understand that they're interested in it, but they really are once you bring it to them, they realize the power that we've created together. So just a little about me, most of you know me, but some are probably new. I know there's some friends in the R community, Julia communities, who wonder what were these crazy people in the Python world. So I did start as a scientist and engineer. That really was my goal, my desire. I studied satellite scaterometry. This was back in the days of Pearl and Vax machines and MATLAB. That's before Python, I was doing all this, but I love inverse problem, love applied math. That's really what my heart is. I ended up in graduate school during my PhD doing medical imaging, having to deal with larger data sets and that led me to Python because MATLAB was just, MATLAB with doubles was just running out of memory. So I had to get something else. Numeric was there, the great work that had been done before meant I could come over, start using Python, I just fell in love with it and I started doing a lot, kind of a lot of stuff with it. And then sort of those distractions led me from kind of being that scientist guy over the past 15 years, now to being that, I guess evil CEO guy. I don't know, I try not to be that guy, but ultimately end up doing a lot more of that than necessarily the science, but my heart and my energy is still, I love seeing what's happening. I really see my calling now to really help make sure that we're developing these tools. These tools keep developing, we can fund it, we can, it's not necessarily once things are known to do, it's not necessarily so lonely. So there's a lot of work that we're doing at Continuum and I wanted to talk about this idea of dark data and how the Anaconda stack and the tools around SciPy, NumPy, and Pandas really help in a really important problem in the world. So I'm not a cosmologist, sometimes I wish I were, they're pretty cool, there's some of you maybe, but I didn't realize how much dark matter and dark energy that the latest cosmological theories believe exists. So it's actually most everything is just dark. And it turns out that actually in the data world, the same is true. If you think about data processing and data that's lit up in this context for me is really data that's sort of sitting in a data store somewhere you can query against. And as you all know, most of the data that people deal with is actually sitting in files on students' desks or on random people's desks. They pull it together, done some transformations, stuck it in a file somewhere and it's kind of dark. There's CSV files, there are NPCs, HDFS, logs, emails. It's a bunch of data that could potentially be interesting but there's no way to sort of understand it, see it, it's not stored anywhere. That's what we're calling dark data and it's actually, it turns out there's a lot of it. Nobody has good estimates but I would estimate it might be similar to that by chart in terms of what actually we have and what we're looking at. And so I wanna talk essentially, it's really just a framing of the conversation to help them people understand that what the Anaconda stack does is essentially give everybody an analytic engine to help essentially bring calculation to data without necessarily having to pull it into a data store. That there's sort of this ability to kind of create virtual databases very, very quickly and very easily, kind of that can come up, spin up, go away. And that's kind of an interesting application of all the work we've been doing. It has huge ramifications, huge implications for a lot of people. So here's the traditional approach to data analysis problems, especially in large organizations or we have a collection of people. You basically take the data sources and shove it into something called a data store. That's the big data, a lot of the energy around big data today is a which data store is it gonna be in? And billions of dollars are sort of being balanced back and forth based on who's gonna win that battle. And I'm basically saying maybe that's the wrong battle. Maybe that's the wrong playing field of even thinking about where the battle is. Where the data is may not be that big of a deal potentially. You know, is it stored in one data store, is stored in another? Because if it's able to put it in a data store and then have clients run against it. Then you have the problem of you now have to get all the data in there and then the analytic engine has to be supported and all the capability has to be supported. How does that expand? Now in the Python world, we've actually created this incredible infrastructure of analytic calculations that can essentially integrate with just about any data and more and more data. I think there's definitely some holes still and some holes that we could fill if we kind of paid attention to them. So if you replace that data store with a Anaconda stack, you've essentially given people a database on top of their dark data. Now actually making that a reality, making that as seamless and smooth as all the simple clients and GUIs that sit on top of most data stores, it's some work. And a lot of the work we've been doing at Continuum is really about making that easy and seamless and transparent to essentially light up your HDF-5, your CSV, your JSON, your XMLs, your logs, make those as easy to process on as your data sitting in some large data store. Make that easy. So that's kind of with that framing, you can start to understand there may be, it's actually a whole lot of, there's a huge amount of value in the tools we're writing beyond just the scientific value, which is also huge. Love the fact that, believe me over the past 15 years it's been awesome to see all the use cases of the tools that you put together. I mean, many of us have worked hard to put some of these tools together and it's been really satisfying to see people using it in diverse ways. But I think there's even bigger opportunities and even more opportunities for these tools to get used beyond what we're typically thinking. So I'm kind of using that pie data notion to describe that entire stack and the new things that are coming down the pipe I think all contribute to that. So for some that don't know, Anaconda really gives you this capability of portable environments. A lot of people talk about reproducible research and there's a lot of work going on in reproducible research. Anaconda actually solves with the Konda package manager some of the fundamental problems associated with that. Not all of them, there's still some that can be that are improving if you worked on, but some of the fundamental problems of dependency analysis and grabbing all the tools together and specifying them are solved so you can port your environment from one to another. So you can go from your desktop to your laptop to a EC2 machine, to a Google engine machine, to any cloud machine, simply. That's a lot of what we've been working on with Anaconda. Now a lot of people know Anaconda as a way I can just go download a bunch of stuff, get it working on my system off I go. But underneath is really this package management scenario that lets you deal with environments. So we're all familiar with the Jupyter Notebook, likely. Jupyter Notebooks are awesome, they give you this workflow you can see, but with every Jupyter Notebook you have what are the dependencies? What are the things it depends on? How do you get those? How do you connect those? Jupyter Plus Conduct actually gives you a reproducible work environment, something you can just ship to somebody and then get everything they need and off they go. Now there's additional things that are needed, data, maybe some services that need to be running and there's work to be done in that direction. And it's exciting to see kind of the work that's happening in the community around that as well. So that's what we mean by Anaconda. Now the rest of the talk, I'm going to talk about some of the innovations on that Anaconda stack that we've been working on and continue them in the direction of Blaze basically. It's part of what's the Blaze ecosystem. Blaze, Dask, Odo, Numba. But before I do that, I want to make a little bit of an aside on kind of NumPy. Fernando described the NumPy of my involvement in NumPy and I was sort of, I was kind of pulled into NumPy. My passion was SciPy. That's what I really got excited about was bringing an analysis library to people while I was a grad student using it. I was not a computer scientist, I was a scientist. In fact, NumPy has some of the problems it does because it was pulled together from other people's ideas and I did the best I could with the understanding I had. I know much better now how I might do it differently. But nonetheless, it was kind of pulled into it. But there were a couple of good things that came out of it. I think one of them was this D-type innovation. Before NumPy, Numeric basically had some magic lists and it had kind of broadcasting was done by a single while loop. It was sort of an artifact of that while loop, the broadcasting rules. They weren't really presented anywhere. So those are the two things in NumPy that the D-type innovation was one. And I think some, and I'm not sure that the full understanding of why that's an innovation is necessarily understood. Why are the key potential benefits of this D-type? And Fernando did a great job this morning of talking about kind of how D-types really add information about the binary data. But one of the use cases that comes out of that is that it turns imperative code into declarative code in a way that's really powerful, in a way that kind of lets you think about the problem differently. And I've seen multiple times in example after example at industry and client conversations where it's just flipped upside down. There's reasoning about the problem and turned hundreds of lines of code into three lines of code that they could just reason about more easily and it's even faster. So, and then D-type really should also provide a solid mechanism for Eufunk dispatch. Now it doesn't really yet, because Eufunks really weren't changed from NumPy. Eufunks in NumPy are really the same thing that was in NumPy. I mean, that was Jim Hogan and his invention along with Paul de Bois and Conrad, and Hinson and others who added to that. And put a little window dressing around it, but it's still based on the same thing. A little bit of, just a few buffer things were changed and Mark Wiebe has improved it since then as well. But I think the D-type, really what's connected to D-type should be a really solid dispatch mechanism for the Eufunk as well. I think that's one of the things that could be improved in the NumPy code system. But to kind of help understand that imperative declarative concept, I wanna just explain briefly those two concepts, the imperative declarative and then a function dispatch capability. It's not too hard to understand. So, I'll use a story to explain this. So when I first came to the Python world, I was a grad student at Mayo Clinic. I was working with analyzed data. I don't know if anybody in the medical imaging knows the analyzed format. I don't know if it's still around. So, you know, this is back in 1970s, the Mayo Clinic had put together a four dimensional CT scanner. Like it was, you could make movies of people's heart beating with the CT scanner. This is back in the late 1970s. It was amazing, right? Where'd they store all that information? I have no idea. It was sort of ahead of its time and being able to deal with the information coming from that sensor. It was pretty cool. And it kind of jumped started medical imaging analysis program there that continues to this day. And they had come up with an analyzed image file format to store medical imaging data. Well, I wanted to read it because it was everywhere inside the clinic and I wanted to pull it into Python so I could do things with it. So, I wanted to read it. So, the very first extension module I ever wrote was in 1988 called NumPyIO. And, you know, there's a story about how I only could do it because of what other people shared about their understanding as well. But, this was essentially a whole lot of F reads and F writes. What it did was give you an F read and F write so you could read binary data and write binary data. Kind of imperatively, you could load data into a NumPy array and write it out to NumPy array. Well, that was great. So, I could take a file format and read it in as I needed. But once NumPy sort of created this D type that understood how data could kind of map over all kinds of memory data, including little Indian, big Indian, kind of became a data description or data declaration language. If you look and Google for data description languages, you can find other examples of what D types are doing for memory and for disk. People have done this, have looked at this area in other fields as well. But once you create that D type representation over raw binary storage, right, then you wrap an array around that. Now you have an array and you can do slice syntax and field access syntax to instantly grab the data you're looking for. Just reference it. Just look at it. You don't have to read or F read or F write. You're just organizing a declaration of how the data is stored. And then you're just making method calls. You're basically doing simple abstractions on top of that. And then it can quickly slice and the computer does the work for you. And when you hook this up to a memory map, it actually is really quite nice. At least as long as you don't do too many calculations of memory and blow your memory up. But as long as you limit yourself to slicing and selecting, it works really, really nicely and very, very fast. I mean, so this is where NumPy examples can be extremely efficient because of this simple abstraction, which is much more powerful than I expected. I did not really expect that use case to come out because my mind was still stuck in the F read, F write when I wrote the D type implementation. But it was sort of the power of constructing the right abstraction, constructing the right pattern leads to incredible results later. So it's kind of one of the lessons that came from that experience of writing D type is you've got things for free that you didn't realize were gonna come because you spent some time really trying to think about the problem. And I remember the, trying to write D type. I remember the day I was sitting on the bed and I was thinking, I really should be able to generalize this D type thing. It's the PyRay desk or a numeric. And if you ever look at the code, it's really not much different than there. A couple of binary things stuck at the end. But I had to be backward compatible numeric. So I had to make sure that I could support all the numeric APIs that dealt with this structure. But I remember sitting there thinking, I should just make this a Python object. Now, if I'd have been a little bit more clever and thought, oh, I should just make this a meta type in Python. But if I'd have been that clever, we'd all be in a different situation. We wouldn't have the problem we have with D types today, but I wasn't. And there was nobody around who could kind of push me in the right direction either at the time. But nonetheless, we are in this situation right now where Python was in Python one, where we have the D type object as a class object. Just like in Python one, all the classes were a object. Kind of shoved into a single object. Then Python two, I think finally by Python 2.2, it was broadened so the types were actually Python types. So that's sort of the one idea that got, once you organized that correctly, you could actually do nice things. I think the other thing that could have come out of organizing the type system correctly at the time would have been modifications to the Ufunk system, where I didn't make any modifications really other than insert a few new types and then expand, introduce some arcane template language that's kind of make it fast to write all these different loops. And before I knew really what a template language was and I think it's before some of them even came out in Python. But certainly today, it could have been done a lot potentially differently. But just from how do you make a bunch of Ufunks? Really the type system helps you make Ufunks. And of course this is a very simplified, it's simplified because it assumes you've got a signature of everything you want. And if you don't, you just raise an error, I suppose, I didn't have the error raising here, it would just raise a key error if you don't have it in your function map. But it gives you the general idea of dispatch, I think very simply, which is you take the arguments, take the type of the arguments, the D type of the arguments and you can build a function map and call the writes you specialize according to the specific types of the arguments. That's essentially what Ufunks are under the covers. There's a lot of more code to basically make sure that you call these functions, the things that are registered are actually loops over N and you're mapping multidimensional maps to a one dimensional kernel. That's, there's code to do that. But you don't, that's sort of all extra sauce around this basic Ufunk mechanism. And of course you have casting. You know, what happens and that's where, that's where multiple dispatch and this kind of another dispatch method mechanisms get, like, okay, what do I do if I don't have it registered? Do I, you know, do the super type, I go to the sub type, which direction the tree do I go? And there's all kinds of, there's actually no, that I'm aware of, no concrete, this is the way it always should be. There's sort of an open, it's an open question you can choose and there's some corner case and you just kind of pick one. But there are some implementations of this. In fact, we're using an implementation of multiple dispatch in several areas of code. I actually haven't done the, to know exactly, Matt Rockman could speak more to this. We're using one of his implementations I believe in both Blaze and Odo. So basically I want to kind of, so going back to the story of, so kind of take that as a recognition of, hey, you're here to build abstractions. That's actually a good idea. If you build some good ones, you can actually affect people for a long, long time. And if you have leaky ones or ones that are slightly wrong, you'll also affect people the other way for a long, long time. So it's a good opportunity to kind of have, to get the best ideas you can up front and then see what we can do to build them. So I want to talk about in the spirit of good abstractions and particularly around the abstractions of how do I take the data and kind of make automatic databases easily around data. I'm gonna talk kind of about why Blaze and our thoughts around there. These slides are actually from Peter Wang. So I'm gonna go through them very quickly. This is kind of a way he thinks about the final result that I want to show you. So in the beginning there's the brain, and most of us have one. Most of you have one. Sometimes I wonder if I do. But then you have data and we kind of pencil on paper and we just analyze your data with our brain. Typically using some math, if we're, you know, if we get a little more math then we spend a little more time. If it gets big, the math gets hard, right? So we then go, okay, this is too hard for my math. Too much, maybe it's not really hard, just a lot of it. So I put a computer in the way. Now I want a computer to do the math. Now how do my brain tell, and I have to have somebody to tell my brain to tell the computer what to do about the math. So I have programs that are created that do all that to tell the data how to work. And then I get general purpose programming. It's typically the way that a lot of that is done. And we have kind of the computer closer to the brain and then the computer does things to data. But then there's a sort of a lot of other things you can do with that paradigm. You got data, you can make websites, you can make Minecraft. You can do a lot of things with that nice little infrastructure. So another approach is to move the computer kind of the low level analytics closer to the data. There's not in a physical sense, but in a logical sense. Then you have an analytic system and you have a general purpose domain specific language. You have a query language to map to the brain. So it's a lot of dist, it's more distance to the computer. You know that R, it could potentially be considered one of these SQL database paradigms. Python plus kind of pandas or Python plus numpy could kind of be considered that. And then, so you could kind of have a different domain specific language for every kind of thing you want to do. You have one for web programming, you have one for game programming, you have one for analytics. So one of the things with Blaze is trying to think about, so we have these, we have a compute, we have data, we have brains. How do we organize them and create abstractions so that we can separate them and then combine them as needed, maybe kind of substitute one for the other? And how do we separate abstractions, create separation of concern and bring them back together easily? So that was one of the motivations around kind of the Blaze organization. So the brain can basically map to expressions, data is about metadata, type systems around the data, and the runtime is the computer. So kind of we separate those three things into three logical areas, then we can start thinking about those abstractions separately and potentially bring them together more easily and get better code reuse, get better collaboration, make sure that we're not kind of all having to reinvent the wheel in our particular silo. Only that's the benefit of collaboration is we have limited time, there's a lot of people, we have limited time so if we can collaborate and use each other's work, we get a lot, we get done things a lot faster. That's actually been the thing that's motivated me about open source the most. The day is basically, I'm actually, I love markets, I know we're here in Berkeley and I'm not sure how other people feel about that, but actually I'm a true believer in markets for coordinating human activity, I love them, I think they're actually very important, it's a critical thing, but I also love open source, I don't see them as incompatible, I love open source because I see them as people coming together to share ideas. So I want both to kind of work. And people sharing ideas and then reusing each other's ideas really at the heart of what led me to spend time on NumPy, spend time on releasing SciPy packages, just let people reuse code that's already been written. Now, that doesn't always work because people have slightly different framings, they have some different ideas, they have to, they want to approach the ideas and that's fine, that's actually powerful and robust when you have lots of different ways to approach things. But when you can share, it's awesome to share. If you can create a protocol, create a standard, a shared abstraction, it's really awesome. So what do I mean by these expressions? So expressions might be things like join, group by filter, selection, power, operations, kind of the things you do around your data. And then the compute at this level can be things like pandas, NumPy, maybe KDB, Spark, Mongo, Cassandra, and Paula. And then the type system, the metadata is things like data shape or D type, the shape, maybe some other metadata around that, like the labels or whatnot. So Blaze started as kind of an ambitious project, kind of a marketing really to try to grab people who could organize around this idea and get people who are interested to collaborate with us. And it was very ambitious. The goal was basically, let's build this, right? Let's build the right collection of abstractions for this, right? Which is like, okay, that may take us a while actually, maybe it might take us a lifetime to really, especially grab all the real information out there. But what can we do? Over the course of fits and starts and different people doing different things, lots of exploration, I've actually kind of come up with an ecosystem around this idea. And with so many interesting ideas kind of merging out of it. Dynes come out of kind of the improvements to Dynes. Dynes was something that Mark we've started before Blaze, but we've come, a lot of improvements to Dynes happened because of our efforts around Blaze. And then a Blaze library itself, which includes a server and a client. Odo, which is data migration and copying. Dask, which I'm very excited about, which is kind of a parallel runtime calculation engine, which is now its own project and kind of Steam is behind it. It's really nice. Then some storage concepts as well. Francesc was working on BLZ and then he's kind of modified it to B-calls. But kind of, some of those same ideas were inherent in many of the things we were trying to do. And then Castro is another thing all around Blask, which is another idea around the ecosystem. And then the data shape is one of the important ones I want to focus on because it's kind of the, it's rather just a data declaration language, just a way to describe data. One of the things I was very happy with with D-type was that it was a way for people to commonly express their type system. At least it's a language. Now it's unfortunately kind of a, it's like English. It's got like lots of homonyms and lots of ways to talk about it. So it's a very difficult language to translate. We might have been better off with a Spanish-like D-type system where everything is actually the same. But nonetheless it's people are using the same commonalities, language. The data shape is one we've been using. You saw a little bit of it with Dynes. Dynes uses the data shape or at least a subset of it. And then Blaze also. So Blaze really, if you think of what the Blaze library is itself, it's basically an expression library. It's a generalized expression library sitting on top of runtimes and data. It's basically something that sits on the expression side, on the brain side of that triangle. And it needs type system and runtime from somewhere else. So for us, you know, here's another way to write that tri-unit, that tri-force graph. You have the expression side, you have the runtime, you have the data, metadata. And kind of, if you separate those concerns and then bring them together for an actual computation you can have a lot more flexibility. Most of us are used to separating the runtime from data. But kind of the expressions is tied to the runtime pretty much universally, usually. The SQL was one approach to bringing out kind of an expression language that could be behind multiple runtimes. So there's prior art here for sure. So the Blaze library, how much time do I have? I've got like four minutes, right? So excellent. So I've given you what we need to know. Kind of the why, the what, what we're headed for. And now I'm going to just rifle through. There's actually a lot of capability here. I think one of the things that, you know, Peter and I have looked at each other over the past several months. We've been running a company, starting a company, kind of finding funding, looking around for everywhere. We just did receive a bit of money so we can do a little bit of broadcasting of what we're trying to do. And so we realize we have a lot of stuff here that's actually not, you know, we haven't really pushed very far. You know, we've pushed kind of some of the ideas and some of you've heard of the ideas. There's a lot of stuff here. Some people are starting to understand that or re-look at it. So Blaze basically gives you a wrap around any kind of data. You can look at CSV, SQL, Mongo, JSON, S3, get an expression graph. You can do things like select columns, filter, operate, reduce. And it builds up a computation structure that then pushes to the particular backend that it's with. Blaze uses the data shape. Data shape is a type system that lets you, you know, you can have variables and strings, variables and types. And you can go to the web and read all about what's there. It's, these are works in progress. They're certainly not, you know, none of this is 1.0. It's all ready for collaboration. It's all open source, all open to discussion. It's been, really appreciate the funding from Xdata. The DARPA funding from Xdata is really what allowed us to push a lot of this into the world. Here's some examples of data shape and I'll make these slides available later so you can see kind of all of the different things that I'm including here. Blaze server is really what lights up your dark data. Blaze server lets you sit basically a simple HTTP server with a description of names and whatever you want. It could be files, could be directories of files, could be SQLite, could be whatever. Now you have a server, a common interface with including a query language that you can talk to this server with and send information to it. So it gives you a way to normalize your interactions across all your data. There's a client and there's a server capability. Obviously we're focused on the client. Our focus, you know, the compute backends for Blaze really include Python, Dine, Panda, Spark and Paula, Mongo, Dask, various degrees of capability. So, you know, right now it's still a work in progress so your mileage may vary on a particular stack. Our efforts have been really around what I call the Pytata stack. Our back end of choice and our back end of interest is the kind of Dask and then an array library like Xray or Pandas or NumPy. That's really what we're trying to focus on optimizing. Yeah, we'll support Mongo, yeah, we'll support SQL. Our focus is really to make sure that stack works really, really well. Ideally, you know, we're getting to the right once deploy anywhere but in practice today it's more of a, you know, reduce your technical debt because you can decide, you can write things in Blaze and then pick your back end without having to rewrite your code. Ultimately you're gonna have to pick a back end that optimize, you know, the performance, the way you want it. And so once you get started, you're gonna have a little bit of technical debt because not every back end's gonna support every expression. But in Blaze, the goal is to have every expression. If it's in one back end, it's in Blaze. So just try to move your back end, you may have errors because your back end doesn't support those expressions. So because of that, and because of our focus, you're gonna have to copy data. And so Odo was a library for copying data. I'll let you read about that online. It's really cool, actually. A lot of people are using it. Basically it's a network and you can basically copy from one to another, from Deeth, from Iris JSON to a Hive database, you can really easily go back and forth between one data library to another. Very easy, it's being used actually by several people. Dask, I'm actually gonna let Matt talk about Dask tomorrow. He's gonna go into some detail about it, so please listen to him or, and there's also videos online to talk about Dask. I highly recommend checking out Dask. It's very cool. It basically is a nice abstraction that lets you do parallel computing. And then there's tools around it, like collections that build graphs, and then there's tools for executing those graphs. And it's decoupled in a way that there's improvements gonna be made on all sides. It's a really nice tool. And then Numba, I've talked about a lot. If you haven't heard of Numba, please go look at it. It's actually pretty cool. It brings a lot of the capabilities we want out of a head of just in time compiling for Python, makes you able to write fast code quickly. And I will just point out, because sometimes people aren't aware that CUDA Python is in open source Numba. You can do GPU programming in Numba source Numba. It used to be in Numba Pro only, but it's been for about a year and a half, completely free in Numba. We just recently, a month ago, released the vectorize and parallel thread computing of vectorize in the open source Numba as well. I think that just came out a few days ago in the next release. So more and more, more and more things are going into open source in Numba. So I will basically conclude by saying thanks to all the people that makes this possible. The DARPAxData program, Chris White, Nao Wei Chen, there's continued support, have not only helped what I showed you, but also what I haven't showed you, which is Bokeh, which is a tremendous visualization library, and there's videos online you can hear about that. And then also investors in Continuum and clients and customers in Continuum who have helped develop this and helped develop these tools and continue to do so. And I also like to shout out to the PyData NumFocus volunteers. NumFocus is an organization whose purpose is to be a foundation for the creation of accessible computing. And it takes a lot of volunteer work to make that happen. And a lot of folks have stepped up to make that PyData ecosystem really work. And I wanna thank them for their efforts as well. And thank you, and I'll be open for questions.