Podcast | Enterprise-Level Quantum Coding - with Classiq

Writing code for quantum computing always involves some layers of abstraction. Learn about QMOD, a new language that makes it easier to create working circuits and comes with some solid working use cases you can try out. Classiq makes QMOD available within its enterprise-level development tool, which you can now use for free (for non-commercial applications). Join Host Konstantinos Karagiannis for a chat with Amir Naveh from Classiq.

Guest: Amir Naveh, Classiq

The Post-Quantum World on Apple Podcasts

Quantum computing capabilities are exploding, causing disruption and opportunities, but many technology and business leaders don’t understand the impact quantum will have on their business. Protiviti is helping organisations get post-quantum ready. In our bi-weekly podcast series, The Post-Quantum World, Protiviti Associate Director and host Konstantinos Karagiannis is joined by quantum computing experts to discuss hot topics in quantum computing, including the business impact, benefits and threats of this exciting new capability.

Read transcript +

Konstantinos Karagiannis: Writing code for quantum computers always involves some layers of abstraction. Learn about a new language that makes it easier to create working circuits and an enterprise-level development tool you can use for free in this episode of The Post-Quantum World. I’m your host, Konstantinos Karagiannis. I lead Quantum Computing Services at Protiviti, where we’re helping companies prepare for the benefits and threats of this exploding field. I hope you’ll join each episode as we explore the technology and business impacts of this post-quantum era.


Our guest today is the cofounder and head of algorithms at Classiq, Amir Naveh. Welcome to the show.


Amir Naveh: Hi. Thank you for having me.


Konstantinos Karagiannis: We’ve had Classiq on. It was over two years ago, so it’s about time you guys come back, and we’ll get to why. But can you tell us about how you found your way to quantum?


Amir Naveh: I was into physics from high school. I was in the Physics Olympics. That was a long time ago. Then I was in the Israeli Defense Forces, doing everything from algorithms to physics to satellite engineering, all over the place. I remembered a bit of quantum physics from the time I actually learned about physics formally, and we were thinking about forming a company, and we were going to quite a lot of places — AI and computer vision and brain computer interfaces and a lot of different ideas me and my cofounder had.


Then Yehuda, who is also my father, was working at IBM, leading one of the quantum software teams. At some point, we started talking with him about quantum software, and it just felt like the right thing to do, where you can build a big company in a technology that’s not quite there yet but is going to be there in a few years, which is exactly the right place to build a big company. From there, we never look back.


Konstantinos Karagiannis: Plenty of our listeners weren’t here 60-some episodes ago, when we had Classiq on. Can you give a refresh or introduction on what Classiq is and what your general approach is?


Amir Naveh: Classiq was built with the understanding that quantum computers are going to be here, and they’re going to be here in a few years. To build the software for using these computers follows a lot of the challenges we had decades ago in creating classical software. You’re not writing at the gate level or at the punch card level anymore. You have operating systems and compilers that enable you to express your ideas more or less in a human-readable way. At the output, you have the gates that are actually working on the classical computers on the chips.


But in quantum, there is also quantum logic. You also have quantum gates and quantum machines, but you need to have this abstraction in order that you can describe what you want — what is the algorithm, or what is the programme you want to run?


But in these compilation steps, we sometimes forget how many optimisation steps are happening from the human level down to the machine level. If we don’t create these abstractions, we have to do things manually. People are very bad at optimising large programmes. Without this technology stack, in some sense, you’re very limited on what you can do with a quantum computer. This is the technology Classiq is creating, enabling this abstraction and automation — the analog to compilers and operating systems in the classical world.


Konstantinos Karagiannis: There’s plenty there we’re going to stick pins in and dive in on. Thanks for that overview. I’ve seen a diagram drawn pretty nicely of how the platform works. You can have an IDE, you can have a Python SDK and then you can drill down into all the other layers, like a synthesis engine, etc. Can you describe what a person sees in those different ways when they’re trying to interact with the platform?


Amir Naveh: The first thing we need to understand is that the person needs to describe their algorithm. This we call the model of the quantum algorithm. They can describe it using the graphical interface, they can describe it using Python, they can describe it using our modeling language. But in essence, it’s always describing the logic of the quantum programme, defining which functions or which building blocks you’re using and how they connect, or how the inputs and outputs work between each of them in order to create a full logical programme.


