Q# Blog

As quantum algorithms grow more sophisticated, teams need powerful tools that support practical, scalable quantum development. With this release, Microsoft’s Quantum Development Kit takes a major step forward. QDK v1.27.0 delivers stronger insight into program behavior, richer developer tooling, and first-class program composability across Q#, Python, OpenQASM, and leading frameworks such as Qiskit and Cirq. QDK v1.27.0 improves how developers build, inspect, and assemble quantum programs, making it easier to iterate on complex algorithms using reusable components.   AI‑assisted quantum development is now a first‑class experience in the QDK, elevating quantum development across the entire workflow. Deep integration with Visual Studio Code and GitHub Copilot brings intelligent assistance to every stage, from code generation and circuit reasoning to debugging, visualization, hardware submission, and resource estimation. Enhanced circuit diagrams, quantum state inspection, and a streamlined VS Code experience make iteration and exploration faster, more reliable, and more interactive across Python, Jupyter, and Q#.   Alongside these core advances, QDK for Chemistry v1.1.0 expands what can be explored on today’s early fault‑tolerant hardware. In response to strong user demand, the release adds support for a broad family of model Hamiltonians, introduced through a systematic workflow that connects real molecular systems to reduced models such as the Fermi‑Hubbard Hamiltonian. Combined with stronger core primitives, deeper ecosystem integration, and a significantly faster classical pipeline, QDK for Chemistry enables practical chemistry and materials science experimentation today while laying the groundwork for larger‑scale quantum capabilities ahead.   Together, these updates advance quantum computing from basic research toward practical, hardware-aware quantum engineering.   Download Microsoft’s QDK and QDK for chemistry

