 Well, for the people that weren't in the room for the previous talk, Alexander Kondelman is going to talk this time about D-Wave Software Development Kit. He was also delivering the talk beforehand because we had a spontaneous mix-up where one person didn't show up. And he's a mathematical software developer at D-Wave Systems, which is a quantum hardware company based in Vancouver. And he's also a passionate Pythonista and has developed a lot of the open-source software that is part of the D-Wave software stack and that he's going to be talking about now. Thank you. All right, so before we get started, a lot of shuffling. Who was not here for the talk just previous to this? Can I just see a short hand? Okay, great. I see that we're sort of moving this way in the room as people come in. Okay, great. So then just the really short version. My name's Alex Kondelow. I'm with the Applications Development Technologies and Tools Group at D-Wave, which is a very long way of saying that I write the tools. In this talk, I'm going to be talking more about our software development kit, which is something that I work very, very closely with. Previously in D-Wave, before I started working on our SDK, I could be thought of as a human compiler. My job was to go to individual customers and ask them what they're trying to do and then write the code or help them write the code, most often write the code for them and then give them credit for it to actually solving the problem on the system. But like every software developer probably in the world, I love making my own job obsolete. And so from that I was generating a lot of tools and utilities that I was using over and over again. And we thought, hey, it would be really, really great if we could share these with everybody else and also if I can open source it so I don't have to write every line of it because I'm also lazy. So I'm going to be talking about our kit today. Yeah. So this slide was actually from my last talk, but I'm just going to mention it again. So for those that are new and who have just come into the room, when you're solving problems with the D-Wave system, the thing that I want you to keep in your mind is this landscape metaphor. So if you imagine every solution, every possible solution to your problem as a point on a landscape, some point in like a park or something like that, you can imagine good solutions as being very low points, low to the ground or underground and bad solutions being high in the air, mountains and valleys and ridges. And what you'll often find when you have a problem this way is that if you have a particular bad solution say and you go one bit flip away from it, you know, having distance one away from it, it's still a bad solution. And so in this way you get these sort of ridges and valley and mountain tops and these sort of big rolling hills and often then when you have a good solution and you go one bit flip away from it, you find that maybe it's not as good of a solution but it's almost as good of a solution and this way you get these sort of valleys and they go along certain fault lines of bit distance and it creates these sort of very interesting landscapes that you're trying to navigate with. So specifically though there has to be a mathematical underpinning to all that philosophy and flowingness and art that I was just talking about and the mathematical underpinning is this thing called a binary quadratic model which has an equation defined like this. And so when you're working with a binary quadratic model, you have a solution vector v which has to be a vector of binary variables and so by binary I don't mean zero one in this case, I mean two valued. So zero and one is a possible binary state but also negative one one and depending on what your problem is or what your solution is, one of those two bases might be more or less convenient. So you have to first express your problem as the solutions to your problem rather as one of these binary vectors. And then once you have the space of solutions with your binary vectors, you have two controls that you have over this solution space. The first one is that I can bias an individual variable or qubit's value. It's propensity to be one or zero. I can say that I very strongly want you to take the one value or I very strongly want you to take zero. I can say that I don't care or I can say I weakly want you to take one or zero. And that's represented by this a term, this b term, this linear bias associated with each value. It's a per variable control. The other type of value that I have accessible is a quadratic bias which is represented by this a term. So quadratic biases influence the individual qubit's likeliness to both be up or both be down or be opposite or equal. And in that way, this is the only two controls I have, but if I can represent my problem as a solution, a ground state, a minimizing energy to this polynomial, then I'm good to go. That's the game for quantum computing. And the ocean software stack is fundamentally built around the notion that I want to get a problem from your head to this representation and then from this representation down to a quantum computer. So one thing that's worth mentioning is that that binary quadratic model is very large and very general and very mathematical and it's nice. It has wonderful things like the biases can be just real valued. That's lovely when you're trying to do proofs, but when you actually sit down to a quantum computer and I have one bias of 0.1 and another bias of a trillion, things become a little bit sticky, especially when you're dealing with, you know, currents and voltages and capacitance and all these fun things. You can't do stuff like that. So a quantum machine instruction is a binary quadratic model with some restrictions, some constraints, some limitations. And specifically those limitations are that our linear biases, those were the a's before, which we call h's in this context, are limited from negative 2 to 2. This is a normalized value. There's no unit associated with that, but it has to do with, we just normalize it and it has to do with the noise capacitance of the system. The other value that we have is our b values, our quadratic biases, which are represented by j's here, which can go from negative 2 to 1. So again, there's just this normalized value that we want to work with. And that limitation is not so restricting because we can always, these things are normalized, so we can always just rescale our problem. But it does matter in that you can't have some biases that are in the millions and other biases that are in the, you know, 0.1s. Because if you normalize that down to negative 2.1, what you'll find is those 0.1s get very, very, very small and therefore are hard to see from the processor. So there's a relative level constraint. And the other constraint that quantum machine instructions have is it has a particular graph, which is defined by the hardware. And this is the way the qubits are actually laid out on the system. So our system right now is laid out in something called a chimera graph, which I won't show you here because it's a little bit complicated, but it is the current system of our graph. And then as some of you may have known, there's another graph that's sort of floating around out there in our documentation called the Pegasus graph, which is even more connected than the chimera graph. But the way to think about it is this is not fully connected. Not every qubit can talk to every other qubit. Some of them are restricted. So how do I program with BQMs? What is the way that if I want to get started on the DOA system using this to solve my problem, how do I do that? So the way to do that is the ocean software, which is the thing that I work on. Ocean software kit, the total ecosystem, are a set of tools for solving BQM problems. They're mostly written in Python, although for all of the really heavy computational steps we use C++ and we wrap them in Python. And almost all of it is open source and available on GitHub because we really, really, really, really want y'all to come and help me write this because I'm only one person and I need more people in the ecosystem. So very selfishly open sourcing this thing. OK. So I just said a bunch of words, but how does this thing fit together? So the basic flow, as I mentioned, when you're solving a problem on the DOA system is that you start off in your problem domain, which might be graph theory, might be constraint satisfaction problems, or it might be some other domain that you're interested in, machine learning, for instance, or material simulation. So the first thing you want to do when you're going to solve a problem on the system is you want to translate your problem, you want to represent your problem as a BQM. So you need to get from your problem, your NP-hard problem, or your whatever problem, to BQMs, which is also in general minimizing your NP-hard problem. So there's a polynomial time transformation. So you need to find that transformation. Once you have a BQM, you need to get it down to a quantum machine instruction, which as I said is a BQM with some extra rules. And so the ocean software stack is built around this model. So this is sort of the conceptual model of the BQM. And what you can see is up at the top we have applications. So we've highlighted two here, which is optimization, often these graph theory style problems, and constraint satisfaction problems. The way that those come in is that we have, as I said, you want to get those to a BQM. So we have these mapping methods. So we have graph mapping methods, and we have constraint compilation methods. And in the future we'll have more of these methods for getting from different domain areas down to a BQM, which is represented as this uniform sampler API. So this is saying that once you have a BQM, you should be good to go. If you're not interested in the details of how your BQM gets down to a cubo, you shouldn't have to know anything about that. You did it. You got to the finish line. You got a BQM. You should be good. If you're interested, you have to get from your BQM, your uniform interface, down to different samplers, different things that might solve your problem. And this might be the quantum system, or this might be a classical system. This might be some person with a piece of chalk writing it on a whiteboard, or this might be some goblin flipping coins in a closet, or whatever it is. Something has to give you back answers to your problem. And those individual samplers, those things that solve BQMs, use compute resources under the hood, so CPUs, GPUs, quantum processing units, whatever it is that has to solve your problem. So this is what the ocean stack looks like. So our ecosystem, the ocean SDK, actually includes a large number of packages, which I'm going to go through sort of one by one very quickly here. But this is what the overall picture for our stack looks like. And you'll notice on the side that we have those mapping methods, this uniform sampler API, and compute resources. So the first package that you need to know something about is called Dimod. That stands for discrete models. Everyone always asks what it stands for, but I'm not supposed to say that because that actually kind of is a meaningless word. This is one of those cases where it's just the name kind of stuck and I'm the one who named it and so everyone's stuck with it. But basically what this thing does is it provides an object that represents your BQM, your abstract problem. And it also defines an API that samplers are supposed to have. So samplers being the things that solve your BQMs that return solutions for your BQM. So starting at the bottom then, we want to access these individual compute resources. So this Dimod object is just sort of present throughout the stack. That, as I said, defines the main objects, but now we're going to start building up from the bottom. So if you want to access the QPU, you need to use the D-Wave Cloud Client. So this simply handles communications with the QPU. It includes another couple things like it stores your token, which is your authentication locally so that you can access the QPU. You don't have to keep providing it over and over again. You don't need to sign in to some web front end or anything like that. It also provides a simple command line interface so you can test your connection. You can ping the system and make sure that you have a good connection. But the Cloud Client is very, very minimal. It's fundamentally just designed. It's the REST API like on your system. It's trying to be as small and as bare metal as possible. So we need a nice interface. We need an abstract interface that we can use for lots of different problems. And that's what our D-Wave system package provides. What that does is it represents the QPU on your system as an object, as a sampler object that you can use to solve your problem. There's another package here called Miner Miner, which as I said, getting from this abstract BQM down to a quantum machine instruction is a hard thing and Miner Miner helps you do that. The details of that are quite complicated, but I would love to talk to anybody who's interested in the embedding problem or different graph theory problems after the talk. Once you have this uniform sampler API, you might ask, well, what if I can solve my problem on the QPU? Can I solve it on a classical system? Would the classical system be faster than solving it on the QPU? Or would it be slower? So we provide right now two other samplers that are available. We have D-Wave Neal, which is a simulated annealing sampler. Simulated annealing is a classical algorithm that's very similar to quantum annealing in some ways. And then we have a taboo algorithm, which is an implementation of taboo search. These are both written in C. They're relatively performant, but nobody's going to be winning benchmarking competitions. But if you are interested, if you have a simulated annealing implementation that's winning benchmarking competitions, we would love to get it into our open-source ecosystem. And the other thing is that we'd like to expand this in the future. We want more classical samplers in our ecosystem because we want to be able to benchmark our problems over a whole variety of instances. We're not interested in hiding the QPU. We're interested in having it compete with the best of the best. Once we have that uniform sampler API, now we want to start solving actual real-world problems. So one of those types of problems is a constraint satisfaction problem. So constraint satisfaction are things like, I have this set of variables, and I need A equal to B, and B not equal to C, and C less than four, and four, you know, that sort of stuff. If you can express your problem that way, we can represent it as a BQM, and we'll do that for you. You just need to understand BQMs. You just need to understand problems in your own domain space, constraint satisfaction. This is what passes for applied in the ocean software stack, which I understand constraint satisfaction solvers are quite low-level normally. The other one that we have is d-wave network x. So that solves graph theory problems on the QPU. So if you have a maximum cut problem or a vertex cover problem or a minimum maximum independent set problem, those sorts of things, we can represent those on the QPU without you needing to know anything about BQMs. You can just solve your graph theory problem on the system. Actually, I don't know. How many of you have used network x? It's a Python package. Can you show a hands? Yeah. This is just an extension of that, where we're using a known API to get into the QPU. And this is a fundamental design notion. We don't want to reinvent your domain area wheels. We want to just, you know, plug into it so that you can seamlessly use the QPU. And finally, the package I'm going to mention just very briefly is d-wave hybrid, which doesn't really fit exactly in this stack. It's used to solve problems, but it also just makes use of the sampler API. And my colleague Radimir here will be talking about that quite a bit in the next talk. Okay. So I've talked a couple of times, but just to remind you what the QPU programming method is. And if you have to go through all these steps to solve your problem. So first, you need to translate your problem into a binary optimization problem. And so what I mean by that is if your problem has real-valued variables in it, you can't do that on the QPU. You need binary variables. So you need to represent your problem, maybe with different encodings, or maybe you're interested in going greater than one or less than one, that sort of thing. Once you have your problem in the binary space, you need to define your BQM function, which is that energy equation that I was describing, that polynomial that you're trying to minimize. Next thing you have to do is put your coefficients into a matrix form. So this is, you have to represent that BQM as something that the QPU can understand or another sampler can understand. You then run that problem, that matrix through a sampler, whether it be the QPU or simulated annealing or any other classical resource. And then finally, you have to interpret the results. So what it's going to return to you is an assignment to that vector. It's going to say that variable one should be spin up and variable one should be spin down and variable three should be zero and variable four should be one. And you have to then interpret those solutions. So that defines the ground state of your polynomial, but what does that mean against your original problem? So just to make this a little bit more concrete, I'm going to give an example. So say that you have a network of pipelines. And the question that you're trying to solve is I need a set of junctions from which we can monitor every pipe in the segment. So I need to have a sensor sitting at some subset of the junctions, preferably a minimal subset because I don't want to spend a lot of money, such that I'm adjacent to every single pipe. So for those of you who have some graph theory background or a mathematics background or really probably most of you, know that this is a vertex cover problem, a minimum vertex cover. So what you want to do is you want to find the set of variables or set of nodes rather that are adjacent to, such that every edge has at least one node adjacent to it that satisfies this property. So great news, this is binary. My nodes are either have a sensor or don't have a sensor. So I've done my first step. And the next thing is I need to represent that as a BQM. So what I could do is I could write a problem in binary optimization form. I could translate that to a cubo. I could simplify down that cubo matrix. I could go through all of these individual steps. But A, that's kind of mathematical. And B, it's not very elegant. So what I would do instead is I would go to our ocean software stack. I would go to our documentation and I would search for maximum or minimum vertex cover. And something would come up. In this case, our D-Wave network X package. So this is what the program to solve that problem looks like in ocean. So I have to import some stuff, go figure. And specifically I have to construct a sampler object. So I'm going to walk in front of the thing, which I'm not supposed to do. I'm not supposed to leave this area. But you can see that we have to instantiate a sampler object. So that D-Wave sampler call there makes contact with the QPU, gets a list of all the solvers available. It uses your token to see which QPUs you have access to. It ranks them by which one is least busy. And it returns that handle to you. This embedding composite thing, that's what takes problems from an arbitrary structure down to one that the QPU can understand. This is the compiler that takes your arbitrary BQM down to a quantum machine instruction. So now we have a sampler object. And then all we have to do is define our graph. So this, you can take my word for it, is the graph that was represented in that little pipe problem I showed. And then you just solve it. So you call devonemercx minimum vertex cover. You provide the sampler that you want to use, in this case the QPU. And it will return a vertex cover for you. So if you want to find more information about ocean, we have read the docs. It's all, as I said, open source. So read the docs is sort of, I think, one of the most common ways to represent it. We have it indexable. There's a whole set of documentation. There's piles of examples. All of the source code is available for all of this. You can go to our GitHub account, and you can look at the raw code. You can see all of our different packages, and some other ones besides. Stuff that's in Ocean. Ocean doesn't include all of the open source the UAV has. There's a couple other packages in there. And a reasonable question is, okay, what if there isn't a tool for my application? So as I said, we have some graph theory tools, and we have some constraint satisfaction problem tools. And in the future we'll have others, but right now that's sort of what we have. So the thing that you can do is, as I said, you can represent any most problems as a BQM. So you could just develop that BQM yourself and then just use the sampler directly, that sampler object, the QPU, or say simulated annealing directly. Or, what I would much prefer, is you can develop the BQM, you could write a reusable tool, and then you could make it as a pull request or maintain it yourself, and then use that to access the system. And therefore you could expand the set of problems that people are asking questions about, like, can quantum computing help with this problem? And other people can come in and say, like, hey, I have this better solution that uses some obscure GPU cluster, or hey, actually I think you could do your QPUs to call better and get involved with the thing, get involved with the project. So I don't think I need to describe what a pull request is to this group, but anybody can make a pull request to GitHub. We have links for how to actually do that if you've never done it before, which maybe some of you haven't, I suppose it's possible. But we're very active on GitHub, we're very active in merging pull requests and engaging with our customers or with people who are just interested in the system. And finally, if you're interested in installing the thing, this is very simple, it's pip install d-wave ocean SDK. That'll get you all of the packages in the SDK, the latest stable version of all the packages. Sometimes if you want the latest and greatest, individual packages sometimes can get ahead, but it's not necessarily stable, so we keep this one as stable as possible. And as I said, we have our GitHub account, you can find plenty of stuff there, or you can go directly to docs.ocean.dos.com to see all of our read the docs and get started on jumping in. And that's it for me, I think. All right, so I think we have maybe like seven minutes for questions? Ten minutes. Ten minutes, great. Do we have any questions? Sure. Yeah, so the biases in your QPM function have some limited range. Yes. Well, the next, is this the physical implementation of the computer? Will this improve in the next release of the quantum computer? Yeah, it's great. All right, so the question was, so as I pointed out, our quantum machine instruction, there's limited range associated with the biases. And so the question is, is that a hardware limitation and will that improve with the next version of the QPU? So the answer is yes, it's absolutely a hardware limitation. And yes, it will improve with the next implementation of the QPU. The detail that gets a little bit, to just expand on that a tiny bit, is that because these are normalized ranges, the actual ranges might not change the ones that are available to use the programmer, but the quality of solutions might improve. So there's sort of a noise limit associated with the system where below some threshold value, the QPU can't really detect the biases. So if you have a bias of 0.0000001, the QPU is not going to know what to do with that. But as the QPU improves, we're going to, you know, that'll get closer and closer and more accessible. And then the only thing that might change these individual visual ranges is if we find that we have significantly more control on say the linear biases than the quadratic biases, you might see one range expanding and the other one staying static, which is actually how we got to this sort of strange negative two to two rather than one-to-one model. So maybe you could comment on how many bits of precision are we going to, are we going to have current cut? Yeah. So the question is how many bits of precision do we have now versus the future? So there's two different questions associated with that, which is how many bits of precision are accessible to the QPU? Like if you're trying to detect a signal, how many bits of precision do you have? And I don't have the exact number in front of me, but I believe it's about 0.01, the number that's detectable by the QPU where you'll be able to distinguish it so in this normalized range. But the question is then for a real-world problem, what should I start to get worried about? And so in that context about 0.1 is about the point at which like when you have big complex problems with complex energy scales that you start seeing problems. But depending on your exact application, it can actually get quite a bit smaller or quite a bit larger. So the range that you have for coefficients and if we do a grid search or a grid search, how many instances of a QBM problem we can have on this system? Sorry, could you ask the question again? So we have the coefficients which are real values that are limited, they're limited range. So depending on the precision, how many instances of the QBM problem we can have if you do a grid search for A's and B's? I'm not sure I know offhand. Yeah, so the question was given that amount of precision if you're trying to... Yeah, I'm not actually even sure I understand the question. Maybe I'm just... I understand. The question is how many problems are there theoretically? Oh, how many problems are there on the system? This grid range... Sure. So there are on the current system we have 2048 qubits and 2048 times four couplers, whatever that works out to be. So if you have 0.01, I don't know, very big number, but I'm not sure exactly. Yeah. Any other questions? Sure. Do you have any comparisons with classical Fujitsu and Hitachi annulars that are kind of available on the market? Do you know anything about it? Yeah, so do we have comparisons with some of the other annulars that are available on the market? So Fujitsu I think is the one... Hitachi. Yeah, and Hitachi. I do know that... So we have a whole benchmarking team and I do know that they do have comparisons to those. I'm actually not sure what the state of our published work on that is and I'm not involved with that project anyway, so I'm not sure off-hand. Yeah, so I don't know off-hand. How many samplers do you have? How many samplers do we have? Classical samplers, do you mean? Yeah. So right now we have three. So as I said, we have simulated annealing. We have taboo search and we have another one called QB-solve which is a different form of taboo search. And then obviously the QPU sampler. What kind of problem cannot be solved with the BQM? Yeah, so as I said, you can represent any NP-hard problem as a BQM. I assume that there are... I mean there are complexity classes above that that probably you would not be able to represent as a BQM. So I don't know of any off-hand. The other point that's worth mentioning is that while you can represent any NP-hard problem with a BQM, there's a lot you wouldn't want to. So some of them just the number of variables, the number of qubits essentially that you would need to represent the problem grows, say linearly or quadratically with the size of your problem, which wouldn't be a very good use of that representation. So a good example of that actually is factoring, which everyone would love to do on the QPU. We get asked very often with the largest number that's been factored on the QPU. It's about 18 bits. But basically the number of bits that you would need, that the number of qubits you need relative to the number of bits grows as a square. So that's not so great with the size of the system, the way it's growing. Sure. Yeah, the claim is not that we solve all NP-hard problems or anything even close to that. The claim is that you can represent NP-hard problems with a quantum machine instruction which can be solved on the D-way system. Yeah. Yes, that's a good clarifying question. Yeah. So maybe a question, you hinted that even classical algorithms were improved actually by trying to translate it into a quantum problem. So maybe can you elaborate on that, like what kind of improvements were made? Sure, yeah. So the question was, I had mentioned briefly earlier that just translating some problems to a BQM, you can see an improvement relative to what you're doing before. And the question was, do I have any examples of that? So yes, in an early collaboration with Google, they were doing, I forget exactly what the machine learning task they were doing is. I think it was some sort of speech recognition task, although I'm not actually 100% sure. But basically, they were representing their variables with real value variables. And by moving to discrete values and in an attempt to map to the BQM, they were able to see a big improvement. The other thing is that there's a lot of research, like because so many people are competing with you, there's whole research groups at other universities and companies and things that are built around trying to beat us on BQMs. Some of these solvers are very, very state-of-the-art. And so you can sometimes, if you're in a domain area that doesn't have state-of-the-art solvers built for them, just moving it to a domain that does have state-of-the-art will get you pretty far. And we have a lot of tools that are designed to get from other domains into ours relatively easily. Sure? Do you have an easy example of a problem with BQM that does not yet run on your... An easy example of a problem that does have a BQM that does not yet run on the system. So there are a lot of problems for which the scale of the problem is just such that you can't get it down to... So there's, for instance, some scheduling problems that we've collaborated with some other organizations where they have... It's sort of natively a BQM problem, but they have millions or even trillions of variables in them. And so at that point you get into the concept of decomposition, which is where you're using the QPU to solve sub-problems for this larger problem where you're trying to reduce that problem down to some latent space that you're using the QPU to solve. But for some of these problems, they're just so large and so complex that, like, yes, we can use the QPU to address them in the sense that, like, you can just let the computer run, but you're not seeing any significant improvement because the size of the problem is so large and the latent space the QPU can solve is relatively so small that we can't yet access them. But I don't know of any BQMs that have a minimum number of variables that are larger than, say, the size you can fit on the system. The largest complete BQM, so that is an all-to-all connectivity that you can fit on our current architecture is 65 variables, but depending on how sparse your problem is, you can get up to 2048 variables onto the system. How many variables each variable can couple to? Yeah, so on the system, the Qubits are each connected to eight other Qubits. Okay, unfortunately, we don't have any more time, so let's thank the speaker.