This is something the human does because they understand what they’re trying to achieve. This is the input for us. This goes into a compiler or synthesis engine, which takes this model, which is abstract, and creates concrete implementation of the actual gate-level, machine-level code that can actually run on a quantum computer.


If people are aware, for example, of Qiskit, you have formats called QASM quantum assembly — that would be the output of the compiler or the synthesis engine that describes the concrete programme. Now, from one model, you can have a very large number of concrete programmes, depending on if you want to optimise on the number of qubits, on the depth on the errors. If you know the specific hardware, it will be wired differently. Even a single function can have many implementations, and the full algorithm can have a very large space of different solutions. This is the first step.


Then, once you have this concrete quantum programme, sometimes also with some classical instructions on how to iterate this quantum programme many times, you send it over to a simulator or to actual quantum hardware, which is also not always trivial to do, because you have many interfaces, and every single machine works a bit differently. This is an end-to-end platform where you always begin with describing the quantum programme using a model, then it’s compiled into a concrete implementation, which is then run on hardware or a simulator. You get the results. This is basically the flow.


Konstantinos Karagiannis: For those listening, you choose how you want to start the process. Do you want to be abstract — to hopelessly simplify it here, basically, moving around little colored blocks to create a circle — or do you want to actually drill down on the code level? You end up with this model, and that gets passed on to the rest of the platform to do the synthesis, to create output code and then send it to execute on some kind of target?


Amir Naveh: Exactly. At the easiest level, we have quite a large library of prebuilt applications and algorithms. You can open one of them, change whatever parameters you want — Shor’s algorithm — put in the number you want to factorise, and then run it and you’ll get an answer. That’s the simplest way. But if you want to change within Shor’s algorithm how the modular exponentiation is being implemented, you can go into that level. You can work at many layers of the subtraction layer, and of course, the more you go inside, the more control you have over what is going to happen at the end.


Konstantinos Karagiannis: In a bit, I want to talk about those Classiq models you have — the prebuilt stuff people can start playing with. I’m visualising this and moving through the layers so everyone can understand the workflow. The newest thing here is QMod, a new language with constructs for quantum. Can you talk about that, and how it might be an easier way for folks to get started than with the Classiq Python SDK?


Amir Naveh: This is important. I wish we wouldn’t have had to build a language. I wish there was something that was descriptive enough so we could use it off-the-shelf. For classical computing, we have many of these languages, from languages for chip design like Verilog to languages for algorithm development like Python. But in quantum — let me give you an example. If you have a multi-control-x gate, which is a very common construct in many quantum algorithms, in any other quantum programming language, you have to specify the implementation. You have to say how many auxiliary qubits it’s using and how these auxiliary qubits are wired to other auxiliary qubits. It’s forcing you to manage the memory and manage the different implementations. This is hardcoded in the language. It’s not something you can bypass.


We had to give the users some way in which they can describe the quantum algorithm without specifying the implementation so that first, it’s easier for them, and second, you can do many levels of optimisation on this algorithm the user doesn’t care about. The user doesn’t care about wiring the auxiliaries in an optimal way. They just want to get a circuit with a minimal number of qubits or that fits within some specific hardware.


Every quantum model you create with Classiq will end with QMod, which is your way of saying, “I’ve just described a quantum algorithm or a quantum programme,” and it’s always frustrating to learn a new language. But here, everyone who uses this tells us, “This is so much easier. I could work with the gates directly, and why are the qubits?” But here, you’re giving me a language that enables me to describe what I care about. The CX’s are just the implementations. I care about the logic. This is a language that’s enabling me to describe the logic. This is the major step here.


Konstantinos Karagiannis: So, QMod comes in earlier in the steps, and you build your model with this language, then you send it off, then you still, in theory, end up with code that gets output in the end if you did want to tweak QASM or something later on.


Amir Naveh: Of course. There are different levels of the abstraction at the modeling level. But of course, after you press Synthesise — there’s a synthesise button in the IDE, for example — you can download the quantum assembly. You can take this and change the CNOT gate into a CZ gate and change one function into another function and it’ll work. It’s a well-defined syntax, but it’s at a level much closer to the actual hardware.


Konstantinos Karagiannis: I want to make sure listeners understand that just because it’s a language you created and it works in your world, it doesn’t limit you after that. It does output and interface with the rest of the ecosystem.


