The post Introducing the Azure Quantum Development Kit Preview appeared first on Q# Blog.
]]>The Azure Quantum team is excited to announce the initial preview of the new Azure Quantum Development Kit (or QDK for short). This has been entirely rebuilt using a new codebase on a new technology stack, and this blog post outlines the why, the how, and some of the benefits of doing so.
The “tl;dr” is that we rewrote it (mostly) in Rust which compiles to WebAssembly for VS Code or the web, and to native binaries for Python. It’s over 100x smaller, over 100x faster, much easier to install & use, works fully in the browser, and is much more productive & fun for the team to work on.
Give it a try via the instructions at https://github.com/microsoft/qsharp/wiki/Installation, and read on for the details…
The existing Quantum Development Kit has grown organically over several years, first shipping in late 2017. Being in a fastevolving space, it naturally evolved quickly too, incorporating many features and technologies along the way.
As we reflected on what we’d like the QDK to be going forward, it was clear some of the technologies and features would be a challenge to bring along, and that a rewrite might be the best solution. Some of our goals were:
Many quantum developers don’t come from a .NET background, being mostly familiar with Python. However, the existing QDK exposes much of the .NET ecosystem to developers, providing an additional learning curve. Some examples being the MSBuildbased project & build system and NuGet package management. When working with customers on issues, they will sometimes be confused when needing to edit .csproj files, run commands such as “dotnet clean”, or troubleshoot NuGet packages for their Q# projects.
Providing a delightful & simplified experience, from installation to learning to coding to troubleshooting to submitting jobs to quantum computers is our primary goal.
The existing QDK has some code and dependencies that are platform specific. While these were not problems initially, as platforms have evolved this has caused challenges. For example, Apple Silicon and Windows on ARM64 are not fully supported in the existing QDK. We also wanted the tools to run in the browser, such as in our new https://quantum.microsoft.com portal, or in a https://vscode.dev hosted editor.
With the runtime dependencies in the existing QDK, the full set of binaries that need to be installed has grown quite large. Besides the .NET runtime itself, there are some F# library dependencies in the parser, some C++ multithreading library dependencies in the simulator, some NuGet dependencies for the Q# project SDK, etc. In total, this can add up to over 180MB when installed locally after building a simple Q# project. Coordinating the download and initialization of the binaries, as well as the complexity of the interactions between them, can often lead to performance & reliability issues.
As the existing QDK had come to span multiple repositories, multiple build pipelines, multiple languages & runtimes (each often with their own set of dependencies), and multiple distribution channels, the speed at which we could check in a feature or produce a release has slowed, and a great deal of time is spent on codebase maintenance, security updates, and troubleshooting build issues. To provide a productive (and enjoyable) engineering system going forward, dramatic simplification was needed.
Around the end of 2022 we set about prototyping some ideas, which grew into the new QDK we are releasing in preview today. The basic philosophy behind engineering the new QDK is as follows:
By writing as much as possible in Rust, we have a codebase that can easily target native binaries for any platform supported by the Rust compiler (which we build into our Python wheels) and build for WebAssembly (via wasmbindgen) to run in the browser. With a focused codebase, the resulting binaries are very small & fast too.
There is a cost to every dependency you take. The cost to learn it, the cost to install it (i.e., build times and disk space), the cost to update & maintain it (i.e., as security issues are reported), the cost to final product size, and so on. Sometimes these costs are worth paying for what you get in return, but the taxes accumulate over time. We are very mindful and minimal in the dependencies we take.
For our new codebase, we have limited the languages used to:
For those three languages, we keep dependencies to a minimum, nearly all of which can be seen in the Cargo.toml and package.json files at the root of the repo.
The below highlevel diagram shows roughly how this all fits together in our VS Code extension, Python packages, and for general web site integration.
Setting up a build environment for developers (or CI agents) should be fast. For the new codebase, currently you just install Rust, Python, and Node.js, clone one repo, and run one Python build script.
Developing the product should be fast. When working on the core compiler Rust code, the development innerloop is often as fast as clicking ‘run’ on a unit test in VS Code via the excellent “rustanalyzer” extension. When working on the TypeScript code for the VS Code extension, with “esbuild” running in watchmode it’s as quick as saving the changes and pressing F5 to launch the Extension Development Host.
The build infrastructure should be easy to keep working. Our CI and build pipeline use the same ‘build.py’ script in the root of the repo that developers use locally to build & test.
Last but certainly not least, is to avoid the extraneous. Every feature added should have a clear need and add significant value. This provides for a more streamlined & intuitive product for the customer, and a less complex codebase to do further development in.
We’re pretty proud of the result. It’s no exaggeration to say the new Azure Quantum Development Kit is 100x smaller, 100x faster, available on Windows, Mac, Linux, and the web, and is a greatly simplified user experience.
As outlined above, the existing QDK results in over 180MB of binaries locally once a project is fully built and all dependencies installed. The VSIX package for our new VS Code extension is currently around 700KB and includes everything needed for Q# development in VS Code. (If you ‘pip install’ our Python packages to work with Q# via Python, that’s around another 1.3MB). Installation typically takes a couple of seconds with no other dependencies. If you have VS Code, (and Python/Jupyter if desired), you’re ready to install.
We have examples of programs that would take minutes to compile in the existing QDK. Those same programs are now measured in milliseconds in the new QDK. The language service is so fast, most operations are done on every keystroke and feel instant. The simulator can run 1000s of ‘shots’ per second for many common algorithms on a good laptop.
The build pipelines for the existing QDK take between 2 – 3 hours to complete, are fragile, and issues often require coordinated checkins across multiple repos. For the new QDK, all code is in one repo, and we build, test, and push live to our online playground in around 10 mins on every commit to main. Our publishing pipeline uses largely the same script.
We’ve built an extremely fast & reliable installation, language service, compiler, and debugger. Oh, and it all works inside the browser too!
A couple of years ago VS Code introduced VS Code for the Web (https://code.visualstudio.com/docs/editor/vscodeweb), with the ability to run the IDE in a browser with no local install, such as at https://vscode.dev or by pressing “.” when in a GitHub repo. By building our extension entirely as a web extension ALL our features run equally well in VS Code desktop or in the browser.
By way of example, the below screenshot shows loading the editor in the browser by visiting https://vscode.dev, running a Q# file under the debugger, viewing the quantum simulator output in the Debug Console, while also signed in to an Azure Quantum Workspace shown in the Explorer sidebar (to which the current program could be submitted) – all without anything needing to be installed on the local machine.
We think the improvements in the user experience for the new QDK really are a quantum leap (bad pun intended).
This is an early preview, and we still have several features to add before we get to our ‘stable’ release, some of the main ones being:
Once the core product is solid, we have a laundry list of further features and Q# language improvements we want to get to, which you can view and contribute to on our GitHub repo.
The existing QDK (https://learn.microsoft.com/enus/azure/quantum/installoverviewqdk) is still fully supported and should be used if the new QDK Preview doesn’t meet your needs or is changing too frequently as we iterate towards our stable release.
We’d love for you to give it a try and give us your feedback. The installation guide and other getting started documentation is currently on our GitHub wiki at https://github.com/microsoft/qsharp/wiki/Installation. You can report any issues, weigh in on feature requests, or contribute code on that same GitHub repo.
The post Introducing the Azure Quantum Development Kit Preview appeared first on Q# Blog.
]]>The post Modeling quantum architecture with Azure Quantum Resource Estimator appeared first on Q# Blog.
]]>There are numerous architectural decisions to consider when building quantum computers, which have the potential to address realworld computational challenges like quantum chemistry and quantum cryptography. Researchers worldwide are engaged in developing various aspects of quantum computer architecture. Microsoft Azure Quantum Resource Estimator plays a pivotal role in assessing how different combinations of design choices might impact the performance of upcoming quantum computers.
Azure Quantum Resource Estimator was designed to assist researchers in estimating computational time and the requisite number of qubits based on diverse assumptions regarding hardware quality and error correction strategies. We have used a more powerful version of the Resource Estimator for many years as an internal tool for analyzing architectural decisions in our own quantum program. We have incorporated new options to offer similar capabilities to the Azure Quantum users.
Continuing our commitment to enhancing the tool’s capabilities, we have recently introduced several new features. These updates include the ability to customize error budget distributions and implement custom distillation units.
In this article, we provide an overview of fundamental concepts related to the architecture of quantum computers, exploring their influence on the necessary resources and the capabilities offered by Microsoft Azure Quantum Resource Estimator to model these intricate structures.
One can represent quantum computing stack as follows:
Scientists all around the world are collaborating on refining individual stack components and integrating them cohesively. The multitude of decisions made at each stack layer, coupled with diverse quantum algorithms, results in a vast array of possible combinations that warrant evaluation and comparison. Microsoft Azure Quantum Resource Estimator helps to assess and compare those combinations efficiently. You can submit your quantum program (such as in Q# or Qiskit) or Quantum Intermediate Representation (QIR) while specifying particular characteristics of a proposed quantum computing stack:
And the Resource Estimator will calculate rQOPS of the architecture and, qubits and time required for the application given this combination.
In the current landscape of 2023, a significant challenge lies in the pursuit of rapidly responsive, stable, and scalable physical qubits to enable impactful applications in chemistry and materials science (read more at Communications of the ACM, 2023). Researchers are exploring a range of design possibilities, including instruction sets as well as diverse anticipated levels of speed and fidelity for these qubits.
In the process of resource estimation, a higher degree of specificity becomes necessary, encompassing various times for distinct actions involving qubits. Our recent updates here involve:
Azure Quantum Resource Estimator supports:
Here is an example of specifying a custom qubit type:
from azure.quantum import Workspace from azure.quantum.target.microsoft import MicrosoftEstimator from azure.quantum.target.microsoft.target import MeasurementErrorRate #Enter your Azure Quantum workspace details here workspace = Workspace( resource_id="", location="" ) estimator = MicrosoftEstimator(workspace) params = estimator.make_params() params.qubit_params.name = "qubit_maj_ns_e6" params.qubit_params.instruction_set = "Majorana" params.qubit_params.one_qubit_measurement_time ="150 ns" params.qubit_params.two_qubit_joint_measurement_time = "200 ns" params.qubit_params.t_gate_time = "100 ns" params.qubit_params.one_qubit_measurement_error_rate = MeasurementErrorRate(process=1e6, readout=2e6) params.qubit_params.two_qubit_joint_measurement_error_rate = 1e6
# test quantum program from qiskit import QuantumCircuit circ = QuantumCircuit(3) circ.crx(0.2, 0, 1) circ.ccx(0, 1, 2) job = estimator.submit(circ) job.wait_until_completed() result = job.get_results() print(result)
We use a simple Qiskit circuit for this blog post for short. To learn how to run resource estimator for Q# algorithms, go to the Create the quantum algorithm section at the resource estimator documentation.
You can learn more about this at the Physical qubit parameters section of documentation.
Error correction in classical computing involves creating duplicates or checksums of data and periodically verifying these duplicates. In quantum computing, error correction is more complex due to the impossibility of copying information (see Nocloning theorem).
However, the basic principles are similar to classical error correction: achieving greater accuracy in computations requires extra resources (additional qubits and time). Analogous to classical computing, the extent of extra information can be quantified using a code distance (see Hamming distance). Opting for a higher code distance necessitates more resources but leads to enhanced computation fidelity.
We use the following exponential model for error rate suppression:
Here, p – is the physical qubit error rate (computed from various physical error rates above), P – is the (output) logical error rate provided by an error correction scheme, d – is the code distance, and a and p – are coefficients specific for the scheme, called crossing prefactor and error correction threshold correspondingly. As you can see, if p < p*, then P increases when d increases.
As mentioned above, resources involved would also grow with increasing of d. Here are examples for the Floquet scheme (arxiv.org:2202.11829):
logicalCycleTime=3 * oneQubitMeasurementTime * d,
physcialQubitsPerLogicalQubit=4 * d^2 + 8 * (d 1).
Microsoft Azure Quantum Resource Estimator supports two predefined schemes of error correction: surface and Floquet, as well as custom error correction schemes.
The surface scheme is based on the premise that physical qubits form a lattice on a surface. In this arrangement, we have two types of qubits: data qubits, which play a role in primary algorithm computations, and measurement qubits, which serve as supplementary components. These qubits are organized in a checkerboard pattern, where each data qubit is surrounded by four measurement qubits, and vice versa. Boundary qubits are conceptually linked to qubits on the opposite side, creating a toroidal structure. Stabilization measurements are performed on corresponding qubits along different axes with a specific geometric pattern. This scheme exhibits versatility, as it can be applied to both gatebased qubits and Majorana qubits.
Conversely, the Floquet scheme places more stringent demands on the geometric arrangement of qubits but offers significant advantages in terms of time and space efficiency (as detailed in arxiv.org: 2202.11829). Qubits must be arranged in a grid with three neighbors each, and it should be possible to color the plaquettes with just three colors. Honeycomb is an example of such structure. Subsequently, stabilization measurements are executed periodically with a period of three, involving joint measurements between one qubit and one of its three neighbors at a time. This geometric structure aligns well with Majorana qubits and can bring substantial benefits when applied to them.
If using Microsoft Quantum Development Kit, one can submit the following job with different error correction schemes:
from azure.quantum import Workspace from azure.quantum.target.microsoft import MicrosoftEstimator, ErrorBudgetPartition # Enter your Azure Quantum workspace details here workspace = Workspace( resource_id="", location="" ) estimator = MicrosoftEstimator(workspace) params = estimator.make_params() params.qec_scheme.error_correction_threshold = 0.01 params.qec_scheme.crossing_prefactor = 0.07 params.qec_scheme.logical_cycle_time = "3 * oneQubitMeasurementTime * codeDistance" params.qec_scheme.physical_qubits_per_logical_qubit = "4 * codeDistance * codeDistance + 8 * (codeDistance  1)"
# there are two predefined schemes: floquet_code and surface_code # the floquet_code can be applied for models with Majorana instruction set # the surface code can be applied to both: Majorana and gatebased instruction sets. # you can just specify the name of a predefined scheme #params.name = "surface_code" # test quantum program from qiskit import QuantumCircuit circ = QuantumCircuit(3) circ.crx(0.2, 0, 1) circ.ccx(0, 1, 2) job = estimator.submit(circ) job.wait_until_completed() result = job.get_results() print(result)
See more at the Quantum error correction schemes section of the Resource Estimator documentation.
To harness the benefits of quantum computing over classical counterparts, it is essential to devise quantum gates that cannot be effectively simulated on traditional nonquantum hardware. These operations can be envisioned as rotations of the Bloch sphere, executed at arbitrary angles. In this context, classical nonquantum hardware is proficient at executing rotations limited to angles of 90 degrees. This particular set of operations can be encapsulated by the concept of Clifford gates.
By combining a set of Clifford gates with additional nonClifford gates, it is possible to create a universal set of quantum gates. This means that any quantum gate can be efficiently approximated to the desired precision using a predefined sequence of operations from this set. This approximation process is commonly referred to as rotation synthesis.
Various quantum computer architectures might incorporate distinct nonClifford gates within the rotation synthesis. These particular gates are often termed “magic gates,” and their associated states are labeled as “magic states.” A notable challenge in quantum computing stems from its inherent inability to duplicate data. Consequently, generating these magic states once and employing them indefinitely is unfeasible. Instead, each usage demands the creation of fresh instances of these magic states. This intricate procedure of generating magic states with a specified level of precision is known as magic state distillation.
One of popular choices for the magic state is the Tgate defined as follows:
In Azure Quantum Resource Estimator, we assume that the Tstate is used as the magic state.
Algorithms designed for Tstate distillation play a crucial role in enhancing qubit accuracy. These algorithms utilize multiple input qubits with low accuracy to generate an output qubit with higher accuracy. This process can encompass multiple rounds of distillation, progressively refining qubit quality until the desired standard is attained. Each round employs a specific algorithm known as a distillation unit.
For each distillation unit, one should specify how it improves the qubit quality and what resources it will consume for the runtime: qubits involved, and time spent. Those characteristics depend on the code distance used for the distillation, physical quality of qubits and accuracy provided originally or by the previous round of distillation.
It’s important to note that distinct sequences of distillations can yield greater efficiency for different qubit qualities (output error rates). In other words, depending on the initial error rate of an input qubit, specific sequences of distillation may be more adept at achieving the required error rate while utilizing fewer resources.
Here are examples of distillation units described in Assessing requirements to scale to practical quantum advantage:
Distillation unit 
# input Ts 
# output Ts 
acceptance probability 
# qubits 
time 
output error rate 
15to1 spaceeff. physical 
15 
1 
1−15p_{T}−356p 
12 
46t_{meas} 
35p_{T}^{3}+7.1p 
15to1 spaceeff. logical 
15 
1 
1−15P_{T}−356P 
20n(d) 
13τ(d) 
35P_{T}^{3}+7.1P 
15to1 RM prep. physical 
15 
1 
1−15p_{T}−356p 
31 
23t_{meas} 
35p_{T}^{3}+7.1p 
15to1 RM prep. logical 
15 
1 
1−15P_{T}−356P 
31n(d) 
13τ(d) 
35P_{T}^{3}+7.1P 
When we are estimating the performance of a particular quantum algorithm on a specific quantum computer (which has a certain qubit quality and operation speed), we might need different target output error rates. Considering two distillation units (15to1 spaceefficiency and 15to1 RM preparation) and various code distances for each round, there could potentially be thousands of combinations to evaluate.
Various research groups are actively working on developing distillation algorithms, and their approaches might differ from the ones described earlier. For instance, some algorithms could generate multiple output Tstates, potentially reducing costs by sharing resources or enabling parallelization. With dozens of distillation algorithms in consideration, an intriguing opportunity arises to compare them against each other, encompassing diverse physical qubit attributes and algorithm variations. This comparative analysis could provide valuable insights into their relative effectiveness.
Microsoft Quantum invites researchers to assess the resources needed for their unique distillation approaches. Presently, we offer support for two established distillation units named `151 RM` and `151 spaceefficient`, in addition to the flexibility to define custom distillation unit specifications.
Here is an example of calling the Resource Estimator with custom distillation unit specifications:
from azure.quantum import Workspace
from azure.quantum.target.microsoft import MicrosoftEstimator
from azure.quantum.target.microsoft.target import DistillationUnitSpecification, ProtocolSpecificDistillationUnitSpecification
# Enter your Azure Quantum workspace details here
workspace = Workspace(
resource_id="",
location=""
)
estimator = MicrosoftEstimator(workspace)
params = estimator.make_params()
specification1 = DistillationUnitSpecification()
specification1.display_name = "282"
specification1.num_input_ts = 2
specification1.num_output_ts = 28
specification1.output_error_rate_formula = "35.0 * inputErrorRate ^ 3 + 7.1 * cliffordErrorRate"
specification1.failure_probability_formula = "15.0 * inputErrorRate + 356.0 * cliffordErrorRate"
physical_qubit_specification = ProtocolSpecificDistillationUnitSpecification()
physical_qubit_specification.num_unit_qubits = 12
physical_qubit_specification.duration_in_qubit_cycle_time = 65
specification1.physical_qubit_specification = physical_qubit_specification
logical_qubit_specification = ProtocolSpecificDistillationUnitSpecification()
logical_qubit_specification.num_unit_qubits = 20
logical_qubit_specification.duration_in_qubit_cycle_time = 37
specification1.logical_qubit_specification = physical_qubit_specification
specification2 = DistillationUnitSpecification()
specification2.name = "151 RM"
specification3 = DistillationUnitSpecification()
specification3.name = "151 spaceefficient"
params.distillation_unit_specifications =[specification1, specification2, specification3]
# test quantum program
from qiskit import QuantumCircuit
circ = QuantumCircuit(3)
circ.crx(0.2, 0, 1)
circ.ccx(0, 1, 2)
job = estimator.submit(circ)
job.wait_until_completed()
result = job.get_results()
print(result)
For further information, please refer to the Distillation Units section in the Resource Estimator documentation.
Quantum algorithms inherently embrace a probabilistic aspect, and the execution process is susceptible to errors. Typically, an algorithm can be run multiple times to reveal its probabilistic behavior and mitigate errors. When sending an algorithm for quantum computer execution, it’s crucial to determine how many runs are required to achieve a desired confidence level. Consequently, a probability of error in the final computations is defined, termed the error budget. Seeking a higher probability of success can involve employing the error correction methods elucidated earlier. However, it is important to note that this pursuit of higher success probability comes at an elevated cost, involving more qubits and a longer runtime.
We could categorize errors into three categories by occurrence:
As an initial approximation, we might distribute the error budget evenly among these three sources. Yet, certain algorithms could demand varying amounts of rotations or magic states. Hence, there could be a preference to readjust the error budget to align with the intricacies of the algorithm in question.
If using Microsoft Quantum Development Kit, one can submit the following job with different error budget options:
from azure.quantum import Workspace
from azure.quantum.target.microsoft import MicrosoftEstimator, ErrorBudgetPartition
# Enter your Azure Quantum workspace details here
workspace = Workspace(
resource_id="",
location=""
)
estimator = MicrosoftEstimator(workspace)
params = estimator.make_params()
# make an estimate with specific error budget
# for each of the three error sources:
params.error_budget = ErrorBudgetPartition(logical=0.001, t_states=0.002, rotations=0.003)
# for uniformly distributed error budgets,
# # you can specify just the total as single number:
# params.error_budget = 0.001
# test quantum program
from qiskit import QuantumCircuit
circ = QuantumCircuit(3)
circ.crx(0.2, 0, 1)
circ.ccx(0, 1, 2)
job = estimator.submit(circ)
job.wait_until_comps()
print(result)leted()
result = job.get_result
Read more about error budgets in the documentation.
The Azure Quantum team is dedicated to ongoing enhancements of the Resource Estimator. This valuable tool serves both our internal teams and external researchers in the endeavor to design quantum computers. Expanding the scope of modeling capabilities remains a key priority for us. We eagerly welcome your feedback on the specific custom options you require for estimating your quantum computer resources. Your insights will greatly contribute to refining our tool and making it even more effective for the quantum community.
There are many ways to learn more:
The post Modeling quantum architecture with Azure Quantum Resource Estimator appeared first on Q# Blog.
]]>The post Mentoring capstone projects at the University of Washington appeared first on Q# Blog.
]]>This spring we had the opportunity to mentor two student teams as part of the University of Washington’s NSF Research Traineeship program Accelerating QuantumEnabled Technologies (AQET). This yearlong certificate program offers graduate students training in quantum information science and engineering and includes several courses on different areas of quantum technologies followed by the culminating team project within the UW EE522: Quantum Information Practicum class. For this course the students worked on a quantumrelated project under the guidance of mentors from the quantum industry—and that’s where we came in.
We worked on two projects focused on the tools necessary to implement quantum algorithms at scale. As quantum computers evolve from their current noisy intermediate scale quantum (NISQ) era to scalable quantum supercomputers, the programs that run on them will evolve as well, from simple circuits to complex programs that solve sophisticated problems. As part of this progress, we start exploring the practicality of implementing various algorithms to run on quantum computers and the resources required to execute them. We also look at the possibility of generating parts of these programs automatically, borrowing from our experience in classical computing. The students’ projects explored different areas of quantum software development using Microsoft’s Quantum Development Kit (QDK) and Azure Quantum Resource Estimator.
Both teams did a great job, and later this fall they will be presenting their work at IEEE Quantum Week 2023 on Wednesday, September 20. Here is a teaser of their work.
Students: Chaman Gupta, ITung Chen
Mentors: Mathias Soeken, Mariia Mykhailova
The goal of this project was to design a workflow that would convert classical computation description into Q# code that implements it as a quantum computation. For example, the following Q# code for classical computation
internal function Multiplication2(a : Int, b : Int) : Int {
return a * b;
}
would be automatically converted into a quantum circuit that can be used like an operation implemented by the Q# library operation, e.g., MultiplyI.
The QDK samples already had an example of doing this for Boolean function evaluation, so this project targeted integers and arithmetic functions that work with integers: addition, multiplication, and modulo operations.
The image below shows the workflow used in the project.
Automated oracle synthesis workflow as implemented in the project
The steps in the workflow are as follows.
The generated quantum code can be executed via any tool that accepts QIR programs as input. This project used QIR Runner to run the simulation of the generated code for small inputs, and Azure Quantum Resource Estimator to estimate the resources required to run the code for larger inputs. Code samples and more technical details of this work can be found here.
When compared with handcrafted Q# library operations implementing similar quantum computations, our automatically generated code was faster but required more qubits to run. This shows that automatic generation of quantum code is a promising avenue of producing reliable and performant code in an efficient manner. The next steps in this direction would be exploring the ways to optimize the generated code even further and adding support for more arithmetic types and operations, such as floatingpoint arithmetic.
Students: Ethan Hansen, Sanskriti Joshi, Hannah Rarick
Mentors: Wim van Dam, Mariia Mykhailova
In this project, the students explored quantum multiplication algorithms and compared their efficiency in terms of runtime, qubit numbers, and Tgates required to run them on large inputs.
The project built on prior work by Gidney and it compared three quantum implementations of algorithms for multiplying nbit integers:
Classical multiplication is an arithmetic operation that is often taken for granted when discussing algorithms. However, when implemented on a quantum computer, it incurs quite a lot of overhead in terms of both additional qubits and extra operations performed to implement the computation as a unitary transformation that preserves coherence.
Using Azure Quantum Resource Estimator, the team calculated how the required resources depend on the multiplication algorithm used and on the size of the integers. The estimates showed that windowed multiplication uses slightly more qubits compared to the schoolbook algorithm but that it runs faster. Karatsuba’s algorithm uses more qubits and has longer runtimes compared to the schoolbook algorithm for inputs up to several thousand bits long. Eventually though, for large enough input sizes, the runtime of Karatsuba’s algorithm caught up with that of the schoolbook algorithm. Put together, these results refine our understanding of the performance of these three algorithms, and how in different settings different algorithms should be preferred.
This project provides a framework of applying similar resource estimation techniques to comparing different implementations of other quantum arithmetic primitives, such as floatingpoint functions, and other quantum subroutines.
The students found their projects interesting and enjoyable. They mentioned that the work on capstone projects helped them discover and learn important topics in quantum computing, such as oracle synthesis and resource estimation of algorithms, and broaden their understanding of the current state of the field. The students got valuable insights into their projects using Azure Quantum Resource Estimator, and their feedback on their experience helped us improve the tool for the future users. It has been a pleasure to mentor these teams, and we are looking forward to next year’s capstone projects!
The post Mentoring capstone projects at the University of Washington appeared first on Q# Blog.
]]>The post Blueprint to organize a quantum computing workshop appeared first on Q# Blog.
]]>The Azure Quantum team frequently receives questions on how to organize quantum computing workshops, so we thought it would be helpful to provide some guidance. And Azure Quantum is the ideal platform for quantum workshops because it provides the following:
If you want to organize a workshop on quantum computing, this is your guide!
Note that this guide provides you with steps to organize a workshop using your own Azure Subscription. You could also organize a workshop asking all attendees to create their own Azure subscription and workshop. This is not covered here.
The post Blueprint to organize a quantum computing workshop appeared first on Q# Blog.
]]>
Today, Azure Quantum is introducing sessions,
The post Azure Quantum introduces sessions to accelerate your research with variational algorithms appeared first on Q# Blog.
]]>
Today, Azure Quantum is introducing sessions, freeing you from the need to understand specificities of the cloud provider or quantum manufacturer. With a simple Python API call you can start a session that will logically group your jobs and take advantage of performance optimizations that the quantum manufacturer may provide, combining simplicity of use and performance.
In partnership with Quantinuum, we are also announcing that you can get exclusive access to the QPU for the duration of the session.
Organize your quantum jobs with sessions
Without sessions, running multiple iterations of algorithms that each contain multiple quantum jobs can quickly become confusing. Sessions allow you to group jobs within a single run of an algorithm, making it easier to track and manage them. When managing jobs in your Azure Quantum workspace via the Azure Portal, sessions are now displayed alongside any jobs submitted without a session. You can drill into a session to see the job details for all jobs that make up the session.
Similarly, you can manage your sessions locally using the Microsoft QDK.
Improve performance with dedicated QPU access for sessions with Quantinuum
Session IDs are attached to all jobs sent to Azure Quantum’s hardware partners, allowing them to identify related jobs and improve processing. As part of our sessions release, Quantinuum now offers an exciting feature that can dramatically improve performance for researchers running complex hybrid algorithms.
For all Quantinuum targets, once the first job in a session is completed, subsequent jobs in the same session get exclusive access to the target for the duration of the session as long as Quantinuum receives them within a minute of previous job execution. Individual jobs no longer need to get in the back of the queue, with Quantinuum’s support for sessions they’re treated as components of a single algorithm with dedicated QPU access!
“Variational algorithms play an important role in the NISQ timeframe. Quantinuum provides batching capability for running a set of circuits backtoback in a quick succession. Now this capability is available to our Azure customers via Azure Quantum Sessions providing increased convenience to the algorithm developers who need to run their experiments with minimal delay between individual circuits.”
Alex Chernoguzov, Sr. Technical Fellow, Quantinuum
Quantinuum has been an important partner for Azure Quantum and the quantum community, and their additional support for sessions will help researchers push the boundaries of quantum computing as hardware and algorithms continue to scale.
Save time and money with job failure policies
As quantum algorithms become more complex, cost and runtime considerations become increasingly important. Parameterized hybrid algorithms like VQE and QAOA can fail if an individual quantum job failure prevents classical code from defining appropriate parameters for the next job. Submitting improperly parameterized jobs after a previous job failure can waste valuable time and resources.
To prevent this, jobs within a session have a cancelonfailure policy by default: if a job within a session fails, Azure Quantum automatically stops submission of subsequent jobs in the session and attempts to cancel any jobs already submitted to a target. This policy can be disabled if you’d like subsequent jobs in your session to continue to run even if previous jobs fail.
How to create a session
The basic sample below shows how to create a session in Python with Qiskit using a simple circuit run three times.
from qiskit import QuantumCircuit
from qiskit.tools.monitor import job_monitor
from azure.quantum.qiskit import AzureQuantumProvider
# Enter your Azure Quantum workspace details here
provider = AzureQuantumProvider(
resource_id = "",
location = "")
# Define a circuit
circuit = QuantumCircuit(2, 2)
circuit.name = "GenerateRandomBit"
circuit.h(0)
circuit.cnot(0,1)
circuit.measure([0,1], [0,1])
circuit.draw()
# Choose a target
backend = provider.get_backend("quantinuum.sim.h11e")
# Create a session and run three jobs in the session
with backend.open_session(name="Qiskit Session") as session:
for i in range(3):
# Some classical logic could go here
job = backend.run(circuit=circuit, shots=100, job_name="Job "+str(i+1))
job_monitor(job)
# Check the state of the session
session.refresh()
print("Session " + session.id + " is in " + session.details.status + " state.")
It’s easy to extend sessions to more advanced scenarios. As part of our sessions release, Azure Quantum published new sample code for running VQE on a hydrogen molecule that you can use in the Azure portal or your preferred IDE. Running the sample in a session is as easy as adding one line of code:
with backend_target.open_session(name="VQE Nature IonQ Sim") as session:
calc = GroundStateEigensolver(qubit_converter, vqe_solver)
print(calc.get_qubit_operators(problem))
res = calc.solve(problem)
print(res.groundenergy)
You can also create sessions with Cirq and Q# via Azure Quantum’s Python SDK. See the sessions documentation for the full list of supported scenarios.
Learn more
Sessions are one part of Microsoft’s work to enable hybrid quantum computing at scale. You can read the full details of sessions in our documentation.
To get started with sessions with Azure Quantum, create your own free Azure Quantum workspace and check out our new VQE sample in the Azure Portal or your preferred development environment.
The post Azure Quantum introduces sessions to accelerate your research with variational algorithms appeared first on Q# Blog.
]]>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.
]]>