At Microsoft, our quantum mission is clear: to build a scalable, fault-tolerant quantum computer capable of solving problems that are intractable for classical systems. Achieving this requires more than incremental progress—it demands breakthroughs in physics, engineering, and computer science. Our approach is rooted in topological quantum computing, a paradigm that promises inherent error resilience by encoding information in global properties of matter rather than local states.   Topological quantum computing offers a fundamentally different path to scalability, but realizing its full potential requires innovation across every layer of the stack. One promising direction is measurement-based quantum computing, which leverages adaptive measurements on entangled resource states to implement quantum logic. This approach could simplify control, enhance robustness, and accelerate the path to fault tolerance.   Introducing the 2026 Quantum Research Pioneers Program To advance this frontier, we are launching the 2026 Quantum Pioneers Program (QuPP). Through this program, we invite leading academic researchers to explore the next generation of measurement-based techniques for topological quantum computing.       Microsoft Quantum Pioneers Program Contest Official Rules   1. SPONSOR These Official Rules (“Rules”) govern the operation of the Microsoft Quantum Pioneers Program Contest (“Contest”). Microsoft Corporation, One Microsoft Way, Redmond, WA, 98052, USA, is the Contest sponsor (“Sponsor”).      2. DEFINITIONS In these Rules, “Microsoft”, “we”, “our”, and “us” refer to Sponsor and “you” and “yourself” refers to a Contest participant, or the parent/legal guardian of any Contest entrant who has not reached the age of majority to contractually obligate themselves in their legal place of residence. By entering you (your parent/legal guardian if you are not the age of majority in your legal place of residence) agree to be bound by these Rules.     3. ENTRY PERIOD The Contest starts at 12:00 a.m. Pacific Time (PT) on April 13, 2026, and ends at 11:59 p.m. PT on April 27, 2026 (“Entry Period”). The entry period is divided into two (2) Prize Periods, as follows:    Prize Period Start Date End Date 1 November 1, 2025, at 12:00 a.m. PT January 30, 2026, at 11:59 p.m. PT 2 April 13, 2026, at 12:00 a.m. PT April 27, 2026, at 11:59 p.m. PT     4. ELIGIBILITY This is a trade Contest open only to students (doctoral students, post-doc students, etc.) and professors (assistant, associate, etc.) at a university or degree-granting research institutions in the fifty (50) United States (including the District of Columbia and Puerto Rico). Applicants may only serve as principal investigator (“PI”) or co-PI on one (1) proposal submitted to Microsoft as part of the Quantum Pioneers Program each year. There can be a maximum of two (2) PIs per proposal. You must be twenty-one (21) years of age or older to be eligible. If you are twenty-one (21) years of age or older but have not reached the age of majority in your legal place of residence, then you must have consent of a parent/legal guardian to enter.    Employees and directors of Microsoft Corporation and its subsidiaries, affiliates, advertising agencies, and Contest Parties are not eligible, nor are persons involved in the execution or administration of this Contest, or the family members of each above (parents, children, siblings, spouse/domestic partners, or individuals residing in the same household). Void in Cuba, Iran, North Korea, Sudan, Syria, Region of Crimea, Russia, and where otherwise prohibited by law.     If you are participating in your capacity as an employee, it is your sole responsibility to comply with your employer’s gift policies. Microsoft will not be party to any disputes or actions related to this matter. PLEASE NOTE: If you are a public sector employee (government and education), all prize awards will be awarded directly to your public sector organization and subject to receipt of a gift letter signed by your agency/institution’s ethics officer, attorney, or designated executive/officer responsible for your organization’s gifts/ethics policy. Microsoft seeks to ensure that by offering items of value at no charge in promotional settings it does not create any violation of the letter or spirit of the entrant’s applicable gifts and ethics rules.      5. HOW TO ENTER To create an entry, create a five (5) page written proposal for research related to measurement-based quantum computing that includes:    Exploring at least one (1) of the following subject matter areas:  Novel simulation approaches to topological qubit dynamics  Explorations of novel readout and control techniques and components  Quantum error correction and circuit compilation for measurement-based approaches  Early fault-tolerant and NISQ experiments for measurement based approaches  Measurement-based methods for quantum characterization, verification, and validation (MB-QCVV)  A statement of need describing the specific outstanding challenge that is addressed by the research activity, that is, what the award funding will be used for;  The type and amount of collaboration needed or desired from Microsoft to perform the research activity;  Desired outcome of the research activity with expected impact on the field;  Facilities, materials, equipment, or other support available and/or needed to complete the proposed research; and  A short CV of the Principal Investigators (PI), not to exceed one (1) – tow (2) pages for each PI, should also be included in the proposal.    To submit an entry, send your written proposal by email to QPP@microsoft.com via an email with “ 2026 Quantum Pioneers Program” in the subject line during one of the Prize Periods.    The entry limit is one (1) per person overall. Any attempt by you to obtain more than the stated number of entries by using multiple/different accounts, identities, registrations, logins, or any other methods will void your entries and you may be disqualified. Use of any automated system to participate is prohibited.      We are not responsible for excess, lost, late, or incomplete entries. If disputed, entries will be deemed submitted by the “authorized account holder” of the email address. The “authorized account holder” is the natural person assigned to an email address by an internet or online service provider, or other organization responsible for assigning email addresses.       6. ELIGIBLE ENTRY To be eligible, an entry must meet the following content/technical requirements:     Your entry must be your own original work; and  Your entry cannot have been selected as a winner in any other contest; and  You must have obtained all consents, approvals, or licenses required for you to submit your entry; and  To the extent that entry requires the submission of user-generated content such as software, photos, videos, music, artwork, essays, etc., entrants warrant that their entry is their original work, has not been copied from others without permission or apparent rights, and does not violate the privacy, intellectual property rights, or other rights of any other person or entity. You may include Microsoft trademarks, logos, and designs, for which Microsoft grants you a limited license to use for the sole purposes of submitting an entry into this Contest; and  Your entry may NOT contain, as determined by us in our sole and absolute discretion, any content that is obscene or offensive, violent, defamatory, disparaging or illegal, or that promotes alcohol, illegal drugs, tobacco or a particular political agenda, or that communicates messages that may reflect negatively on the goodwill of Microsoft.      7. USE OF YOUR ENTRY We are not claiming ownership rights to your entry. However, by submitting an entry, you grant us an irrevocable, royalty-free, worldwide right and license to use, review, assess, test and otherwise analyze your entry and all its content in connection with this Contest and use your entry in any media whatsoever now known or later invented for any non-commercial or commercial purpose, including, but not limited to, the marketing, sale or promotion of Microsoft products or services, without further permission from you. You will not receive any compensation or credit for use of your entry, other than what is described in these Official Rules.    By entering you acknowledge that we may have developed or commissioned materials similar or identical to your entry and you waive any claims resulting from any similarities to your entry. Further, you understand that we will not restrict work assignments of representatives who have had access to your entry, and you agree that use of information in our representatives’ unaided memories in the development or deployment of our products or services does not create liability for us under this agreement or copyright or trade secret law.     8. WINNER SELECTION AND NOTIFICATION Pending confirmation of eligibility, potential prize winners will be selected by Microsoft, our designated agent, or a qualified judging panel from among all eligible entries received based on the following judging criteria:     33% – Faculty Merit: Faculty is accomplished in research and community engagement.  33% – Research Merit: Faculty’s proposed research is aligned with Microsoft Quantum interests, innovative, and likely to have a significant impact on the field.  33% – Proposal Quality: The research proposal is clear, focused, and well-organized, and it demonstrates the team’s ability to successfully execute the research and achieve a significant impact.    Potential winners will be selected within twenty-one (21) days following the Entry Period from among all eligible entries received. In the event of a tie between any eligible entries, an additional judge will break the tie based on the judging criteria described above. The decisions of the judges are final and binding. If we do not receive enough entries meeting the entry requirements, we may, at our discretion, select fewer winners than the number of Contest Prizes described below.    Potential winners will be notified via the contact information provided during entry no more than seven (7) days following judging with prize claim instructions, including submission deadlines. If a selected winner cannot be contacted, is ineligible, fails to claim a prize or fails to return any Forms, the selected winner will forfeit their prize and an alternate winner will be selected. If you are a potential winner and you are twenty-one (21) years of age or older but have not reached the age of majority in your place of legal residence, we may require your parent/legal guardian to sign all required forms on your behalf. Only three (3) alternate winners will be selected, after which unclaimed prizes will remain unawarded.        9. PRIZES The following prizes will be awarded:    At least one (1)* Grand Prize. Each winner will receive: A cash prize, to be awarded as a check to the winner’s educational institution (or if to the winner, if the winner is not affiliated with any institution) for the purpose of pursuing the research described in the winner’s submission. Approximate Retail Value (ARV) $200,000.00 USD.   *Microsoft may decide, in its sole and absolute discretion, to award up to four (4) additional prizes in the Entry Period for any reason.   PLEASE NOTE: If you are a public sector employee (government and education), your prize will be awarded as a research grant directly to your public sector organization and subject to receipt of a gift letter signed by your agency/institution’s ethics officer, attorney, or designated executive/officer responsible for your organization’s gifts/ethics policy. The ARV of electronic prizes is subject to price fluctuations in the consumer marketplace based on, among other things, any gap in time between the date the ARV is estimated for purposes of these Official Rules and the date the prize is awarded or redeemed. We will determine the value of the prize to be the fair market value at the time of prize award.   The total Approximate Retail Value (ARV) of all prizes is between $200,000.00-$1,000,000.00 USD, depending on the number of additional prizes awarded.   We will only award one (1) prize per person during the Entry Period. No more than the stated number of prizes will be awarded. No substitution, transfer, or assignment of prize permitted, except that Microsoft reserves the right to substitute a prize of equal or greater value in the event the offered prize is unavailable. Prizes are awarded “AS IS” and WITHOUT WARRANTY OF ANY KIND, express or implied (including but not limited to, any implied warranty of merchantability, fitness for a particular purpose, or non-infringement); you assume the entire risk of quality and performance, and should the prizes prove defective, you assume the entire cost of all necessary servicing or repair.    Prizes will be sent no later than twenty eight (28) days after winner selection. Prize winners may be required to complete and return prize claim and/or tax forms (“Forms”) within the deadline stated in the winner notification. Taxes on the prize, if any, are the sole responsibility of the winner, who is advised to seek independent counsel regarding the tax implications of accepting a prize. By accepting a prize, you agree that Microsoft may use your entry, name, image and hometown online and in print, or in any other media, in connection with this Contest without payment or compensation to you, except where prohibited by law.     10. ODDS The odds of winning are based on the number of eligible entries received.      11. GENERAL CONDITIONS AND RELEASE OF LIABILITY To the extent allowed by law, by entering you agree to release and hold harmless Microsoft and its respective parents, partners, subsidiaries, affiliates, employees, and agents from any and all liability or any injury, loss, or damage of any kind arising in connection with this Contest or any prize won.    All federal, state, and local laws and regulations apply. In the event of a dispute, the decisions of Microsoft are final and binding.    We reserve the right to cancel, change, or suspend this Contest for any reason without prior notice, including but not limited to, cheating, technology failure, catastrophe, war, or any other unforeseen or unexpected event that affects the integrity of this Contest, whether human or mechanical. If the integrity of the Contest cannot be restored, we may select winners from among all eligible entries received before we had to cancel, change or suspend the Contest.     If you attempt or we have strong reason to believe that you have compromised the integrity or the legitimate operation of this Contest by cheating, hacking, creating a bot or other automated program, or by committing fraud in any way, we may seek damages from you to the full extent of the law and you may be banned from participation in future Microsoft promotions.      12. GOVERNING LAW This Contest will be governed by the laws of the State of Washington, and you consent to the exclusive jurisdiction and venue of the courts of the State of Washington for any disputes arising out of this Contest.       13. PRIVACY Personal data you provide while entering this Contest will be used by Microsoft and/or its agents and prize fulfillers acting on Microsoft’s behalf only for the administration and operation of this Contest and in accordance with the Microsoft Privacy Statement.     14. WINNERS LIST Send an email to clarebozzo@microsoft.com with the subject line “Quantum Pioneers Program Contest winners” within thirty (30) days of April 22, 2026 to receive a list of winners that received a prize worth $25.00 USD or more.      