Amir Naveh: You can take a QMod and output QASM from this, and you can also, if you want, take a QASM and upload it, and you will see it in our platform. We’re very much supportive of the lower levels of the stack. That’s very helpful. The fact that there’s somewhat of a standard in many people accepting QASM3 or Q Sharp, which we also support, this is important. We don’t want to replace those levels.


Konstantinos Karagiannis: While you’re experimenting with QMod, you don’t have to worry about what your target will ultimately be. Will you be sending it to IBM? Will you be sending it to Braket? It doesn’t matter. You can just play more freely.


Amir Naveh: For sure. I encourage listeners, of course, to enter our platform. It’s easy — just go to Platform.classiq.io. You can see in the place where you write the QMod, you can also specify the hardware. Now, you don’t have to, and then you’ll get some circuit that’s ready to run, but if you know the hardware in advance, it’ll make decisions based on the hardware. That’s strong. If you have full connectivity, you’ll get a different circuit than if you have nearest-neighbor connectivity in the qubits. It implies different implementations, which will be more optimal for your specific hardware. This is nice — how knowing what the target will be helps the optimisation process. You don’t have to do it, but it can help.


Konstantinos Karagiannis: You can get the optimisation by knowing while you’re in QMod. If, later on, you decide on a different platform, is it possible to apply any kind of optimisation then?


Amir Naveh: QMod stays the same. This is adding additional constraints. Let’s say my model is saying, “Do this Grover’s search problem.” This will stay the same, but now, one time, I’m saying, “The constraint is, you have up to 100 qubits to work with.” I’ll get one circuit. The second time, I’ll say, “Use as few two-qubit gates as possible.” I may get a circuit with more than 100 qubits, but I’ll get fewer two-qubit gates. But they’re all stemming from the same QMod, from the same model. I didn’t change the QMod — I just put different constraints and preferences. This is what the hardware is also doing. If I put a different hardware, it’s always the same model, but I’m changing how the constraints and preferences are — how the synthesis engine treats them.


Konstantinos Karagiannis: Looking at how this works, I want to make sure listeners understand that this is something that, even though it seems abstract and high-level, might lead to a greater understanding of what goes on way low-level. That’s what impressed me.


Amir Naveh: For example, Grover’s search is a good example because it’s a simple algorithm. When you’re looking at the model, it’s straightforward. Do Hadamard, then do the oracle. Then, if your oracle, for example, is an arithmetic function, you write the arithmetic function and then you have the logic, and then do the diffuser. This is so simple. This is just how Grover works. Then, repeat this so many times. That’s easy.


But in each of these steps, in the arithmetic within the oracle, or in the MCX gate within the diffuser, there is so much to do. You don’t care. When you’re doing the diffuser — you just want to flip the state vector there. You don’t care how many auxiliaries the diffuser is going to use, and you don’t care how the uncomputation was managed within the arithmetic within the oracle. It makes it much easier to read. If I would have drilled this down to the CNOT level, you wouldn’t understand what’s going on. It’s a benefit both for the optimisation and for readability. This is the most direct way how you can describe Grover’s algorithm formally.


Konstantinos Karagiannis: The output here is intended to be enterprise grade. Ultimately, the hope is to build a use case that can actually be applied for some business purpose one day. But what’s interesting is, you can do this for free, which I thought was interesting. Can you talk about the new licensing model — about free for personal — and how it switches over?


Amir Naveh: That’s a good point. I was at the Quantum Information Processing conference just last week in Taiwan, and it was painful for me that a lot of people didn’t know this. This is a good platform, maybe, to shout out to the world — the platform is open. You can use it for anything that’s noncommercial. If you’re a researcher, if you’re just an individual, you want to try it out, to test it, signing up takes 10 seconds, and there you are. You can work with the IDE, you can do pip install Classiq and work with SDK. No one’s going to limit you. We’re not charging anything. We just want to create a large community around this. This is important for us.


Of course, if you’re working at an enterprise team, we’d be happy to discuss and work together on creating what’s interesting. But for noncommercial community use, this is open for everyone, and it’s our biggest passion to work with as many people as possible.


Konstantinos Karagiannis: It lowers the barrier entry too. If you want to consider using it at your company or your team, whatever, you can go try it out. Of course, all the links are in the show notes for all this. It does take 10 seconds to sign up and get started. It’s quick and easy, and you can use the interface right in your browser, basically, to get started.


