The post Azure Quantum unlocks the next generation of Hybrid Quantum Computing appeared first on Q# Blog.
]]>Quantum computing is inherently hybrid. The key to unlocking impactful, commercial applications at scale will be deep integration between classical computing capabilities including HPC and AI with scaled quantum computing in the cloud.
Now, researchers can begin developing hybrid quantum applications with a mix of classical and quantum code together that run on one of today’s quantum machines, the Quantinuum HSeries in Azure Quantum. This capability unlocks a new generation of hybrid algorithms and is a first for the industry.
The new Integrated Hybrid feature is an important step forward and is a key part of our Hybrid Quantum Computing Architectures. As you can see in Figure 1, tighter and richer integrations will be made available between quantum and classical computing as each milestone is reached on the path to scaled quantum computing.
Figure 1 – Hybrid Quantum Computing Architectures
This launch introduces integrated quantum computing, enabling scientists to devise new algorithms such as adaptive phase estimation that can iterate and adapt over classical computation while physical qubits are coherent, as illustrated in Figure 2.
“Quantum computing hardware is rapidly improving. Enabling solutions such as the integrated hybrid tools from Azure Quantum empower users to take advantage of the emerging hardware features and capabilities”, Tony Uttley, President & Chief Operating Officer at Quantinuum
This new capability also represents a milestone for students engaging with quantum computing. Students can begin to learn algorithms without drawing circuits, and can instead leverage high level programming constructs such as branching based on qubits measurements (if statements), loops (for…), calculations and function calls.
Figure 2: Example of an Integrated Hybrid program
“The ability to do high fidelity iterative circuits, including classical calculations within runtime, opens up a whole new set of algorithms. Each algorithm could significantly improve fidelities just like iterative phase estimation, and bring us closer to Quantum Advantage.”, shares Michael Egan, Director Quantum Technologies at KPMG.
A new generation of hybrid algorithms
Early adopters of integrated hybrid capabilities have already developed or adapted new algorithms applicable to a broad range of fields including chemistry, machine learning, and error correction:
“Error correction methods described in research papers and reserved to quantum hardware manufacturers can now be implemented and tested by scientists around the world. Using Azure Quantum and QCI unique realtime capabilities, the Entropica Labs team implemented a simple process for the quantum repetition code scheme. The data allowed the team to investigate the effects of noise on different initial quantum states, and different circuit variations of the scheme. It also allowed the team to test the effectiveness of different errorcorrection recovery strategies. This opens the possibility of optimizing code schemes for better efficiencies, based on realworld hardware environments. Azure Quantum provides the framework to ensure that in the quest of achieving scalability, errorcorrection code schemes can tested and optimized at each step of the way” explains Jing Hao Chai, Faulttolerant Quantum Computing Scientist at Entropica Labs.
“Azure Quantum, equipped with a new quantum computer hybrid architecture, has become a powerful platform that allows us for a wide range of research possibilities.” tells Tennin Yan, CEO at QunaSys.
A collaborative effort across industry leaders
Developing hybrid quantum computing architectures requires a full stack approach – software and hardware are married to deliver new capabilities and the highest possible performance. The QIR Alliance, created in September 2022 and composed of leading quantum software and hardware vendors, has driven innovation into integrated hybrid capabilities via the Quantum Intermediate Representation.
“We are proud to see that the efforts of the QIR Alliance have resulted in achieving a tighter integration between quantum and classical resources. These recent advances are a critical step towards a practical use of quantum acceleration. We are excited about the new opportunities for application research that are now available to everyone.”, Dr Bettina Heim, Chair of the QIR Alliance.
“QIR is the main enabler for increasing expressivity of quantum programs in a standard and interoperable manner. Using hardwarespecific QIR profiles, end users can take full advantage of the unique capabilities provided by the HSeries quantum computers including runtime support for measurementconditioned program flow control – a key building block of quantum error correction paving the way towards fault tolerant quantum computing of the future.” said Alex Chernoguzov, Chief Engineer of Commercial Products at Quantinuum
Start exploring Integrated quantum computing
You can try integrated hybrid quantum computing on Azure Quantum for free. All users are eligible for $500 in Azure Quantum credits – use it to explore and experiment with any Quantinuum QPU available on the platform. You can also apply for up to $10,000 in research credits on Azure Quantum to further your quantum research and innovation. To get started, just set up an Azure account (check out free Azure accounts for students), create an Azure Quantum workspace in the Azure Portal, and start your quantum journey with Azure Quantum.
For an installation free experience, try our hosted notebooks experience in the Azure Portal. Hosted notebooks enable a variety of languages and Quantum SDKs. To try hosted notebooks:
Executing this sample will help you learn how to develop algorithms performing iterative and adaptive calculations while qubits are coherent, mixing classical and quantum compute operations. Programming against specialized highperformance hardware running next to the QPU, such as FPGAs, is no longer required. Running an equivalent program without integrated hybrid capabilities would require returning every intermediate measurement result and then running post processing on the data.
Using Python + Q#
This sample verifies a 3 qubit Greenberger–Horne–Zeilinger (GHZ) state and counts up the number of times it sees the entanglement fail out of 10 attempts. Without noise, this would return 0 for every shot, but with noise you can get back failures.
import qsharp.azure
# Enter your Azure Quantum workspace details here
qsharp.azure.connect(resourceId=”, location=”)
%%qsharp
open Microsoft.Quantum.Measurement;
open Microsoft.Quantum.Arrays;
open Microsoft.Quantum.Convert;
operation CheckGHZ() : Int {
use q = Qubit[3];
mutable mismatch = 0;
for _ in 1..10 {
H(q[0]);
CNOT(q[0], q[1]);
CNOT(q[1], q[2]);
// Measures and resets the 3 qubits
let (r0, r1, r2) = (MResetZ(q[0]), MResetZ(q[1]), MResetZ(q[2]));
// Adjusts classical code based on measurement results
if not (r0 == r1 and r1 == r2) {
set mismatch += 1;
}
}
return mismatch;
}
# Set a Quantinuum target backend with Adaptive Execution flag, and submit job
qsharp.azure.target(‘quantinuum.sim.h11e’)
qsharp.azure.target_capability(‘AdaptiveExecution’)
# This run will use approximatively 10 HQCs (Quantinuum billing unit)
result = qsharp.azure.execute(CheckGHZ, shots=50, jobName=’Check GHZ’, timeout=240)
result