While the documentation (https://aka.ms/qdk) is a great resource to learn in detail about the Microsoft Quantum Development Kit (or “the QDK” for short), seeing it in action really helps convey just how simple it is to get started, the breadth of features it includes, and the power of the Q# language for developing quantum code.   With that in mind, the team that builds the QDK has put together a video where Mine Starks will give a brief tour of some of the main features of the QDK.   Enjoy!  

While the documentation (https://aka.ms/qdk) is a great resource to learn in detail about the Microsoft Azure Quantum Development Kit (or “the QDK” for short), seeing it in action really helps convey just how simple it is to get started, the breadth of features it includes, and the power of the Q# language for developing quantum code.   With that in mind, the team that builds the QDK has put together a video where Stefan Wernli will go more in-depth and walk through implementing an error correction algorithm using the quantum-specific Q# programming language included with the QDK.   Enjoy!  

While the documentation (https://aka.ms/qdk) is a great resource to learn in detail about the Microsoft Quantum Development Kit (or “the QDK” for short), seeing it in action really helps convey just how simple it is to get started, the breadth of features it includes, and the power of the Q# language for developing quantum code.   With that in mind, the team that builds the QDK has put together a video where Mine Starks will give a brief tour of some of the main features of the QDK.   Enjoy!  

This spring, we partnered with Quantum Coalition to offer a challenge at QRISE 2024. This six-week-long event aimed to connect students with quantum computing industry research challenges and help them get started doing research projects of their own.   The challenge we offered to the participants focused on resource estimation of quantum algorithms. Resource estimation helps us answer the question “How many physical qubits and how much time is necessary to execute a quantum algorithm under specific assumptions about the hardware platform used?” Getting these kinds of estimates serves multiple purposes: It allows us to deduce the conditions that quantum hardware needs to meet to offer practical quantum advantage. It helps us clarify which algorithms truly give quantum advantage over their classical counterparts, and which ones do not, and if they do, what problem instances get the advantage. It allows us to compare the efficiency of different algorithms that solve the same problem long before they become viable to run on quantum machines, thus enabling work on improving quantum algorithms. The goal of the challenge was to implement a quantum algorithm of participants’ choice and obtain and analyze the estimates of resources required for running it on future fault tolerant quantum computers using the Microsoft Azure Quantum Resource Estimator. This is exactly the kind of questions quantum algorithms researchers work on!   Let’s meet the winning teams and learn about their projects in their own words!   Team Qu-Cats Katie Harrison Muhammad Waqar Amin Nikhil Londhe Sarah Dweik Quantum approximate optimization problem (QAOA) is a quantum algorithm used to solve optimization problems. However, QAOA can only solve an optimization problem that can be formulated as a quadratic unconstrained bounded optimization (QUBO) problem. In this project, we have chosen to solve the Number Partitioning Problem (NPP) using QAOA. NPP involves partitioning a given set of numbers to determine whether it is possible to split them into two distinct partitions, where the difference between the total sum of numbers in each partition is minimum. This problem has applications in various fields, including cryptography, task scheduling, and VLSI design. This problem is also recognized for its computational difficulty, often described as the Easiest Hard Problem. In this project, we have accomplished two primary objectives. Initially, we determined the optimal QPU configuration to run QAOA. Subsequently, we conducted an analysis of resource estimates as we scaled the input size.   To determine the best setup for the quantum processing unit (QPU), we evaluated resources for eight different hardware setups, tracking variables like physical qubits, the fraction of qubits used by T-factories, and runtime, among others. The table below details results for the eight different configurations.     In addition, we conducted an analysis of resource estimates across a range of input variables. The plot below represents a segment of the analysis, primarily illustrating how the number of physical qubits varies with increasing input size.     Besides that, we have plotted other variables, such as algorithm qubits, partitions (in NPP), and T-factory qubits. We see that all variables increase as the input size increases. This is expected because from the QUBO cost function we require one bit for every element in the set. We also plotted the number of partitions that represents the scale of the problem for a particular input size. Interestingly, we notice that up to 12 elements, the number of partitions is higher than the number of physical qubits. This indicates that QAOA is at a severe disadvantage compared to the brute-force approach. However, as the number of elements continues to increase beyond 12, the growth in the number of physical qubits slows down.   Check out the team’s project!   Team Exponential Niraj Venkat   Integer factorization is a well-studied problem in computer science that is the core hardness assumption for the widely used RSA cryptosystem. It is part of a larger framework called the hidden subgroup problem which includes the discrete logarithm, graph isomorphism and the shortest vector problem. State-of-the-art classical algorithms that exist today, such as the number field sieve, can perform factorization in subexponential time. Shor’s algorithm is a famous result that has kicked off the search for practical quantum advantage. It showed that a sufficiently large, fault-tolerant quantum computer can factor integers in polynomial time. Recently, Regev published an algorithm that provides a polynomial speedup over Shor’s, without the need for fault-tolerance. Regev’s result leverages an isomorphism between factoring and the shortest vector problem on lattices, which had remained elusive for more than two decades.   This project provides resource estimates for different variants of Regev’s quantum circuit, by comparing state preparation routines and evaluating recent optimizations to quantum modular exponentiation. In scope for future work is the classical post-processing of the samples from the quantum circuit (more below).   The initial step of Regev’s quantum circuit prepares control qubits in a Gaussian superposition state. For n qubits, this is achieved by discretizing the domain of the Gaussian (normal) probability distribution into 2n equally spaced regions and encoding those cumulative probabilities as amplitudes of the quantum state. For example, here is a visualization of successive sampling of a Gaussian state over n = 4 qubits, plotted using the Q# Histogram:     As we add more shots, the histogram gradually adopts the shape of a bell curve. Such a visual test can be useful during development, especially when running on actual quantum hardware where the quantum state is not available for introspection. This project explores three different algorithms for Gaussian state preparation: Q# library PreparePureStateD Arbitrary state preparation by Möttönen et al., similar to above where the amplitudes for each basis state are specified Grover-Rudolph state preparation which is meant specifically for probability distributions like the Gaussian, and does not require amplitudes as input In the resource estimation of the overall quantum circuit, we use the fastest method from the three listed here, namely inlinecode PreparePureStateD inlinecode, to initialize the Gaussian state.   The next step of Regev’s quantum circuit is modular exponentiation on small primes. This project implements two different algorithms: Binary exponentiation used in Regev’s original paper Fibonacci exponentiation with the Zeckendorf representation of integers, using a fast algorithm for Fibonacci number calculation Regev’s algorithm uses the quantum computer to sample a multidimensional lattice. In terms of complexity analysis, Gaussian states have properties that work well on such lattices. However, it is unclear whether a Gaussian state is actually required in practice. For this reason, our test matrix looks like this:     Quantum modular exponentiation algorithm used Control register state preparation algorithm used Fibonacci exponentiation with uniform superposition Binary exponentiation with uniform superposition Fibonacci exponentiation with Gaussian superposition Binary exponentiation with Gaussian superposition   Here are the resource estimation results for different variants of the factoring circuit for N = 143:     The overall winner is Fibonacci exponentiation with a uniform distribution over the control qubits. In this analysis, the size of the control register is fixed to 20 logical qubits for all the four profiles being tested. Preparing a uniform superposition is just a layer of Hadamard gates, which is the same for all problem sizes N. This is clearly advantageous over Gaussian state preparation, where the radius of the Gaussian state required increases exponentially with N.   This project is focused on quantum resource estimation, and for these purposes the classical post-processing of the samples from the quantum circuit is not required. However, this is required for a complete implementation of Regev’s algorithm. Current work includes investigation of lattice reduction techniques, followed by filtering of corrupted samples and fast classical multiplication in order to compute a prime factor. Other state preparation algorithms in the literature – including ones specific to Gaussian states – may also prove beneficial by reducing the gate complexity and number of samples required from the quantum circuit.   Check out the team’s project!

Introduction Some quantum computers can do more than execute a static sequence of gates. The most advanced ones can perform mid-circuit measurements, conditionally execute gates, perform real-time classical computations and re-use qubits. If you want to experiment with these state-of-the-art capabilities, we have good news for you. The Microsoft Quantum Development Kit now supports running hybrid quantum programs on hardware targets. This kind of program combines classical and quantum computations; thus, we refer to them as hybrid quantum programs.   Last year, we released Azure Quantum’s Integrated Hybrid feature, enabling users to develop their hybrid quantum programs using Q# and the QDK. Since then, we have modernized the QDK, but the initial release did not have support for this feature. After months of dedicated development, we are excited to announce that the QDK again has support for implementing hybrid quantum programs!   Not only have we added support for these advanced capabilities, but we have also made significant improvements to the development experience, and users now have: More detailed and comprehensive design-time feedback. Support for a wider range of Q# features when creating hybrid quantum programs. Optimized compilation for running on quantum hardware. Increased execution reliability on programs submitted to run on quantum computers via the Azure Quantum service. Integrated Hybrid Unlocks New Possibilities Hybrid quantum computing refers to the process and architecture of a classical computer and a quantum computer working together to solve a problem. Integrated hybrid quantum computing is a specific kind of architecture that allows classical computations to be performed while qubits are coherent. This capability in combination with mid-circuit measurement enables features like branching based on measurement and real-time integer computations. These features represent a step forward in the use of high-level programming constructs in quantum applications, opening the door to a new generation of hybrid algorithms such as adaptive phase estimation, return-until–success, and some quantum error correction schemes.   At its most basic form, integrated hybrid quantum computing enables you to perform different operations based on the results from a qubit measurement. For example, the following code snippet conditionally applies an X operation to one qubit if the result of the measurement of another qubit is One:   namespace MyQuantumHybridProgram { @EntryPoint() operation Main() : Result { use qs = Qubit[2]; H(qs[0]); if MResetZ(qs[0]) == One { X(qs[1]); } return MResetZ(qs[1]); } }   Conditionally applying quantum gates based on measurement results is a feature that can be used for error correction. You can imagine how you can perform syndrome measurement and based on it apply the appropriate corrections.   You can also use other familiar Q# constructs such as loops and even integer computations that are performed while qubits are coherent. For example, the following program keeps track of how many times a measurement resulted in One and returns a Bool representing whether the count is an even number. Moreover, the program also takes advantage of another hybrid quantum computing feature, qubit re-use, which allows us to just use one qubit instead of the five that would be otherwise required. Note that all of this is automatically handled by the Q# compiler.   namespace MyQuantumHybridProgram { @EntryPoint() operation Main() : Bool { use q = Qubit(); mutable count = 0; let limit = 5; for _ in 1..limit { // Here we take advantage of an integrated // hybrid capability, qubit re-use, so we // can repeat this logic many times without // having to use a different qubit each time. H(q); if MResetZ(q) == One { set count += 1; } } return count % 2 == 0; } }   The ability to perform different computations, either classical or quantum, opens the door to the development of new innovative algorithms that are inherently hybrid.   Configuring the QDK You can run hybrid quantum programs both from Visual Studio Code and Python. In both cases, when working with a Q# program, select QIR Adaptive RI as the Q# target profile. This will enable the QDK to provide accurate design-time feedback. Diving into the details of the QIR Adaptive RI profile: QIR stands for Quantum Intermediate Representation, which is the program representation that the Q# compiler produces. Adaptive is the specific QIR profile. Profiles are defined in the QIR specification and represent a coherent subset of functionality that quantum targets support. RI stands for qubit re-use and integer computations respectively, which are extensions to the QIR Adaptive profile. Currently, Quantinuum is the only provider in Azure Quantum that supports integrated hybrid quantum computing, so make sure you submit your programs to their targets.   The Q# Compiler Guides You Once you have set up the Q# target profile, the QDK provides design-time feedback about Q# patterns that are not supported by the chosen quantum target.   Let’s look at an example of the kind of feedback the QDK provides. Consider the following code snippet:   namespace MyHybridQuantumProgram { @EntryPoint() operation Main() : Int { use q = Qubit(); H(q); let result = MResetZ(q); // We use the measurement result to determine // the value of variables of different types. // We refer to these variables and values as dynamic. // Dynamic Bool and Int values are supported by the // QIR Adaptive RI profile. let dynamicBool = result == One ? true | false; let dynamicInt = result == Zero ? 0 | 1; // Dynamic Double values are not supported by the // QIR Adaptive RI profile so the following line // will result in a compilation error. let dynamicDouble = result == Zero ? 0. | 1.; // The QIR Adaptive RI profile supports returning // dynamic values of type Result, Bool and Int. return dynamicInt; } }   In this program, we use a qubit measurement to determine the value of Bool, Int, and Double variables. Since both dynamic Bool and Int values are supported by the QIR Adaptive RI profile, the compiler does not produce any errors in the lines of code where the dynamicBool and dynamicInt variables are bound. However, since dynamic Double values are not supported by this same profile, the compiler produces an error like the following in the line of code where the dynamicDouble variable is bound:     This is just one example of how the Q# compiler provides design-time feedback to guide you on what kind of programs integrated hybrid targets can execute. The accuracy and usefulness of the feedback has significantly improved compared to the previous QDK, in which the compiler could not determine whether it was possible to execute a program on a quantum target before its submission. With the latest version of the QDK, programs execute more reliably when submitted to Azure Quantum targets.   The Q# Compiler Optimizes Your Program for Running on Quantum Hardware Another improvement that we have made is that we heavily optimize classical computations that do not need to be executed during coherence time. For example, in the following code snippet the loop limit calculation is relatively complex. Even though integer computation support makes it possible to perform this calculation while qubits are coherent, the program does not strictly require it. Since computing resources on current quantum computers are limited, the Q# compiler pre-computes anything that it can to reduce the number of computations that the quantum computer needs to perform, no matter the data type. In this program, the compiler computes the value of the limit variable, unrolls the loop and computes the value of angle for each iteration.   namespace MyHybridQuantumProgram { open Microsoft.Quantum.Convert; open Microsoft.Quantum.Math; @EntryPoint() operation Main() : Result { use q = Qubit(); let seed = 42; let limit = ((seed + 10) % 5) * (seed ^ 2); for idx in 0 .. limit { let angle = IntAsDouble(idx) * PI(); Rx(angle, q); } return MResetZ(q); } }   Give It a Try If you want to experiment with the most advanced capabilities quantum devices currently offer, install the Microsoft Quantum Development Kit VS Code Extension or install the qsharp Python package, and start implementing your own quantum hybrid programs. You can get inspiration to develop your own hybrid quantum algorithms from our samples and experiments. We are excited to see what you can accomplish!

Introduction Some quantum computers can do more than execute a static sequence of gates. The most advanced ones can perform mid-circuit measurements, conditionally execute gates, perform real-time classical computations and re-use qubits. If you want to experiment with these state-of-the-art capabilities, we have good news for you. The Microsoft Quantum Development Kit now supports running hybrid quantum programs on hardware targets. This kind of program combines classical and quantum computations; thus, we refer to them as hybrid quantum programs.   Last year, we released Azure Quantum’s Integrated Hybrid feature, enabling users to develop their hybrid quantum programs using Q# and the QDK. Since then, we have modernized the QDK, but the initial release did not have support for this feature. After months of dedicated development, we are excited to announce that the QDK again has support for implementing hybrid quantum programs!   Not only have we added support for these advanced capabilities, but we have also made significant improvements to the development experience, and users now have: More detailed and comprehensive design-time feedback. Support for a wider range of Q# features when creating hybrid quantum programs. Optimized compilation for running on quantum hardware. Increased execution reliability on programs submitted to run on quantum computers via the Azure Quantum service. Integrated Hybrid Unlocks New Possibilities Hybrid quantum computing refers to the process and architecture of a classical computer and a quantum computer working together to solve a problem. Integrated hybrid quantum computing is a specific kind of architecture that allows classical computations to be performed while qubits are coherent. This capability in combination with mid-circuit measurement enables features like branching based on measurement and real-time integer computations. These features represent a step forward in the use of high-level programming constructs in quantum applications, opening the door to a new generation of hybrid algorithms such as adaptive phase estimation, return-until–success, and some quantum error correction schemes.   At its most basic form, integrated hybrid quantum computing enables you to perform different operations based on the results from a qubit measurement. For example, the following code snippet conditionally applies an X operation to one qubit if the result of the measurement of another qubit is One:   namespace MyQuantumHybridProgram { @EntryPoint() operation Main() : Result { use qs = Qubit[2]; H(qs[0]); if MResetZ(qs[0]) == One { X(qs[1]); } return MResetZ(qs[1]); } }   Conditionally applying quantum gates based on measurement results is a feature that can be used for error correction. You can imagine how you can perform syndrome measurement and based on it apply the appropriate corrections.   You can also use other familiar Q# constructs such as loops and even integer computations that are performed while qubits are coherent. For example, the following program keeps track of how many times a measurement resulted in One and returns a Bool representing whether the count is an even number. Moreover, the program also takes advantage of another hybrid quantum computing feature, qubit re-use, which allows us to just use one qubit instead of the five that would be otherwise required. Note that all of this is automatically handled by the Q# compiler.   namespace MyQuantumHybridProgram { @EntryPoint() operation Main() : Bool { use q = Qubit(); mutable count = 0; let limit = 5; for _ in 1..limit { // Here we take advantage of an integrated // hybrid capability, qubit re-use, so we // can repeat this logic many times without // having to use a different qubit each time. H(q); if MResetZ(q) == One { set count += 1; } } return count % 2 == 0; } }   The ability to perform different computations, either classical or quantum, opens the door to the development of new innovative algorithms that are inherently hybrid.   Configuring the QDK You can run hybrid quantum programs both from Visual Studio Code and Python. In both cases, when working with a Q# program, select QIR Adaptive RI as the Q# target profile. This will enable the QDK to provide accurate design-time feedback. Diving into the details of the QIR Adaptive RI profile: QIR stands for Quantum Intermediate Representation, which is the program representation that the Q# compiler produces. Adaptive is the specific QIR profile. Profiles are defined in the QIR specification and represent a coherent subset of functionality that quantum targets support. RI stands for qubit re-use and integer computations respectively, which are extensions to the QIR Adaptive profile. Currently, Quantinuum is the only provider in Azure Quantum that supports integrated hybrid quantum computing, so make sure you submit your programs to their targets.   The Q# Compiler Guides You Once you have set up the Q# target profile, the QDK provides design-time feedback about Q# patterns that are not supported by the chosen quantum target.   Let’s look at an example of the kind of feedback the QDK provides. Consider the following code snippet:   namespace MyHybridQuantumProgram { @EntryPoint() operation Main() : Int { use q = Qubit(); H(q); let result = MResetZ(q); // We use the measurement result to determine // the value of variables of different types. // We refer to these variables and values as dynamic. // Dynamic Bool and Int values are supported by the // QIR Adaptive RI profile. let dynamicBool = result == One ? true | false; let dynamicInt = result == Zero ? 0 | 1; // Dynamic Double values are not supported by the // QIR Adaptive RI profile so the following line // will result in a compilation error. let dynamicDouble = result == Zero ? 0. | 1.; // The QIR Adaptive RI profile supports returning // dynamic values of type Result, Bool and Int. return dynamicInt; } }   In this program, we use a qubit measurement to determine the value of Bool, Int, and Double variables. Since both dynamic Bool and Int values are supported by the QIR Adaptive RI profile, the compiler does not produce any errors in the lines of code where the dynamicBool and dynamicInt variables are bound. However, since dynamic Double values are not supported by this same profile, the compiler produces an error like the following in the line of code where the dynamicDouble variable is bound:     This is just one example of how the Q# compiler provides design-time feedback to guide you on what kind of programs integrated hybrid targets can execute. The accuracy and usefulness of the feedback has significantly improved compared to the previous QDK, in which the compiler could not determine whether it was possible to execute a program on a quantum target before its submission. With the latest version of the QDK, programs execute more reliably when submitted to Azure Quantum targets.   The Q# Compiler Optimizes Your Program for Running on Quantum Hardware Another improvement that we have made is that we heavily optimize classical computations that do not need to be executed during coherence time. For example, in the following code snippet the loop limit calculation is relatively complex. Even though integer computation support makes it possible to perform this calculation while qubits are coherent, the program does not strictly require it. Since computing resources on current quantum computers are limited, the Q# compiler pre-computes anything that it can to reduce the number of computations that the quantum computer needs to perform, no matter the data type. In this program, the compiler computes the value of the limit variable, unrolls the loop and computes the value of angle for each iteration.   namespace MyHybridQuantumProgram { open Microsoft.Quantum.Convert; open Microsoft.Quantum.Math; @EntryPoint() operation Main() : Result { use q = Qubit(); let seed = 42; let limit = ((seed + 10) % 5) * (seed ^ 2); for idx in 0 .. limit { let angle = IntAsDouble(idx) * PI(); Rx(angle, q); } return MResetZ(q); } }   Give It a Try If you want to experiment with the most advanced capabilities quantum devices currently offer, install the Microsoft Quantum Development Kit VS Code Extension or install the qsharp Python package, and start implementing your own quantum hybrid programs. You can get inspiration to develop your own hybrid quantum algorithms from our samples and experiments. We are excited to see what you can accomplish!

Introduction This blog post highlights a recent collaboration between Microsoft and Alice & Bob, a French startup whose goal is to build a fault-tolerant quantum computer by leveraging a superconducting qubit called a cat qubit. In this collaboration, Alice & Bob uses the new extensibility mechanisms of Microsoft’s Resource Estimator to obtain resource estimates for their cat qubit architecture.   The Resource Estimator is a tool that can help evaluate the practical benefit of quantum algorithms. It calculates an estimate for the expected runtime and the number of physical qubits needed to run a given program under different settings of the target fault-tolerant quantum computer. The default settings of the resource estimator represent generic gate-based and Majorana-based qubits, unbiased planar quantum error correction codes (i.e., 2D layout for logical qubits assuming the same error rates for bit flip and phase flip errors) that support lattice surgery, and T factories that use multiple rounds of distillation (please refer to this paper for more details on these assumptions). These settings cover many quantum computing architectures, but they do not have complete flexibility for quantum architects to model various other important system architectures with different assumptions.   Microsoft is happy to announce that the Resource Estimator, which was made open source in January 2024, now has an extensibility API to model any quantum architecture and to modify all assumptions. To show how this extensibility API works, Microsoft and Alice & Bob demonstrate how it is used to model Alice & Bob’s cat qubit architecture, along with a biased repetition code, and Toffoli factories. The open-source example performs the resource estimation for elliptic curve cryptography described in Alice & Bob’s Physical Review Letters paper from July 2023.   Architecture Cat qubits have special error correction requirements because they exhibit a biased noise: they have several orders of magnitude less bit flips than phase flips. They use engineered two photon dissipation to stabilize two coherent states of the same amplitude and opposite phase, used as the 0 and 1 of the qubits. The Alice & Bob roadmap takes advantage of this asymmetry to simplify the error correction strategy. To achieve this however, the usual hierarchy of gates used in quantum computing has to be modified. As a first step, we need to build a gate set that protects this noise-biasing property. And then, from this set, they have to offer a universal set of fault-tolerant operations (note that the bias-preserving gate set is typically not universal, but sufficient to implement a universal gate set at the logical level). This work is carried in the article Repetition Cat Qubits for Fault-Tolerant Quantum Computation and summarized in the figure below.     Alice & Bob’s architecture highlights the importance of extensibility in the Resource Estimator and the ability to override the pre-defined settings. The typical error correction code, used by the Resource Estimator, is the surface code, but cat qubits require a repetition code. The Resource Estimator assumes a “Clifford+T” universal gate set, while the gate set presented above for cat qubits is “Clifford+Toffoli.”   Implementation details   The resource estimator, which is written in Rust, can be extended by using a Rust API. The main function of the resource estimator is to calculate the physical resource estimates for a logical overhead with respect to an error correction protocol, a physical qubit, and a factory builder. The interaction of these components is illustrated in the architecture diagram above. Each of these components are interfaces that can be implemented, which allows full flexibility. For instance, the resource estimator doesn’t have to know about the input program, or even the layout method. It only needs the logical overhead, which gives the number of logical qubits, the logical depth, and the number of needed magic states. Likewise, the implementations of the other interfaces provide information for the resource estimation. We will explain some aspects of the implementation in the remainder of this section but please refer to the example source code in GitHub for more details.   The error correction protocol in the Resource Estimator defines both the physical qubit and the code parameter that it uses. For most codes, the code parameter is the code distance, and finding a value for the code distance that ensures a desired logical error rate given a physical qubit is one of the main goals of the error correction protocol. The Alice & Bob architecture uses a repetition code with two parameters: distance and the average number of photons. The distance deals with the phase flip error and the number of photons must be high enough to avoid bit flip errors, so that the repetition code can focus on correcting only the phase flip errors.   A factory builder’s job is to make magic state factories that produce magic states with a certain maximum output error probability. The factories can be either pre-computed or they can be calculated as needed, when a new request is made. Also, they can use the error correction protocol and select their own code parameters to make the factories. For Alice & Bob’s architecture, the magic state that is produced is CCX and there’s a pre-computed list of Toffoli factories available (see also Table 3 in the paper).   We make two main assumptions about the input program: that it uses mostly CX (or CNOT) and CCX (or Toffoli) gates, and that they aren’t run in parallel, but each have their own cycle time (i.e., the number of needed error correction syndrome extraction cycles). With these assumptions, and the number of logical algorithm qubits before taking into account the layout, we can easily calculate the layout overhead as a function of the number of logical qubits and the number of CX and CCX gates. Moreover, the paper from Alice & Bob gives formulas to find values for these three metrics for the elliptic curve cryptography algorithm, and so the layout overhead can be generated as a function of the key size and some implementation details (such as the window size for windowed arithmetic). Moreover, we use the Microsoft Quantum Development Kit (QDK) to compute a logical overhead by evaluating a Q# program.     The above graph compares the space-time trade-off of resource estimates using the resource estimator and the estimates from the paper. The paper reported a quicker solution that needed more qubits, while the resource estimator produced estimates with fewer qubits and a longer, but feasible, runtime. Note that the resource estimator does not automatically explore application specific parameters (such as window sizes for windowed arithmetic).   Next steps You can try out and execute the Alice & Bob resource estimation example that uses Microsoft’s Resource Estimator. As it is open source, you can easily change the application input. The cost model that relies on CX and CCX gates is compatible with many logical resource estimation research papers in the literature, and therefore results from those papers can be quickly converted into physical resource estimates. Further, you can examine various Q# programs that are available in the Q# GitHub repository. We hope that the resource estimator gives you useful insights and helps your research; and we would welcome your feedback.

Introduction If you’ve been exploring quantum programming using Q#, you may have been thinking, “This language is great and so easy to use! But what about visual learners?”   I’m a software engineer in the for Microsoft Quantum Development Kit team, and I’m very excited to share a new feature I’ve been working on: circuit visualization in Q#.   One of the neat things about Q# is that it gives you the ability to express quantum algorithms in a procedural language that’s reminiscent of classical programming languages such as C and Python. If you’re already a programmer, this way of thinking will be very intuitive to you, and you can get started with quantum computing right away (if you haven’t done so yet, check out our quantum katas).   However, this isn’t how many people learn about quantum computing today. If you flip through any quantum computing textbook, you’ll see that it’s conventional to think in terms of quantum circuits.   We wanted to bridge the gap between these two different modes of thinking.   Getting Started If you open any Q# program in VS Code, you’ll notice a little “Circuit” CodeLens above the entry point declaration. When you click on that, your Q# program will be represented as a quantum circuit diagram.     Being able to go from Q# code to circuit diagrams means that you can use familiar constructs such as inlinecode for inlinecode loops and inlinecodeif inlinecode statements in your program to manipulate the quantum state while being able to view the logical circuit at any time to get a high-level view of your algorithm.     How does this work? The quantum circuit for a Q# program is generated by executing all the classical parts of the program while keeping track of when qubits are allocated and which quantum gates are applied. This data is then displayed as a quantum circuit.   Not all quantum programs can be represented as straightforward quantum circuits. What if we have a dynamic (commonly known as “adaptive”) circuit? Say we have a inlinecodewhile inlinecode loop in our program that compares measurement results and takes an action that depends on the result. The exact set of gates in the program will not be deterministic anymore.   That’s when we need to run the program through the quantum simulator. This is called “trace” mode since we’re tracing the quantum operations as they are actually performed in the simulator. When the circuit visualizer detects that the program contains measurement comparisons, this mode is activated.     Depending on your luck, you may end up with two gates, or you may end up with many more!     Each time you generate the circuit, you may see a different outcome in the circuit diagram.   It would certainly be nice to visualize all the outcomes at once, and we’re working through some ideas on how to do that. Simple conditionals can be represented as gates controlled by classical wires. But given a language as expressive as Q#, you can write complex conditionals that are difficult to visualize on a single 2-D circuit diagram. How would you represent an adaptive circuit such as the one above? We’d love to hear your ideas. You can leave a comment here or on this GitHub issue.   Reflections Working on this feature sparked a lot of lively debate within the team, especially during the design stage. We’re a team with diverse technical backgrounds. Some of us found it very intuitive to think in terms of circuits. Others preferred reading code and thought circuit diagrams were very limiting. Did we even need the feature at all?   I now realize it’s not either-or: it’s very powerful to be able to do both. Even if you prefer one paradigm over the other, being able to inspect your code through different lenses really deepens your understanding of the problem you’re working on. You can run simulations and look at a histogram of the results. You can step through the code using the Q# debugger. And now you can view it as a circuit diagram. Each different view into the problem offers a different insight.   This is also why testing this feature was so fun for me. I’m far from an expert in quantum computing; some of our Q# samples are admittedly still confusing to me. As I ran the circuit visualizer on each sample, giving it a final look-over, I found the process unexpectedly satisfying. I felt like I was finally starting to understand what these algorithms were doing. I’m happy for this new addition to my learning toolkit!   Your own quantum circuit diagrams If you’d like to try out Q# circuit diagrams for yourself, head over to The Azure Quantum Playground and give it a try now – no installation necessary. When you’re ready to work on your own Q# projects, install the Microsoft Quantum Development Kit VS Code Extension. If you prefer working in Python, head over to the documentation for instructions on how to get started in Jupyter Notebooks. Let us know what you think!