We’ve talked a few times now about this sample code and these sample use cases that appear. They’re called Classiq models, and I urge listeners to go take a look at them. There’s a lot there. There’s chemistry, cybersecurity, there’s finance, logistics, optimisation — basically, all the stuff you would expect to see. But when you click in on them, there are actually papers behind some of the models, and they’re the basis of them.


I thought it was funny because I was looking at the patching-management one under cybersecurity, and it’s based on — I was, like, “Does this remind me of something?” I look — sure enough, it was based on the paper by Mark Carney, who was on this show from Quantum Village at DEF CON, the kill chain paper he wrote. I have some deep experience with that paper. I thought it was interesting to see it implemented in this way. Can you talk about some other sample use cases that are interesting to you from the models?


Amir Naveh: I’m excited about this. It’s a project the team I’m working with has been working on for a long time. We said, “We’ve built this technology. We’ve built this platform where you can do anything. Let’s do the things.” We’ve been working with a lot of customers and users, and we have quite a lot of experience on what’s interesting. We said, “We won’t do everything, but we’ll do at least a few use cases in every industry and show how easy it is, or how approachable this is.”


This was important for us. Specifically in cybersecurity, being an Israeli company comes with, usually, a lot of the people in your company are ex-IDF cyber experts. We have a large percentage of the company coming from a cyber background. All of them know the cyber use cases by heart. We said, “Maybe it’s good to show some cyber applications that are not only Shor’s algorithm or offensive but also defensive cyber.” How can you use quantum to protect your systems and your vulnerabilities? This is exciting.


The patch management, part of that is, doing optimisation problems with Classiq is nice. It’s even a step further from what I described earlier on — doing from, for example, Grover’s algorithm, where you can work with the building-block . If you have an optimisation problem that’s well-defined — meaning, you have your variables, your constraints and your domains for the variables — and you have some optimisation function, you can write all of these down in a very straightforward way.


We have an interface for defining these optimisation problems, and then you can get a quantum algorithm. You don’t even need to understand the underlying Grover or QAOA scheme or whatever. You can, of course, always dive into it. But if you’re a non–quantum expert, for example, and you have this optimisation problem in mind — you want to see how this vertex cover or graph coloring or whatever other problem maps into a quantum computer — all you need to do is define the problem. This is another step forward. It’s not always the case for every single problem, but in optimisation, we’ve done this extra step because a lot of problems are optimisation problems.


Konstantinos Karagiannis: If you click inside of the optimisation — and, again, the links are in the show notes — you’ll be surprised by how many there are there. There’s a weirdly specific electric-grid optimisation, and then it gets more general — MaxCut, stuff like that. I was, like, “I was expecting to see two things in there. I didn’t expect to see that many.” It’s a nice starting point, and you can potentially build something worthwhile. But remember, if you build it for commercial purposes, eventually, the licensing kicks in, but for now, you can start playing.


Is there anything you’re doing to entice more of this community for education, like for building more of these samples?


Amir Naveh: That’s part of the reason why we put this publicly on GitHub. It doesn’t look as pretty as I would have wanted, but being a startup, sometimes you just put it out there and then you iterate on it being nicer. But we encourage people to work with what we have and then to build their own.


There’s also a Slack community that’s moderated by Classiq. There’s a link, also, in the platform, easy to connect, and we have maybe 5,000 people there right now, and it’s very active. In the company it’s very important for us to answer everything, so you won’t have an unanswered question in this community.


Anything — you’re new to quantum, or you have this very specific paper you’re trying to implement and you got stuck with some syntax error or whatever — just ping us over there. You can reach out to anyone from the company to schedule a workshop or a training or whatever. We’re very happy to engage with anyone that’s interested. It’s a small community, so everyone is welcome, and we’d be happy to put in the efforts.


Konstantinos Karagiannis: Are you seeing users answering each other’s questions? “I had that problem, and I did this” — that typical forum stuff.


Amir Naveh: Yeah, that was nice. We did a course with Classiq in the past few months — like, 10 teams each doing a research project with the platform. Then people from one group were answering the people from another group. I won’t say it’s fully autonomous — everything is working, and we are just sitting back and looking at how it’s working. But the community is very active, and the usage, when we’re looking at the usage graphs, it’s growing on a daily basis, and that’s the main goal — just to see how the numbers are growing and how the community is adapting.


Konstantinos Karagiannis: We’ve seen that some papers are the basis for what becomes a Classiq model. To your knowledge, have any of those folks in that community used one of the Classiq models to then build and publish a paper? Has it gone the other way?