Learn More
At Microsoft, we are architecting a public cloud with Azure that enables scaled quantum computing to become a reality and then seamlessly delivers the profound benefits of it to our customers. In essence, artificial intelligence, highperformance computing and quantum are being codesigned as part of Azure and the integration of which will have an impact in important ways in the future.
Learn more about how Microsoft is harnessing the power of the cloud to make the promise of quantum at scale a reality and join our upcoming Microsoft Quantum Innovation Series with Mark Russinovich, Chief Technology Officer and Technical Fellow of Azure at Microsoft and Krysta Svore, Distinguished Engineer and Vice President of Advanced Quantum Development, Quantum at Microsoft.
Also, to learn more about how to use the new Integrated Hybrid feature in Azure Quantum, register for the Developer Webinar and read the full documentation.
#quantumcomputing #quantumcloud #azurequantum #quantinuum #QIR
The post Azure Quantum unlocks the next generation of Hybrid Quantum Computing appeared first on Q# Blog.
]]>The post Shorter quantum circuits appeared first on Q# Blog.
]]>Microsoft has taken a more challenging, but what we believe to be a more promising path towards scaled quantum computing and designed our machine using topological qubits. Our unique qubit architecture is theorized to enable our quantum machine to be small enough to fit in a closet, fast enough to solve problems in a practical timeframe, and have the capability to control more than one million qubits. We are confident in this design given our significant physics breakthrough, which cleared a major hurdle toward engineering the world’s first topological qubit and ultimately, a scaled quantum machine. Anyone can access the same data as our scientists to better understand Microsoft’s approach to building a scalable, fullstack quantum machine.
In preparation for scaled quantum computing, Microsoft aims to empower developers with the knowledge and tools required to design impactful quantum applications. Understanding how many qubits are needed and how fast and reliable the quantum computer must be for practical applications is important for accelerating toward its scaled realization. At Microsoft, we’ve studied the resources required to unlock quantum advantage and focused on breakthroughs to deliver it sooner. Some of our breakthroughs were presented in Ghent, Belgium, at Quantum Information Processing 2023, which is one of the leading scientific conferences in the field. Together with our collaborators we presented results including:
The recordings of the talks are now available on YouTube, courtesy of QIP organizing committee:
This last result, described in our scientific paper “Shorter quantum circuits”, introduces methods to reduce the resources required to execute a very common set of operations in largescale quantum algorithms called diagonal qubit rotation gates, with on average a 50% cost improvement. The runtime can be sped up by a factor of 2.5 by trading for a space (number of qubits) increase by the same factor. Our methods lead to an overall reduction in resources needed to run the algorithm’s instance.
You can try it for yourself! We have published an Azure Quantum Sample Notebook and a dataset that includes examples of circuits produced using the new compilation methods. It includes data analyses that reproduce the results detailed in the scientific paper and are used within the Microsoft Azure Quantum Resource Estimator.
The Resource Estimator is a software tool designed to help quantum algorithm designers and hardware engineers alike assess the resources required to run an instance of a quantum algorithm on faulttolerant quantum computers. The methodology used by this tool is described in our programs’ recent resource estimation study, “Assessing requirements to scale to practical quantum advantage“, posted on the arXiv. Two of the scientists behind this work, Michael Beverland and Mathias Soeken, shared more about the tool and methodology on Wednesday February 8 during the QIP 2023 industry session.
To access the notebook, follow the steps in Azure Quantum Notebooks tutorial
Let’s walk through the following steps to understand how the methods work:
The diagonal qubit rotation gate is a onequbit operation defined by the matrix:
The standard instruction set for a faulttolerant quantum computer, Clifford and T, only includes diagonal rotation gates for angles π/2, π/4, and π/8. However, many quantum algorithms require rotation gates with different angles.
For example, the Quantum Fourier Transform used in the factoring algorithm, requires rotation angles of π/2ᵏ for k = 4, 5, 6, …. The number of diagonal qubit rotation gates required for specific largescale quantum algorithms can be found in the resource estimation study . For instance, the quantum dynamics problem in this study requires 3.01×10⁵ diagonal qubit rotation gates outside of the instruction set, the quantum chemistry algorithm requires 2.06×10⁸ such gates, and the instance of the RSA factoring challenge for a 2048bit number requires 12 rotation gates outside of the instruction set.
So how do we map these different rotation gates to the instruction set available in the quantum computer? It turns out rotation gates outside of the standard instruction set can be approximated using circuits made up of a sequence of gates from the faulttolerant instruction set. We call them “rotation circuits”. The question now becomes how to determine the approximation accuracy needed. Let me briefly explain.
To understand the accuracy requirement for individual diagonal qubit rotation gates, let us briefly discuss the accuracy requirements for quantum algorithms. Like probabilistic classical algorithms, quantum algorithms do not need to be perfectly accurate. A certain level of inaccuracy in the results produced by the quantum computer can be overcome through classical postprocessing of the algorithm results. The algorithm designer typically specifies the required accuracy for the specific algorithm instance.
For instance, the quantum dynamics, quantum chemistry, and factoring examples mentioned earlier have tolerable levels of inaccuracy of 0.001, 0.01, and 1/3, respectively. There are several sources of inaccuracy, including failures of the instructions executed by the faulttolerant quantum computer. It is common to divide the overall inaccuracy among various sources, such as dividing the overall inaccuracy of 0.001 into 0.0005 due to failures of the faulttolerant instructions and 0.0005 due to imprecision of diagonal rotations. For 3.01×10⁵ diagonal qubit rotations, the inaccuracy per rotation would be split equally, resulting in an inaccuracy of 1.66×10⁻⁹.
The accuracy with which a quantum circuit over the faulttolerant gate set approximates a given rotation is measured using the diamond norm. The action of any quantum circuit can be described by a quantum channel, and the diamond norm is a convenient way of measuring the difference between channels; the diamond norm fully captures the difference in the channels’ behavior. To learn more about the diamond norm and its use in this context, see Appendix B in “Shorter quantum circuits”. The higher the accuracy per rotation needed, the larger the contribution of the rotation circuits to the overall space and time cost of the quantum algorithm instance. In other words, better accuracy results in bigger and slower circuits. In the next section, we will discuss the contributions of the rotation circuits to the space and time costs in more detail.
Understanding the cost of a quantum algorithm is crucial in determining its feasibility and optimizing its performance. The two main contributors to the cost are the spacetime cost of faulttolerant Clifford operations and the spacetime cost of Tstate distillation.
Tstates, which enable a nonClifford faulttolerant instruction called the T gate (that is R_{z}(π/8)), are essential for making a faulttolerant quantum computer more powerful than a classical supercomputer. However, the cost of preparing one logical Tstate is typically much higher than that of a logical Clifford operation.
The number of Tstates used by a rotation circuit, as well as its Tstate rate (number of T states used by the circuit per second), are good indicators of its overall spacetime cost contribution. In our paper we compare two compilation methods, using Clifford+𝑇 and Clifford+√T gate sets. Note that for both gate sets, only Clifford operations and Tstate preparations are used. The Clifford+√T gate set uses √T (that is R_{z}(π/16)) and √T³ (that is R_{z}(3π/16)) during an intermediate compilation step. The Clifford+√T method produces shorter quantum circuits with a higher Tstate rate, making it a better option if faster execution is desired but with a higher cost in terms of physical qubits used.
Before our work, there were three popular approaches for approximating rotation gates using a combination of Clifford and T gates with few qubits and without using resource states: Diagonal Approximation [RS2014], Fallback Approximation [BRS2014], and Mixed Diagonal Approximation [C2016],[H2016].
Diagonal approximation circuit
The Diagonal Approximation approach involves approximating a rotation gate with a sequence of one qubit Clifford and T gates.
Fallback approximation circuit
The Fallback Approximation uses two qubits and a measurement. It starts by trying to approximate the rotation gate with a shorter sequence of Clifford and T gates, and then falls back to the diagonal approximation if necessary.
Mixed diagonal approximation circuit
The Mixed Diagonal Approximation involves randomly applying one of several diagonal approximations with carefully chosen probabilities to achieve better accuracy.
In our work, “Shorter quantum circuits”, we improve the fallback approximation approach by allowing the success probability of the first step to be selected ahead of time. We also combine the mixing techniques with the fallback approximation. The plot and table below show the cost improvements for the Clifford and T gate set for a dataset of random angles. The results show that our mixed fallback approach has the best T count linear fit, as a function of diamond norm accuracy ε.
Expected T count as a function of approximation accuracy using Clifford and T gate set
Approximation approach  T count linear fit 
Diagonal [RS2014]  3.02 log₂(1/ε) + 1.77 
Fallback [BRS2014]  1.03 log₂(1/ε) + 5.75 
Mixed diagonal [C2016],[H2016]  1.52 log₂(1/ε) – 0.01 
Mixed fallback [Shorter Quantum Circuits]  0.53 log₂(1/ε) + 4.86 
We also extend all the above approaches to the Clifford+√T gate set. The rotation circuit produced using this gate set has a T rate that is 2.5 times higher but has a similar T count. Additionally, we present a unified approach across all approximation approaches and gate sets with various small improvements over previous work.
Our unified compilation approach, like previous works [RS2014], [KBRY2015], consists of three steps:
The first step determines the region based on the desired approximation accuracy, T count, and gate set. We provide methods for constructing a suitable region for each approximation approach. For the Clifford and 𝑇 gate set, the region is fourdimensional, while for the Clifford and √T gate set, the region is eightdimensional. In practice, we use integer programming with convex constraints for the convex hull of the region.
In the second step, the system of polynomial equations is reduced to a relative norm equation problem in a number field related to the chosen gate set. Solving the norm equation involves integer factoring, but in practice, we encounter instances that are easy to factor.
The third step utilizes exact synthesis algorithms that take advantage of the fact that the cost of unitary operations exactly representable using either the Clifford and 𝑇 or Clifford and √T gate sets can be calculated quickly without knowledge of the gate sequence. The exact synthesis algorithm decomposes the unitary by multiplying it with the gates from the gate set and reducing the cost greedily. It is like solving a combination lock by trying each digit until you find the correct one. In our case, the lock clicks when each correct digit is found. The number of digits represents the number of nonClifford gates in the sequence.
This approach can be applied to many other gate sets that allow for a certain number theoretic description as described in [KBRY2015]. A particularly simple gate set known as the V basis results in a twodimensional region in step 1, shown below, and a simple equation of x²+y²=c in integer variables x and y in step 2, instead of a system of four or eight equations for the Clifford and 𝑇 or Clifford and √T gate sets.
A region for diagonal approximation approach when using V basis gate set
The examples of quantum algorithms we have discussed above use Clifford operations, Toffoli gates and diagonal qubit rotation gates. However, an algorithm designer may want to use arbitrary onequbit gates, onequbit state preparations, or twoqubit gates, which are currently reduced to Clifford and diagonal qubit gates through faulttolerant compilation.
To address this, we introduce the magnitude approximation problem, which helps reduce the cost of compiling arbitrary onequbit and multiplequbit gates. This problem also has a mixed version and is covered by our unified compilation approach.
To enable trying the methods for yourself, we present a dataset that contains quantum circuits approximating diagonal qubit rotation gates using four approximation methods: diagonal, fallback, mixed diagonal, and mixed fallback. The gate sets used in the circuits include both Clifford and 𝑇 and Clifford and √T. The target rotation angles in the dataset consist of a thousand random angles and angles used in the Quantum Fourier Transform.
To access the notebook, follow the steps in Azure Quantum Notebooks tutorial
A Jupyter notebook is available on GitHub and as part of the Azure Quantum Sample Notebooks that explains the structure of the dataset and demonstrates how to reproduce the results from the study. The notebook and dataset provide opportunities for reproducing our results, comparing future approaches to our methods, and conducting more indepth analysis.
With the dataset, you can answer questions such as what the Tcount distribution of fallback circuits looks like or which gates are used by the approximation protocols. Additionally, if you have your own cost metric, you can use the dataset to evaluate our circuits.
Do not miss the chance to explore the exciting world of quantum circuits and improve your understanding of diagonal qubit rotation gates! Take advantage of our dataset, Jupyter notebook, and Azure Quantum Sample Notebooks to compare and analyze the results from the four approximation methods and two gate sets. Try your own cost metric evaluation and unlock new insights in quantum circuit design. While you are at it, try out other Azure Quantum Resource Estimation notebooks and join us on the path to accelerate quantum advantage.
The post Shorter quantum circuits appeared first on Q# Blog.
]]>The post Azure Quantum Winter Learning Opportunities appeared first on Q# Blog.
]]>Whether your objective is to explore interest in new technologies or extend knowledge for school studies or professional development, participating in hackathons and intensive schools can accelerate learning in a fun, interactive environment. We’re excited to share the following winter learning opportunities powered by Azure Quantum.
The Northwest Quantum Nexus (NQN) is a coalition of research and industrial organizations in the Pacific Northwest and neighboring regions with the goal of advancing Quantum Information Sciences (QIS) research and developing a QIStrained workforce. To help enable this goal, NQN is hosting a Hackathon, sponsored by Azure Quantum and IonQ, with virtual workshops on January 17 – 18 and the hacking period running on January 20 – 24. While the inperson hackathon is limited to attendees from NQN member schools, the preceding Azure Quantum and IonQ virtual workshops are open to all and will involve raffle prizes (some restrictions apply). See here for more details and how to register.
MIT’s Intradisciplinary Quantum Hackathon (IQuHack) is back again this year with both inperson and virtual challenges. Azure Quantum is proud to be sponsoring a virtual challenge focused on the new Azure Quantum Resource Estimator capability. Register now to secure a spot and learn more!
Qubit by Qubit is the online learning initiative of The Coding School, a 501(c)(3) organization that aims to empower the next generation through computer science education. Qubit by Qubit is offering a free, 4day intensive introductory program to help high school and university students learn foundations of quantum computing, including quantum mechanics, quantum circuits, and quantum algorithms and protocols, all while gaining familiarity with Microsoft’s quantum computing language, Q#, and Azure Quantum. Apply today!
We hope you enjoy and benefit from these Azure Quantum winter learning opportunities. As a reminder, there are additional learning resources available online including Quantum Katas and MS Learn, check them out today! Happy Learning.
The post Azure Quantum Winter Learning Opportunities appeared first on Q# Blog.
]]>The post Festivus: Azure Quantum Feats of Strength appeared first on Q# Blog.
]]>How about you – what is your favorite thing about Azure Quantum?
Wim van Dam
The post Festivus: Azure Quantum Feats of Strength appeared first on Q# Blog.
]]>The post Developing and using Azure Quantum assignments for quantum computing courses appeared first on Q# Blog.
]]>This course was definitely my favorite of the two courses I designed material for. Introduction to Quantum Science and Technology covers quantum physics in relation to quantum computing and communication protocols. Interestingly, it does not cover quantum algorithms or quantum programming! Considering that our end goal was to create Azure Quantumbased assignments, this posed a unique set of design constraints. Namely, we needed to leverage Q# and the Microsoft Azure platform WITHOUT requiring students to write a single line of code.
The solution we came up with was to create Q# interactive workbooks. The basic structure of these workbooks was as follows. Students would typically start by reading a writeup that provided context and related back to the material they were learning in class. Next, they would be presented with Q# code implementing an example or protocol. Then they would submit this code to Azure Quantum simulators or hardware and view visualizations of the program output. The last step for the student was to answer questions tying the code they are running to concepts in the course. This structure ended up working out very well. I think an example will do a great job illustrating our design philosophy.
In class, students learn about the physical realization of quantum gates on different architectures. For assignment 1 we wanted to relate this to the way we reason about these gates in an abstract manner.
Next, we dive into an application of these ideas with an example Q# program which demonstrates how this abstract model allows us to reason about quantum computation.
Lastly, the students have to answer some questions which tie things together.
It is really exciting to know that these materials have already been used at Purdue. The first session of this course using these materials is wrapping up right now. Fortunately, this has also allowed me to gather some data on student reception of the materials. So I’ll let the students speak as to whether we did a good job.
And my favorite response
I really enjoyed the assignments. Thinking about noise in quantum systems in such a straightforward way was great. I also like to relate the technology hardware to the algorithm itself, although quantum programming layer of abstraction is useful to learn about first! Being able to dial in to a real quantum machine was quite awesome.
So in short, I am happy to say that the reception has been positive. It is great to know that people are enjoying something I helped to build.
I also had a blast writing the assignments for Applied Quantum Computing III: Algorithm and Software. This course corresponds to the last 5 weeks of a 15week course at Purdue. The first 10 weeks are an introduction to quantum mechanics and quantum computing physics. Then for the last part of the course, students get a crash course in quantum algorithms and quantum programming. This made the task of designing these assignments a bit easier since we had the freedom to ask students to write code. We settled on a typical programming assignment structure where students were asked to implement different quantum algorithms using Q# and then run them on Azure Quantum simulators and/or hardware. The list of topics covered includes Simon’s algorithm, BernsteinVazirani algorithm, Grover’s algorithm, and Quantum Approximate Optimization Algorithm (QAOA).
Unlike the previous course, these assignments have yet to be used. So it remains to be seen how students will react to these quantum programming assignments. Maybe I am biased but I think they will enjoy learning about quantum programming using the powerful tools provided by Microsoft QDK and Microsoft Azure. I am certainly looking forward to seeing the feedback once the assignments are implemented in this coming Spring semester.
The post Developing and using Azure Quantum assignments for quantum computing courses appeared first on Q# Blog.
]]>The post λQ#: Understanding and Evolving the Q# Programming Language appeared first on Q# Blog.
]]>Fastforwarding by two or so years, I was interning at Microsoft Quantum on an unrelated project. Q# was still at the back of my mind, so while there, I tried to understand the history and pain points of the language by talking with the designers. This led me to propose a longerterm project for defining formal semantics for Q# and solving some of the problems I learned about. This project is far from complete, but I wanted to share some progress with you.
What does it mean to formally define a language, and why do we want to do it? While many programming languages come with informal specifications, they are written in natural languages (like English), often leaving subtle technical concepts for interpretation (leading to the infamous undefined behavior). A formal specification uses mathematical notation to avoid ambiguity in the meaning of the language and hence aids in understanding and allows precise implementation. This makes it easier to evaluate how new features may interact with existing ones, helping with the evolution of the language.
At a high level, a formal specification consists of the following:
Designing a new language with a formal specification is much easier than endowing an existing language with one. The design decisions aimed at user convenience can typically be at odds with the needs of a researcher studying the language. Since Q# already exists, we borrowed the methodology pioneered in the specification of the Standard ML programming language:^{[2]}
λ_{Q#} is a simply typed λcalculus extended with commands encapsulating actions on the quantum state. In λ_{Q#}, we may encode any Q# program as a pure functional term, analogous to how a language like Haskell treats side effects (we also borrow the do notation from Haskell). The Algol programming language pioneered the idea of safely combining pure functional programming with sideeffectful imperative programming.^{[3]}
Quantum teleportation in λ_{Q#} syntax
The syntax, the type system, and the safety properties of λ_{Q#} (enforcing the nocloning theorem and safe qubit memory management; that the Q# compiler currently does not enforce) have been discussed in various presentations.^{[4]} I take this opportunity to instead emphasize how the dynamic semantics of the language is defined in an accessible manner using a small set of program equations.
In the following equations, the terms on the left of the turnstile (⊢) show the types of variables used in the equations. qref⟨q⟩ represents the type of qubit; × represents the product type; ≡ is the symbol for equivalence; ⟨⟩ represents unit; and D(U, V) = U ⊕ V represents a block diagonal matrix corresponding to controlled unitaries.
λ_{Q#} program equations relating unitary gates and measurement (A and B) and those relating allocation with unitaries and measurement (D and E)
Equation (A) says that applying the quantum X gate to a qubit and then measuring it is the same as negating the measurement result. Equation (B) explains the action of a block diagonal matrix D(U, V) as quantum control: Applying the diagonal matrix and then measuring the control qubit is equivalent to measuring the control qubit and branching on the result to decide whether to apply U or V.
Equation (D) states that measuring a new qubit always results in 0 (false in our language). Equation (E) says that using a new qubit as control is the same as controlling by 0.
These four are the most interesting equations; I omit the other seven administrative equations. This presentation of semantics is known as algebraic or equational semantics. The key idea is to capture the entire behavior of a language using a complete set of equations. For quantum computation, this fully complete set (that we adapt for λ_{Q#}) was first introduced by Sam Staton in a 2015 paper. The beauty of this presentation style is twofold: it is both broadly accessible as almost everyone is familiar with equations from schoollevel mathematics, and it is concise while still being formal.
I hope this post helps you understand our approach to formally specifying Q# using program equations. For full details, see our paper Q# as a Quantum Algorithmic Language (arXiv:2206.03532) presented at the Quantum Physics and Logic conference earlier this year. In the paper, my coauthors (Kesha Hietala, Sarah Marshall, Robert Rand) and I argue that λ_{Q#} represents the core of Q# as an Algollike quantum language. It safely combines pure (classical) and effectful (quantum) computation while obeying a strict stack discipline for (qubit) memory management. We also provide translation rules from Q# to λ_{Q#}.
λ_{Q#} is an idealized version of Q# aimed at providing it a formal language definition, placing the language on a solid mathematical foundation, and enabling further evolution of its design and type system. I am currently working on preventing aliasing in Q# arrays and coverage of remaining features in λ_{Q#}; look out for my upcoming dissertation!
The post λQ#: Understanding and Evolving the Q# Programming Language appeared first on Q# Blog.
]]>The post Signing up for Azure Quantum from scratch appeared first on Q# Blog.
]]>Because of its global importance, signing up for Azure is maybe a bit more complicated than you are used to. To help you get started, I will use this post to walk you through the signing up process. At the end of this tutorial, you will be ready to explore our gallery notebooks, write your own, and use the hardware and simulators of our partners. To get there as a firsttime user, you have to take the following steps, which are explained below:
Before you get started, you could check the availability of the Azure Quantum providers IonQ, Quantinuum, and Rigetti in your country, which you can do at the Global availability of Azure Quantum providers page.
Heads up: getting a quantum workspace is free, but you will need to provide a credit or debit card number to set up a subscription.
You need a general Azure account to get access to Azure Quantum. To set up this account, go to
A note for students and educators in the US: If you have an .edu email address, then you might want to use that to set up your account as that gets you a free student subscription. But to keep things simple and as general as possible, I will assume here that you are not using a .edu address.
Once you have created an account, things should look like this:
Before you can get a quantum resource, you must create a subscription as part of your account. Select the blue “Start” button under “Start with an Azure free trial”. If this is your first Azure account, then you are eligible for the free subscription. You should now be at the site
which should look like this:
Select the “Start free” button and wait a few seconds. Now enter “profile” data. As part of this process, use “Text me” or “Call me” to get a verification code. Select “I agree to the customer agreement and privacy agreement”. Select “Next” and wait a few seconds. Now, since Azure provides paid services, you have to provide a credit card number. But, as it states: “you won’t be charged unless you move to payasyougo pricing”. Enter this data, select “Sign up”, and wait a moment.
At this point you have a subscription and your portal site https://portal.azure.com/ should look like this:
Your Quantum Workspace will be considered a resource, hence: select “+ Create a resource”, search for “Azure Quantum”, and when found, select “Create”.
When you get to the Create Quantum Workspace site, you want to select “Quick create”:
You’re almost there: give your workspace a proper name and enter your Region. Check Azure geographies page to see how the various regions are defined.
Hit the Create button at the bottom of the page and keep in mind that the deployment of the workspace takes about 5 minutes to complete. Once done, you can “Go to resource”. You can claim success if your portal looks like this:
Congratulations, you are now ready to explore the many resources available on Azure Quantum, such as:
.
To get going with the gallery notebooks you first have to copy them to My notebooks so that you can view, execute, and edit them to your heart’s content.
Enjoy and Happy Holidays!
The post Signing up for Azure Quantum from scratch appeared first on Q# Blog.
]]>The post Teaching Quantum Computing with Q# and Azure Quantum at Northeastern University appeared first on Q# Blog.
]]>This fall I taught an “Introduction to Quantum Computing” course at Northeastern University. It was my second time teaching this course at NEU, after the first run in spring 2020. As always, it was a unique experience that taught me a lot – though, hopefully, it taught my students more! – so I decided to share the highlights of my experience with you.
In this course, I introduce quantum computing to graduate students at the College of Engineering at Northeastern University who pursue a nonphysics major. This allowed me to teach the contents through the lens of software engineering rather than physics, spending only a bit of time on an overview of physical implementations of quantum devices and instead spend more time on the algorithm implementation and quantum software stack. In fact, my approach was based on the one our team took when teaching at University of Washington back in 2019: introduce the basic concepts of quantum computing and simple algorithms, focusing on using them for solving problems and implementing and evaluating algorithms. Same as back then, I used Q# and Microsoft Quantum Development Kit as the software tools for the course, adding Azure Quantum for running programs on cloud simulators and hardware.
The threemonth course consisted of two parts:
Let’s take a closer look at the three different kinds of assignments that the course offered: solving programming problems, debugging code, and running code on Azure Quantum.
This type of assignment requires the students to apply the theoretical concepts and algorithms they have learned to solve simple programming problems. To give you some examples,
Same as in the exercises in the Quantum Katas, each problem describes the task and provides the signature of a Q# operation that matches the description of the given problem. The student has to implement the operation that solves the task and turn in their code. The grading is done automatically using a testing harness – Q# code that runs the solutions on a set of tests using quantum simulators and checks that their results match the expected ones.
We’ve used similar assignments in the past courses as well, but this time I took them one step further. In the past we didn’t share the testing harnesses with the students, since they often included solutions to the problems (see “Inside the Quantum Katas” blog series for examples of testing code that relies on reference solutions), and you don’t really want to include the solution as part of the graded assignment! This meant that the instructors and teaching assistants could use the testing harness to automate the grading process, but the students had to come up with other ways to test their work. This could be challenging at times, especially in the first weeks when the students were exposed to a lot of completely new concepts at once.
For this course, I took the feedback from the past courses to heart and modified the projects to conceal the testing code while allowing the students to execute it. This allowed me to share it with my students without revealing the solutions, and my students – to test their code themselves and to figure out which tasks they needed to focus on.
Debugging assignments offer the students a quantum program that has a number of bugs of different kinds and ask them to identify and fix them. They aim to improve the students’ familiarity with the software tools they use and with the algorithms covered in the course. I used them during the weeks that covered wellstudied algorithms such as BB84 quantum key distribution protocol or Grover’s search, when the students are already familiar with the basics of quantum programming and can focus on the logic behind the program.
Tracking down different types of errors emphasize different aspects of writing and running quantum programs:
The final type of assignment encourages the students to explore the behavior of quantum programs on the cloud simulators and quantum devices available via Azure Quantum using the free Azure Quantum credits. The tasks were mostly introductory, teaching the students to run Q# programs on cloud targets and to interpret the results rather than diving deep into the hardware.
This semester was the first time I introduced Azure Quantumbased assignments. I’m looking forward to improving them and including new tools, such as the recently released Azure Quantum resource estimation tool, in the course!
Check out Azure Quantum for Educators page to see examples of materials developed for the course.
The post Teaching Quantum Computing with Q# and Azure Quantum at Northeastern University appeared first on Q# Blog.
]]>The post Automate Resource Estimation with QIR appeared first on Q# Blog.
]]>In these samples, e.g., Estimation with Q# input, you can generate resource estimations like the following that are computed from a quantum program that multiplies two quantum registers (click on the titles to unfold more tables with details on the estimates):
Physical qubits  8160 
Number of physical qubits
This value represents the total number of physical qubits, which is the sum of 4200 physical qubits to implement the algorithm logic, and 3960 physical qubits to execute the T factories that are responsible to produce the T states that are consumed by the algorithm. 
Runtime  6ms 80us 
Total runtime
This is a runtime estimate (in nanosecond precision) for the execution time of the algorithm. In general, the execution time corresponds to the duration of one logical cycle (10us) multiplied by the 608 logical cycles to run the algorithm. If however the duration of a single T factory (here: 82us 500ns) is larger than the algorithm runtime, we extend the number of logical cycles artificially in order to exceed the runtime of a single T factory. 
Logical algorithmic qubits  84 
Number of logical qubits for the algorithm after layout
Laying out the logical qubits in the presence of nearestneighbor constraints requires additional logical qubits. In particular, to layout the ${Q}_{\mathrm{a}\mathrm{l}\mathrm{g}}=33$logical qubits in the input algorithm, we require in total $2\cdot {Q}_{\mathrm{a}\mathrm{l}\mathrm{g}}+\lceil \sqrt{8\cdot {Q}_{\mathrm{a}\mathrm{l}\mathrm{g}}}\rceil +1=84$logical qubits. 
Algorithmic depth  608 
Number of logical cycles for the algorithm
To execute the algorithm using Parallel Synthesis Sequential Pauli Computation (PSSPC), operations are scheduled in terms of multiqubit Pauli measurements, for which assume an execution time of one logical cycle. Based on the input algorithm, we require one multiqubit measurement for the 8 singlequbit measurements, the 0 arbitrary singlequbit rotations, and the 0 T gates, three multiqubit measurements for each of the 192 CCZ and 8 CCiX gates in the input program, as well as No rotations in algorithm multiqubit measurements for each of the 0 nonClifford layers in which there is at least one singlequbit rotation with an arbitrary angle rotation. 
Logical depth  608 
Number of logical cycles performed
This number is usually equal to the logical depth of the algorithm, which is 608. However, in the case in which a single T factory is slower than the execution time of the algorithm, we adjust the logical cycle depth to exceed the T factory’s execution time. 
Number of T states  800 
Number of T states consumed by the algorithm
To execute the algorithm, we require one T state for each of the 0 T gates, four T states for each of the 192 CCZ and 8 CCiX gates, as well as No rotations in algorithm for each of the 0 singlequbit rotation gates with arbitrary angle rotation. 
Number of T factories  11 
Number of T factories capable of producing the demanded 800 T states during the algorithm’s runtime
The total number of T factories 11 that are executed in parallel is computed as $\lceil {\displaystyle \frac{800\phantom{\rule{thickmathspace}{0ex}}\text{T states}\cdot 82us500ns\phantom{\rule{thickmathspace}{0ex}}\text{T factory duration}}{1\phantom{\rule{thickmathspace}{0ex}}\text{T states per T factory}\cdot 6ms80us\phantom{\rule{thickmathspace}{0ex}}\text{algorithm runtime}}}\rceil $ 
Number of T factory invocations  73 
Number of times all T factories are invoked
In order to prepare the 800 T states, the 11 copies of the T factory are repeatedly invoked 73 times. 
Physical algorithmic qubits  4200 
Number of physical qubits for the algorithm after layout
The 4200 are the product of the 84 logical qubits after layout and the 50 physical qubits that encode a single logical qubit. 
Physical T factory qubits  3960 
Number of physical qubits for the T factories
Each T factory requires 360 physical qubits and we run 11 in parallel, therefore we need $3960=360\cdot 11$qubits. 
Required logical qubit error rate  9.79e9 
The minimum logical qubit error rate required to run the algorithm within the error budget
The minimum logical qubit error rate is obtained by dividing the logical error probability 5.00e4 by the product of 84 logical qubits and the total cycle count 608. 
Required logical T state error rate  6.25e7 
The minimum T state error rate required for distilled T states
The minimum T state error rate is obtained by dividing the T distillation error probability 5.00e4 by the total number of T states 800. 
Number of T states per rotation  No rotations in algorithm 
Number of T states to implement a rotation with an arbitrary angle
The number of T states to implement a rotation with an arbitrary angle is $\lceil 0.53{\mathrm{log}}_{2}(0/0)+5.3\rceil $[arXiv:2203.10064]. For simplicity, we use this formula for all singlequbit arbitrary angle rotations, and do not distinguish between best, worst, and average cases. 
QEC scheme  surface_code 
Name of QEC scheme
You can load predefined QEC schemes by using the name 
Code distance  5 
Required code distance for error correction
The code distance is the smallest odd integer greater or equal to $\frac{2\mathrm{log}(0.08/0.000000009790100250626566)}{\mathrm{log}(0.0015/0.000001)}}1$ 
Physical qubits  50 
Number of physical qubits per logical qubit
The number of physical qubits per logical qubit are evaluated using the formula 2 * codeDistance * codeDistance that can be userspecified. 
Logical cycle time  10us 
Duration of a logical cycle in nanoseconds
The runtime of one logical cycle in nanoseconds is evaluated using the formula 20 * oneQubitMeasurementTime * codeDistance that can be userspecified. 
Logical qubit error rate  2.37e11 
Logical qubit error rate
The logical qubit error rate is computed as $0.08\cdot {\left({\displaystyle \frac{0.000001}{0.0015}}\right)}^{\frac{5+1}{2}}$ 
Crossing prefactor  0.08 
Crossing prefactor used in QEC scheme
The crossing prefactor is usually extracted numerically from simulations when fitting an exponential curve to model the relationship between logical and physical error rate. 
Error correction threshold  0.0015 
Error correction threshold used in QEC scheme
The error correction threshold is the physical error rate below which the error rate of the logical qubit is less than the error rate of the physical qubit that constitute it. This value is usually extracted numerically from simulations of the logical error rate. 
Logical cycle time formula  20 * oneQubitMeasurementTime * codeDistance 
QEC scheme formula used to compute logical cycle time
This is the formula that is used to compute the logical cycle time 10us. 
Physical qubits formula  2 * codeDistance * codeDistance 
QEC scheme formula used to compute number of physical qubits per logical qubit
This is the formula that is used to compute the number of physical qubits per logical qubits 50. 
Physical qubits  360 
Number of physical qubits for a single T factory
This corresponds to the maximum number of physical qubits over all rounds of T distillation units in a T factory. A round of distillation contains of multiple copies of distillation units to achieve the required success probability of producing a T state with the expected logical T state error rate. 
Runtime  82us 500ns 
Runtime of a single T factory
The runtime of a single T factory is the accumulated runtime of executing each round in a T factory. 
Number of output T states per run  1 
Number of output T states produced in a single run of T factory
The T factory takes as input 345 noisy physical T states with an error rate of 0.01 and produces 1 T states with an error rate of 2.52e7. 
Number of input T states per run  345 
Number of physical input T states consumed in a single run of a T factory
This value includes the physical input T states of all copies of the distillation unit in the first round. 
Distillation rounds  2 
The number of distillation rounds
This is the number of distillation rounds. In each round one or multiple copies of some distillation unit is executed. 
Distillation units per round  23, 1 
The number of units in each round of distillation
This is the number of copies for the distillation units per round. 
Distillation units  15to1 space efficient physical, 15to1 space efficient logical 
The types of distillation units
These are the types of distillation units that are executed in each round. The units can be either physical or logical, depending on what type of qubit they are operating. Spaceefficient units require fewer qubits for the cost of longer runtime compared to ReedMuller preparation units. 
Distillation code distances  1, 3 
The code distance in each round of distillation
This is the code distance used for the units in each round. If the code distance is 1, then the distillation unit operates on physical qubits instead of errorcorrected logical qubits. 
Number of physical qubits per round  276, 360 
The number of physical qubits used in each round of distillation
The maximum number of physical qubits over all rounds is the number of physical qubits for the T factory, since qubits are reused by different rounds. 
Runtime per round  4us 500ns, 78us 
The runtime of each distillation round
The runtime of the T factory is the sum of the runtimes in all rounds. 
Logical T state error rate  2.52e7 
Logical T state error rate
This is the logical T state error rate achieved by the T factory which is equal or smaller than the required error rate 6.25e7. 
Logical qubits (prelayout)  33 
Number of logical qubits in the input quantum program
We determine 84 from this number by assuming to align them in a 2D grid. Auxiliary qubits are added to allow for sufficient space to execute multiqubit Pauli measurements on all or a subset of the logical qubits. 
T gates  0 
Number of T gates in the input quantum program
This includes all T gates and adjoint T gates, but not T gates used to implement rotation gates with arbitrary angle, CCZ gates, or CCiX gates. 
Rotation gates  0 
Number of rotation gates in the input quantum program
This is the number of all rotation gates. If an angle corresponds to a Pauli, Clifford, or T gate, it is not accounted for in this number. 
Rotation depth  0 
Depth of rotation gates in the input quantum program
This is the number of all nonClifford layers that include at least one singlequbit rotation gate with an arbitrary angle. 
CCZ gates  192 
Number of CCZgates in the input quantum program
This is the number of CCZ gates. 
CCiX gates  8 
Number of CCiXgates in the input quantum program
This is the number of CCiX gates, which applies $iX$controlled on two control qubits [1212.5069]. 
Measurement operations  8 
Number of single qubit measurements in the input quantum program
This is the number of single qubit measurements in Pauli basis that are used in the input program. Note that all measurements are counted, however, the measurement result is is determined randomly (with a fixed seed) to be 0 or 1 with a probability of 50%. 
Total error budget  1.00e3 
Total error budget for the algorithm
The total error budget sets the overall allowed error for the algorithm, i.e., the number of times it is allowed to fail. Its value must be between 0 and 1 and the default value is 0.001, which corresponds to 0.1%, and means that the algorithm is allowed to fail once in 1000 executions. This parameter is highly application specific. For example, if one is running Shor’s algorithm for factoring integers, a large value for the error budget may be tolerated as one can check that the output are indeed the prime factors of the input. On the other hand, a much smaller error budget may be needed for an algorithm solving a problem with a solution which cannot be efficiently verified. This budget $\u03f5={\u03f5}_{\mathrm{log}}+{\u03f5}_{\mathrm{d}\mathrm{i}\mathrm{s}}+{\u03f5}_{\mathrm{s}\mathrm{y}\mathrm{n}}$is uniformly distributed and applies to errors ${\u03f5}_{\mathrm{log}}$to implement logical qubits, an error budget ${\u03f5}_{\mathrm{d}\mathrm{i}\mathrm{s}}$to produce T states through distillation, and an error budget ${\u03f5}_{\mathrm{s}\mathrm{y}\mathrm{n}}$to synthesize rotation gates with arbitrary angles. Note that for distillation and rotation synthesis, the respective error budgets ${\u03f5}_{\mathrm{d}\mathrm{i}\mathrm{s}}$and ${\u03f5}_{\mathrm{s}\mathrm{y}\mathrm{n}}$are uniformly distributed among all T states and all rotation gates, respectively. If there are no rotation gates in the input algorithm, the error budget is uniformly distributed to logical errors and T state errors. 
Logical error probability  5.00e4 
Probability of at least one logical error
This is one third of the total error budget 1.00e3 if the input algorithm contains rotation with gates with arbitrary angles, or one half of it, otherwise. 
T distillation error probability  5.00e4 
Probability of at least one faulty T distillation
This is one third of the total error budget 1.00e3 if the input algorithm contains rotation with gates with arbitrary angles, or one half of it, otherwise. 
Rotation synthesis error probability  0.00e0 
Probability of at least one failed rotation synthesis
This is one third of the total error budget 1.00e3. 
Qubit name  qubit_maj_ns_e6 
Some descriptive name for the qubit model
You can load predefined qubit parameters by using the names gate error rates). 
Instruction set  Majorana 
Underlying qubit technology (gatebased or Majorana)
When modeling the physical qubit abstractions, we distinguish between two different physical instruction sets that are used to operate the qubits. The physical instruction set can be either gatebased or Majorana. A gatebased instruction set provides singlequbit measurement, singlequbit gates (incl. T gates), and twoqubit gates. A Majorana instruction set provides a physical T gate, singlequbit measurement and twoqubit joint measurement operations. 
Singlequbit measurement time  100 ns 
Operation time for singlequbit measurement (t_meas) in ns
This is the operation time in nanoseconds to perform a singlequbit measurement in the Pauli basis. 
Twoqubit measurement time  100 ns 
Operation time for twoqubit measurement in ns
This is the operation time in nanoseconds to perform a nondestructive twoqubit joint Pauli measurement. 
T gate time  100 ns 
Operation time for a T gate
This is the operation time in nanoseconds to execute a T gate. 
Singlequbit measurement error rate  1E06 
Error rate for singlequbit measurement
This is the probability in which a singlequbit measurement in the Pauli basis may fail. 
Twoqubit measurement error rate  1E06 
Error rate for twoqubit measurement
This is the probability in which a nondestructive twoqubit joint Pauli measurement may fail. 
T gate error rate  0.01 
Error rate to prepare singlequbit T state or apply a T gate (p_T)
This is the probability in which executing a single T gate may fail. 
More details on the following lists of assumptions can be found in the paper Accessing requirements for scaling quantum computers and their applications.
Uniform independent physical noise. We assume that the noise on physical qubits and physical qubit operations is the standard circuit noise model. In particular we assume error events at different spacetime locations are independent and that error rates are uniform across the system in time and space.
Efficient classical computation. We assume that classical overhead (compilation, control, feedback, readout, decoding, etc.) does not dominate the overall cost of implementing the full quantum algorithm.
Extraction circuits for planar quantum ISA. We assume that stabilizer extraction circuits with similar depth and error correction performance to those for standard surface and HastingsHaah code patches can be constructed to implement all operations of the planar quantum ISA (instruction set architecture).
Uniform independent logical noise. We assume that the error rate of a logical operation is approximately equal to its spacetime volume (the number of tiles multiplied by the number of logical time steps) multiplied by the error rate of a logical qubit in a standard onetile patch in one logical time step.
Negligible Clifford costs for synthesis. We assume that the space overhead for synthesis and space and time overhead for transport of magic states within magic state factories and to synthesis qubits are all negligible.
Smooth magic state consumption rate. We assume that the rate of T state consumption throughout the compiled algorithm is almost constant, or can be made almost constant without significantly increasing the number of logical time steps for the algorithm.
«We have found the Resource Estimator simple to use despite the complexity of faulttolerant computing schemes. In this tool, resource estimates are neatly laidout at a glance, and hardware parameters and model assumptions can be easily tweaked. This kind of tool represents exactly what will be needed for designing largescale algorithms and computations that are more resourceefficient, which is a major focus of our work.», notes Jing Hao CHAI, Faulttolerant Quantum Computing Scientist at Entropica Labs.
To use the Resource Estimator in your daytoday quantum computing work, and especially to automate multiple resource estimation jobs, it may be more convenient to integrate it directly into your existing toolchains or workflows. In this blog post, we will we use the Azure Quantum Python library to write a Python tool that returns resource estimates in JSON format given as input a QIR program. The complete source code is available in this Gist.
With the tool it will be possible to generate physical resource estimates as simple as:
python estimate.py quantum_program.qir > resources.json
Let’s start by declaring some program arguments:
import argparse, os
parser = argparse.ArgumentParser(
prog="estimate",
description="Estimate physical resources using Azure Quantum")
parser.add_argument("filename", help="Quantum program (.ll, .qir, .bc)")
parser.add_argument("r", "resourceid",
default=os.environ.get("AZURE_QUANTUM_RESOURCE_ID"),
help="Resource ID of Azure Quantum workspace (must be set, unless set via \
environment variable AZURE_QUANTUM_RESOURCE_ID)")
parser.add_argument("l", "location",
default=os.environ.get("AZURE_QUANTUM_LOCATION)"),
help="Location of Azure Quantum workspace (must be set, unless set via \
environment AZURE_QUANTUM_LOCATION")
parser.add_argument("p", "jobparams", help="JSON file with job parameters")
args = parser.parse_args()
The Python tool takes a QIR program as input, which can be either in humanreadable LLVM code (.ll
and .qir
extension) or directly in bitcode (.bc
extension). The tool also requires information on how to connect with your Azure Quantum workspace, which can be either passed as program arguments or using environment variables. An Azure Quantum workspace allows us to access the resource estimator target and submit resource estimation jobs. If you do not have an Azure account, you can set one up for free here. If you do not have an Azure Quantum workspace, create one here. You will find the resource id and the location in the Overview page of your Azure Quantum workspace.
Next, we are connecting to our Azure Quantum workspace:
from azure.quantum import Workspace
workspace = Workspace(resource_id=args.resource_id, location=args.location)
The QIR program can be generated from other quantum programming languages like Q# (more details on generating QIR from Q#) and Qiskit (more details on generating QIR from Qiskit). If the QIR is provided in humanreadable LLVM code, we first need to translate it to LLVM bitcode via the PyQIR library:
from pyqir.generator import ir_to_bitcode
ext = os.path.splitext(args.filename)[1].lower()
if ext in ['.qir', '.ll']:
with open(args.filename, 'r') as f:
bitcode = ir_to_bitcode(f.read())
elif ext == '.bc':
with open(args.filename, 'rb') as f:
bitcode = f.read()
In addition to the quantum program, one can pass job parameters that model the assumed faulttolerant quantum computer. If no job parameters are specified, a default model is assumed. You can find more information on the job parameters in the Azure Quantum documentation. Job parameters can be provided through an optional JSON file such as the following:
{
"qubitParams": {"name": "qubit_maj_ns_e6"},
"qecScheme": {"name": "floquet_code"},
"errorBudget": 0.005
}
We read such a file using Python’s json
library:
import json
input_params = {}
if args.job_params:
with open(args.job_params, 'r') as f:
input_params = json.load(f)
Now that we have access to the Azure Quantum workspace, the QIR program, and the job parameters, we are ready to create and submit a resource estimation job:
from azure.quantum import Job
job = Job.from_input_data(
workspace=workspace,
name="Estimation job",
target="microsoft.estimator",
input_data=bitcode,
provider_id="microsoftqc",
input_data_format="qir.v1",
output_data_format="microsoft.resourceestimates.v1",
input_params=input_params
)
job.wait_until_completed()
Now all what is left to do is to extract the results from the job and print them in JSON format:
result = job.get_results()
print(json.dumps(result, indent=4))
The resulting output looks as follows:
{
// ...
"physicalCounts": {
"breakdown": {
"algorithmicLogicalDepth": 3479912,
"algorithmicLogicalQubits": 217,
"cliffordErrorRate": 0.001,
"logicalDepth": 3479912,
"numTfactories": 18,
"numTfactoryRuns": 242135,
"numTsPerRotation": 15,
"numTstates": 4358430,
"physicalQubitsForAlgorithm": 191394,
"physicalQubitsForTfactories": 599760,
"requiredLogicalQubitErrorRate": 4.4141872274122407e13,
"requiredLogicalTstateErrorRate": 7.648013925503755e11
},
"physicalQubits": 791154,
"runtime": 29231260800
},
// ...
}
Here are some ideas on what to try next:
The post Automate Resource Estimation with QIR appeared first on Q# Blog.
]]>The post Q# Holiday Calendar 2022 appeared first on Q# Blog.
]]>The rules are simple:
Looking forward to reading your Q# and Azure Quantum stories!
The post Q# Holiday Calendar 2022 appeared first on Q# Blog.
]]>