Amir Naveh: There are quite a few projects. Some of them are going to publish on arXiv, but I don’t know if they’re going to try and do peer-reviewed journals as well. I know quite a lot of research groups are working on implementing circuits with the platform. I hope they gain advantage from it and use it properly. For us, the research community is very important right now. That’s what leads the ecosystem. There are quite a few. And of course, when working with enterprise customers, that’s quite a common thing they do. Either by themselves and with our support or together with us, they sometimes want to create research papers. There are at least a few that are in progress and will probably be public in the coming months.


Konstantinos Karagiannis: That’s great. Before we start to wind down, are there any other features you’re trying to implement that you can give us a sneak peek about?


Amir Naveh: This is something that’s much nicer shown than said, but I’ll try within a few words. One of the ways to describe a quantum programme is graphically. If you have the building blocks, you can wire them together. This is quite strong because you’re just saying how the inputs and outputs behave. For example, you’re not saying how the memory behaves — you’re just defining the logic. This is our graphical interface. The output of this is the same QMod — it’s the same structure of language.


You can also work with this textually, but actually seeing this graphical way of viewing and working with quantum circuits, there’s an “Aha!” moment for many people. They understand why this is fundamentally different than working with gate-level programming languages like Qiskit. This is important. Sometimes, it’s just easier working graphically, but also, just for understanding the different layers of how this abstraction works, this is important. This is something at the beta level. We already have it. Some of our early-access people are using this already, and I hope we’ll have it open for wide usage in the next one or two months.


Konstantinos Karagiannis: It’s a sense of, how much can you represent with a rectangle on the screen? It’s, like, you have this high-level rectangle, and inside, there are a bunch of little ones representing actual gates, and so on and so forth. People are getting familiar with this idea.


Amir Naveh: Not that I’m a LabVIEW fan — I hate LabVIEW — but for anyone that’s worked with LabVIEW or with Simulink by MATLAB, this is the same idea of design: You describe the logic and then code is generated. You can work with the Python SDK, and you can work with the textual language. I’m not forcing anyone to work at the graphical level, but it gives some insight and it’s quite exciting. I’m saying this as a person who doesn’t like graphical tools too much.


Konstantinos Karagiannis: You do definitely have to see it. I urge people, since it is free and it is powerful, to take a look at the links in the show notes and give this a try for yourself.
Amir, thank you so much for coming on. I appreciate it, and I hope you get a lot more people added to those ranks inside that channel.


Amir Naveh: Thanks. It was nice talking, and I feel your love for the platform as well. I hope we’ll be able to come in two more years and share even more exciting advances and innovations. Thank you so much for having me.


Konstantinos Karagiannis: Now, it’s time for Coherence, the quantum executive summary, where I take a moment to highlight some of the business impacts we discussed today in case things got too nerdy at times. Let’s recap.


Classiq makes quantum coding easy with a development platform that enables multiple levels of abstraction and fine-tuning. It’s all about translating algorithms to working code. Classiq calls this description of a quantum algorithm a model. To describe or define a model, you can dig into a Python SDK, sure, but you can also programme in a more modular way, literally moving around code blocks to build circuits. A new language called QMod makes it easy to describe the logic of a model for the platform to then run in its synthesis engine. We’ve talked about quantum computing being a full stack here before, and this tool makes it easy to work at your own desired level.


If you’re struggling to get started, you can modify numerous provided use-case examples with your own parameters. For example, add the number you want to factor to Shor’s algorithm code. After an algorithm is synthesised, it can be output to OpenQASM. This allows for interoperability and the ability to code without worrying about the back-end target. One of the biggest developments in the platform is that you can now use the full tool for free for personal use. Check out the links in the show notes to get started on enterprise-level coding today. A license will be required for commercial use.


That does it for this episode. Thanks to Amir Naveh for joining to discuss Classiq, and thank you for listening. If you enjoyed the show, please subscribe to Protiviti’s The Post-Quantum World, and leave a review to help others find us. Be sure to follow me on all socials @KonstantHacker. You’ll find links there to what we’re doing in Quantum Computing Services at Protiviti. You can also DM me questions or suggestions for what you’d like to hear on the show. I’ll be gathering those for an AMA episode I’d like to do soon. For more information on our quantum services, check out Protiviti.com, or follow Protiviti Tech on Twitter and LinkedIn. Until next time, be kind, and stay quantum-curious.