Coder Social home page Coder Social logo

documentation's Introduction

Qiskit

License Current Release Extended Support Release Downloads Coverage Status PyPI - Python Version Minimum rustc 1.70 Downloads DOI

Qiskit is an open-source SDK for working with quantum computers at the level of extended quantum circuits, operators, and primitives.

This library is the core component of Qiskit, which contains the building blocks for creating and working with quantum circuits, quantum operators, and primitive functions (Sampler and Estimator). It also contains a transpiler that supports optimizing quantum circuits, and a quantum information toolbox for creating advanced operators.

For more details on how to use Qiskit, refer to the documentation located here:

https://docs.quantum.ibm.com/

Installation

Warning

Do not try to upgrade an existing Qiskit 0.* environment to Qiskit 1.0 in-place. Read more.

We encourage installing Qiskit via pip:

pip install qiskit

Pip will handle all dependencies automatically and you will always install the latest (and well-tested) version.

To install from source, follow the instructions in the documentation.

Create your first quantum program in Qiskit

Now that Qiskit is installed, it's time to begin working with Qiskit. The essential parts of a quantum program are:

  1. Define and build a quantum circuit that represents the quantum state
  2. Define the classical output by measurements or a set of observable operators
  3. Depending on the output, use the primitive function sampler to sample outcomes or the estimator to estimate values.

Create an example quantum circuit using the QuantumCircuit class:

import numpy as np
from qiskit import QuantumCircuit

# 1. A quantum circuit for preparing the quantum state |000> + i |111>
qc_example = QuantumCircuit(3)
qc_example.h(0)          # generate superpostion
qc_example.p(np.pi/2,0)  # add quantum phase
qc_example.cx(0,1)       # 0th-qubit-Controlled-NOT gate on 1st qubit
qc_example.cx(0,2)       # 0th-qubit-Controlled-NOT gate on 2nd qubit

This simple example makes an entangled state known as a GHZ state $(|000\rangle + i|111\rangle)/\sqrt{2}$. It uses the standard quantum gates: Hadamard gate (h), Phase gate (p), and CNOT gate (cx).

Once you've made your first quantum circuit, choose which primitive function you will use. Starting with sampler, we use measure_all(inplace=False) to get a copy of the circuit in which all the qubits are measured:

# 2. Add the classical output in the form of measurement of all qubits
qc_measured = qc_example.measure_all(inplace=False)

# 3. Execute using the Sampler primitive
from qiskit.primitives.sampler import Sampler
sampler = Sampler()
job = sampler.run(qc_measured, shots=1000)
result = job.result()
print(f" > Quasi probability distribution: {result.quasi_dists}")

Running this will give an outcome similar to {0: 0.497, 7: 0.503} which is 000 50% of the time and 111 50% of the time up to statistical fluctuations. To illustrate the power of Estimator, we now use the quantum information toolbox to create the operator $XXY+XYX+YXX-YYY$ and pass it to the run() function, along with our quantum circuit. Note the Estimator requires a circuit without measurement, so we use the qc_example circuit we created earlier.

# 2. Define the observable to be measured 
from qiskit.quantum_info import SparsePauliOp
operator = SparsePauliOp.from_list([("XXY", 1), ("XYX", 1), ("YXX", 1), ("YYY", -1)])

# 3. Execute using the Estimator primitive
from qiskit.primitives import Estimator
estimator = Estimator()
job = estimator.run(qc_example, operator, shots=1000)
result = job.result()
print(f" > Expectation values: {result.values}")

Running this will give the outcome 4. For fun, try to assign a value of +/- 1 to each single-qubit operator X and Y and see if you can achieve this outcome. (Spoiler alert: this is not possible!)

Using the Qiskit-provided qiskit.primitives.Sampler and qiskit.primitives.Estimator will not take you very far. The power of quantum computing cannot be simulated on classical computers and you need to use real quantum hardware to scale to larger quantum circuits. However, running a quantum circuit on hardware requires rewriting to the basis gates and connectivity of the quantum hardware. The tool that does this is the transpiler, and Qiskit includes transpiler passes for synthesis, optimization, mapping, and scheduling. However, it also includes a default compiler, which works very well in most examples. The following code will map the example circuit to the basis_gates = ['cz', 'sx', 'rz'] and a linear chain of qubits $0 \rightarrow 1 \rightarrow 2$ with the coupling_map =[[0, 1], [1, 2]].

from qiskit import transpile
qc_transpiled = transpile(qc_example, basis_gates = ['cz', 'sx', 'rz'], coupling_map =[[0, 1], [1, 2]] , optimization_level=3)

Executing your code on real quantum hardware

Qiskit provides an abstraction layer that lets users run quantum circuits on hardware from any vendor that provides a compatible interface. The best way to use Qiskit is with a runtime environment that provides optimized implementations of sampler and estimator for a given hardware platform. This runtime may involve using pre- and post-processing, such as optimized transpiler passes with error suppression, error mitigation, and, eventually, error correction built in. A runtime implements qiskit.primitives.BaseSampler and qiskit.primitives.BaseEstimator interfaces. For example, some packages that provide implementations of a runtime primitive implementation are:

Qiskit also provides a lower-level abstract interface for describing quantum backends. This interface, located in qiskit.providers, defines an abstract BackendV2 class that providers can implement to represent their hardware or simulators to Qiskit. The backend class includes a common interface for executing circuits on the backends; however, in this interface each provider may perform different types of pre- and post-processing and return outcomes that are vendor-defined. Some examples of published provider packages that interface with real hardware are:

You can refer to the documentation of these packages for further instructions on how to get access and use these systems.

Contribution Guidelines

If you'd like to contribute to Qiskit, please take a look at our contribution guidelines. By participating, you are expected to uphold our code of conduct.

We use GitHub issues for tracking requests and bugs. Please join the Qiskit Slack community for discussion, comments, and questions. For questions related to running or using Qiskit, Stack Overflow has a qiskit. For questions on quantum computing with Qiskit, use the qiskit tag in the Quantum Computing Stack Exchange (please, read first the guidelines on how to ask in that forum).

Authors and Citation

Qiskit is the work of many people who contribute to the project at different levels. If you use Qiskit, please cite as per the included BibTeX file.

Changelog and Release Notes

The changelog for a particular release is dynamically generated and gets written to the release page on Github for each release. For example, you can find the page for the 0.46.0 release here:

https://github.com/Qiskit/qiskit/releases/tag/0.46.0

The changelog for the current release can be found in the releases tab: Releases The changelog provides a quick overview of notable changes for a given release.

Additionally, as part of each release, detailed release notes are written to document in detail what has changed as part of a release. This includes any documentation on potential breaking changes on upgrade and new features. See all release notes here.

Acknowledgements

We acknowledge partial support for Qiskit development from the DOE Office of Science National Quantum Information Science Research Centers, Co-design Center for Quantum Advantage (C2QA) under contract number DE-SC0012704.

License

Apache License 2.0

documentation's People

Contributors

1ucian0 avatar 3yakuya avatar abbycross avatar arnaucasau avatar beckykd avatar cbjuan avatar cryoris avatar dependabot[bot] avatar derivation avatar divshacker avatar elept avatar eric-arellano avatar frankharkins avatar github-actions[bot] avatar guillermo-mijares-vilarino avatar huangjunye avatar jakelishman avatar javabster avatar jaygambetta avatar jyu00 avatar kaelynj avatar kevinsung avatar lcapelluto avatar mtreinish avatar ng-glen avatar nonhermitian avatar pandasa123 avatar psschwei avatar sooluthomas avatar t-imamichi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

documentation's Issues

Epic: Revamp Start Section

Tasks

  1. content ๐Ÿ“„ section: start
    beckykd
  2. content ๐Ÿ“„ section: start
    abbycross
  3. content ๐Ÿ“„ needs discussion ๐Ÿ’ฌ section: start
  4. content ๐Ÿ“„ infra ๐Ÿ—๏ธ
    Eric-Arellano

Add troubleshooting docs for error code 5302

Describe the bug

It's not uncommon for users to have a Failed job with status reason Failed to publish job: nats: maximum payload exceeded and status reason code 5302. This is due to the job results payload being too large to process for the backend infrastructure. There are improvements being developed to solve this issue in the infrastructure but they aren't available in the short term, so until then it would be good if there was some troubleshooting documentation about what users can do to workaround this.

Anecdotally what I've heard is that requesting IQ data seems to push the size of the job results payload passed the limit and trigger the failure.

Steps to reproduce

In one case I heard this is what the user did:

The job ~700 measurements per circuit, ran for 10000 shots and I requested the IQ data for each.

Expected behavior

There should be troubleshooting docs to help users workaround this type of failure if the experience it.

Suggested solutions

Add the docs.

Additional Information

  • qiskit-ibm-runtime version: latest
  • Python version: n/a
  • Operating system: n/a

Set up spelling check

We're using cSpell in closed source. We should use it here too.

Tasks

Epic: Revamp Run section

Tasks

  1. content ๐Ÿ“„ new โœจ section: run ๐Ÿƒโ€โ™€๏ธ
    abbycross
  2. content ๐Ÿ“„ section: run ๐Ÿƒโ€โ™€๏ธ
    beckykd
  3. content ๐Ÿ“„ section: optimize ๐Ÿ”„ section: run ๐Ÿƒโ€โ™€๏ธ
    abbycross
  4. content ๐Ÿ“„ section: run ๐Ÿƒโ€โ™€๏ธ
    beckykd
  5. content ๐Ÿ“„ section: run ๐Ÿƒโ€โ™€๏ธ
    abbycross
  6. content ๐Ÿ“„ new โœจ section: run ๐Ÿƒโ€โ™€๏ธ
  7. content ๐Ÿ“„ section: run ๐Ÿƒโ€โ™€๏ธ
  8. content ๐Ÿ“„ new โœจ section: run ๐Ÿƒโ€โ™€๏ธ
    kevinsung

[ MOVE ] "Build with Primitives" section from Build to Run

The following pages currently in the Build section should be moved to the Run section:

  • Get Started with Primitives
  • Primitives Examples
  • Specify advanced runtime options

As part of this the introduction page of build should be updated to no lnger talk about primitives as part of the build section

Set up local docs preview

Base this off of the proof of concept from Axel to use a Docker image.

It's fine if at first this requires an IBM log in, as long as we quickly thereafter can use a public Docker image so that open source contributors can use it too.

Figure out folder structure for translations

We need to figure out URL scheme and folder organization for docs, which are tied together.

URL/file names will stay the same

That is, we don't try translating /start/my_file to /empieza/mi_archivo for example. It's a common convention in localization to use consistent URLs and it makes everything much easier to implement.

Proposed URL scheme

English URLs will still the same w/o language in the URL/file, e.g. /start. But English does still need to show up in the language toggle.

Translations will start with /<lang> in their URL, e.g. /es/start and /fr/run. Everything after in the URL will be the same. Each language will have a full copy of the normal documentation but translated, and excluding API docs.

To communicate the language information to the docs app, we could reuse _package.json from #8? Or add _language.json? Whatever makes the most sense for the application.

{"code": "es", "name": "Spanish"}
{"code": "zh-TW", "name": "Chinese (traditional)"}

Similar to how version toggling works, changing the language via the language toggle would change which top-level language folder is loaded (or English). It changes the language setting for the entire Docs app.

Locales vs languages

In qiskit.org, we had a concept of locales: the combination of language and region, e.g. es_UN for Spanish universal. The region part is useful to do things like show currencies and times/dates differently.

But in practice, we only had one locale per language, except for Chinese having both simplified and traditional.

Given the nature of the Qiskit documentation, I propose that we simplify and only use langauge codes like /es and /fr, without locales for every language but Chinese. It seems unlikely that we'll have the bandwidth to differentiate by locale. We didn't have the bandwidth before. It also doesn't seem super critical.

Chinese would be zh-CN (simplified) and zh-TW (traditional), though.

We could always add locales in the future to the other languages. We could set up redirects from /es/ to /es-UN/, for example.

FYI: how to integrate with Crowdin

Crowdin exports the folders with the locale as the prefix, e.g. es-es/. I couldn't change this behavior via their language mapping mechanism, even though the docs suggest it should have worked. For all but Chinese, we'll post-process the folder after downloading translations to remove the locale portion from the folder.

_toc.json

This file controls the names of things in the left sidebar, and what URLs they take you to.

We should not change the URLs. But it makes sense to translate the page titles.

  "children": [
    {
      "title": "Introducciรณn",
      "url": "/start"
    },

Won't translate API docs

We took this decision for qiskit.org and the translations team has continued to plan for that.

So, the URL scheme for API docs from #8 is orthogonal to the URL scheme for historical API docs.

Still, we should account for the possibility of changing our mind. If so, the URL scheme could be:

/es/api/qiskit/utils
/es/api/qiskit/0.44/utils

Internal links handled by the docs app

With internal links, it's important that we take you to the correct language for the sibling file.

There are two ways of doing internal links:

/start/my_file
../start/my_file

The first style starting with / would always refer to the English version of the file; you'd need to use /es/start/my_file to get the Spanish version. Or we'd need to have the docs app interpret the URL differently.

I originally proposed banning the first style and always using relative links, but we decided in #532 to instead have the docs app correctly set up internal links.

Note that links to /api should always point to English since there are no translated API docs.

Anchor links

Normally, we link to headers for anchors with internal links, i.e. #my-header section of a URL. That works because the docs app automatically assigns an HTML ID to headers, like My Header becoming my-header.

But when the headers are translated, My Header would now become Mi Cabecera, so #mi-cabecera. It would be very finicky if we expected translators to change all of these URL anchors for each language.

Instead, I think we do want something like #185 so that we can always use the same anchor regardless of the language. We'd ban using anchors from headers (except API docs).

How to keep files in sync

We'll use the Crowdin GitHub Action to handle a) uploading changes to the source docs, and b) downloading updated translations.

I propose using the GitHub action rather than Crowdin's GitHub integration in the app itself because it allows us more precise control over the behavior. The Crowdin Integration will open up a PR every time there is a new translation, for example, which is noisy. Instead, by using the GitHub action, we can batch changes to e.g. run once every week.

See #541 for how this implemented, including the different schedules we did for uploading English sources vs. downloading translations weekly.

Translations live in this repository

It's useful for the translations to live in Qiskit/documentation because it simplifies the setup. For example, it makes it easier for us to synchronize these open source docs with the closed source infrastructure that deploys this all to ibm.com. We also don't need to duplicate config and tooling like our link checker.

The major concern with translations living here would be if it's too noisy because of lots of PRs to update the translations. That is where batching is important (see "How to keep files in sync"). Rather than a PR for every translation, we'll only pull in translations e.g. once a week.

Refactor "Introduction to Primitives" page

This page should focus on teaching the overall concepts of primitives (the base definition in Qiskit and the Runtime implementations), rather than showing the code of how to use them which is covered in later pages

Tasks

Update session doc to indicate it doesn't work with simulator

What is the expected feature or enhancement?

Session documentation today uses simulator as an example, but session doesn't actually work with simulator backends, since there is no queue. It's usually not a problem since simulator jobs usually run immediately, as they would in a session. But occasionally they do back up, which lead to users questioning why their active session jobs do not run right away.

Acceptance criteria

Clarify how simulator jobs behave in a session.

migrate files from `qiskit-ibm-runtime` to `Qiskit/docs` and convert `.rst` files to `.mdx`

@abbycross @beckykd I'm so lost with these pages pls help ๐Ÿ˜…

The following files should be migrated from the qiskit-ibm-runtime repo to this repo.

Files to migrate to docs/start

Files to migrate to docs/build

No tasks being tracked yet.

Files to migrate to docs/test

No tasks being tracked yet.

Files to migrate to docs/run

No tasks being tracked yet.

Files to migrate to docs/optimize

No tasks being tracked yet.

Files to migrate to docs/other


DISCUSS:

  • what should be done about runtime tutorials that are in the learning app? some tutorials like this one and this one seem more like documentation pages? what is the line between a 1docs page and a tutorial?
  • should we move over the cloud folder?

Review "Building Noise Models" page

This page originally came from the Qiskit Aer documentation, but it begs the question of should we be including ecosystem documentation in 1docs?

We should consider the following:

  • what is the overall goal of this page? What are we trying to teach people?
  • Can this page be rewritten just using core qiskit?
  • If we can't demonstrate the same functionality without Aer how do we best explain what Aer is? This may be the first page in the current docs flow that mentions this new package. Should we add a note box or intro paragraph to the top explaining what Aer is and pointing out to the Aer docs for more details?
  • If we need to keep this page how do we keep it up to date with the equivalent page in the Aer docs? Alternatively, should we rewrite it from scratch and just link out to the Aer docs for more detail?
  • Do we need an additional page explaining what the Qiskit Ecosystem is somewhere? Or include a section about it in the "What is Qiskit" page in start?

Migrate Sphinx -> MDX pipeline for open source

This is currently in closed source, to pull in the API docs for qiskit, qiskit-ibm-runtime, and qiskit-ibm-provider. We're proposing open sourcing it.

At least in a follow up, we should consider running the pipeline on artifacts from CI, rather than the actual published websites. That will allow us to consume specific commits, such as pulling in typo fixes more quickly.

on artifacts from CI

Local builds for Qiskit take too long to run locally.

Update `README.md` with contributing info

To include:

  • What types of contributions we do and do not accept
  • what the process is for suggesting/contributing a new page
  • what types of contributions we recommend/encourage
  • how to make each type of contribution
  • how to run the docs locally
  • a short bit of info about how the deployment pipeline works
  • how we triage API ref feedback

[Doc] Explain what channels are

What is the expected feature or enhancement?

The word channel is used in multiple places in the doc, but it never explains what a channel is. This can be especially confusing for people who have always and only been using IQP. Maybe just a quick explaination in "Getting started".

Acceptance criteria

Consider auto-formatting MDX files

I think it would be worth adding Prettier for our MD/MDX files :) But I'll confirm with the content team that they're okay with it first.

Epic: Revamp Build Section

Tasks

  1. content ๐Ÿ“„ on hold โธ๏ธ section: build ๐Ÿงฑ
    abbycross
  2. content ๐Ÿ“„ section: build ๐Ÿงฑ
    abbycross
  3. content ๐Ÿ“„ section: build ๐Ÿงฑ
    abbycross
  4. content ๐Ÿ“„
    abbycross
  5. content ๐Ÿ“„ section: build ๐Ÿงฑ
    abbycross frankharkins
  6. content ๐Ÿ“„ infra ๐Ÿ—๏ธ section: build ๐Ÿงฑ
    abbycross
  7. content ๐Ÿ“„ section: build ๐Ÿงฑ
  8. content ๐Ÿ“„ needs discussion ๐Ÿ’ฌ section: build ๐Ÿงฑ
    abbycross
  9. content ๐Ÿ“„ section: build ๐Ÿงฑ
    abbycross
  10. 0 of 4
    content ๐Ÿ“„ new โœจ section: build ๐Ÿงฑ
    kevinsung
  11. content ๐Ÿ“„ new โœจ section: build ๐Ÿงฑ
    abbycross
  12. content ๐Ÿ“„ new โœจ section: build ๐Ÿงฑ
    frankharkins
  13. content ๐Ÿ“„ new โœจ section: build ๐Ÿงฑ
    frankharkins
  14. content ๐Ÿ“„ needs discussion ๐Ÿ’ฌ new โœจ section: build ๐Ÿงฑ
    Cryoris
  15. content ๐Ÿ“„ needs discussion ๐Ÿ’ฌ new โœจ section: build ๐Ÿงฑ
    Cryoris

[ REFACTOR ] Pulse pages

The pulse pages (which came from Qiskit tutorials) are a bit old and possibly need a rewrite

What should be done:

SME collaborators (involve for planning and review):

@nkanazawa1989

[ NEW PAGE ] Add an Introduction page to the Transpile section

The Transpile section should have an overview page explaining what the "transpile" phase is, similar to what we already have for the build section

What the new page should cover:

  • define hierarchy of abstraction levels of circuits:
    • abstract
    • logical / virtual (TODO: decide upon terminology of โ€˜logicalโ€™ or โ€˜virtualโ€™)
    • physical
    • scheduled
  • describe required transpilation to use different primitives (logical for sampler and estimator, physical for circuit runner / backend.run)
  • define what content in this section is relevant to everyone vs what content is relevant only to advanced users. users: a plain transpiler user, a pm builder, a plugin user, a plugin writer.

SME collaborators (involve for planning and review):

Ali Javadi, Matthew Treinish, Luciano Bello

Existing resources to build upon

Figure out URL and folder structure for API versioning

Background

Part of #77. We need historical versions for the API docs, like Qiskit 0.24 vs 0.25. Distinct versions will be for minor releases, but not patch releases like 0.24.1.

The non-API docs do not have versioning per-API. Instead, #133 tracks how we will indicate in non-API docs their version compatibility. This ticket is focused on API docs.

Relationship to translations

API docs have not ever been historically translated and we don't plan to in the future, per @SooluThomas.

So, while the folder structure we use for translations (#7) is relevant, it's somewhat orthogonal.

Plan

/api/qiskit/<version>/, e.g. /api/qiskit/0.25/circuit

This URL scheme corresponds to the folder structure, that we'll have a folder api/qiskit/0.25 etc. That folder will be self-contained, e.g. with its own _toc.json. When in the frontend the user changes the currently selected version, we'll switch to rendering that folder.

Cross-references

We need to update cross-references for stable version folders so that they all link to files in the same version folder, i.e. 0.25 files all cross-link to 0.25 files.

This will be automated by our API generation script.

Keep un-versioned API

We'll also continue having an un-versioned "latest" URL, like /api/qiskit/circuit, so that people can link to latest.

When generating the API docs for the "latest", it will update both the stable folder and the unstable folders so that they're in sync.

None of our API pages start with a numberโ€”which would be a violation of Python naming rulesโ€”so we shouldn't have a clash between the version folder and the unversioned docs.

Non-API docs will link to the un-versioned docs in most cases, other than specific edge cases like how qiskit.algorithms is being deleted, so the Algorithms migration guide must link to the historical file.

migrate files from closed source to `Qiskit/docs`

Each of the files in the following list should be moved over from closed source in their existing format (either .mdx or .ipynb). For some of these files that were originally based on other open-source content the original open-source authors should be added as co-authors to the files when they are migrated over

Files to move - Start

Files to move - Build

Files to move - Test

Files to move - Run

Files to move - Optimize


DISCUSS:
Should we move over the files in the following folders:

  • docs/admin
  • docs/announcements
  • docs/lab
  • docs/service-alerts

Refactor "get started with primitives" page

this page was originally written only with the runtime primitives in mind, but now that we are also including qiskit docs we should update this page to include more information about the qiskit primitives as well.

Note: before the migration there was a lot of work put into creating a new primitives tutorial. This tutorial never got released due to all the chagnes with qiskit docs, but the information in this tutorial was almost ready to go. We should consider incorporating the content from this tutorial, and credit the original authors if we choose to reuse their content

Add an Overview page to the Test section

The Test section should have an overview page explaining what the "test" phase is, similar to what we already have for the build section

This page should include a section about when the use of simulators are appropriate, and what the limits are. Generally we want to strike a balance between documenting this part of the workflow while encouraging people to move on to larger experiments on real hardware as quickly as possible

Epic: Revamp Verify section

Tasks

  1. content ๐Ÿ“„ new โœจ section: verify ๐Ÿงช
    abbycross
  2. content ๐Ÿ“„ section: verify ๐Ÿงช
    abbycross
  3. 0 of 3
    content ๐Ÿ“„ section: verify ๐Ÿงช
    abbycross
  4. 1 of 3
    content ๐Ÿ“„ section: verify ๐Ÿงช
    kevinsung
  5. content ๐Ÿ“„ needs discussion ๐Ÿ’ฌ new โœจ section: verify ๐Ÿงช
    kevinsung
  6. content request new โœจ
    abbycross beckykd
    javabster

[ REMOVE ] "conditional reset" page

This page should be removed from onedocs

Note: some of the content can be repurposed for the new "Native gates and opertations' page. See issue here:

Epic: create new Transpile section

Tasks

  1. content ๐Ÿ“„ new โœจ section: transpile ๐Ÿ”€
    abbycross kaelynj
  2. content ๐Ÿ“„ in-progress new โœจ section: transpile ๐Ÿ”€
    beckykd nbronn
  3. content ๐Ÿ“„ in-progress section: transpile ๐Ÿ”€
    beckykd nbronn
  4. content ๐Ÿ“„ new โœจ section: transpile ๐Ÿ”€
    abbycross kaelynj
  5. content ๐Ÿ“„ section: transpile ๐Ÿ”€
    beckykd kevinsung
  6. content ๐Ÿ“„ new โœจ section: transpile ๐Ÿ”€
    kevinsung
  7. content ๐Ÿ“„ new โœจ section: transpile ๐Ÿ”€
    abbycross kaelynj
    nbronn
  8. infra ๐Ÿ—๏ธ
    Eric-Arellano
  9. content ๐Ÿ“„ needs discussion ๐Ÿ’ฌ new โœจ on hold โธ๏ธ section: transpile ๐Ÿ”€
  10. content ๐Ÿ“„ needs discussion ๐Ÿ’ฌ new โœจ section: transpile ๐Ÿ”€
    kaelynj

[ NEW PAGE ] Build/ Control flow with Qiskit

What the new page should cover:

Tasks

SME collaborators (involve for planning and review):

@jakelishman

Existing resources to use for reference

Reno spacing of release-note comments generates new `ul` elements

reno report generates release notes that look something like this:

Bug Fixes
---------

.. releasenotes/notes/0.23/fix-transpiler-optimize-1q-decomposition-score-e79ea05c3cf1b6fa.yaml @ b'7dc7a1cc7111b80f6cb7eea6de867e36db3ab1a8'

- Fixes a bug in the :class:`.Optimize1qGatesDecomposition` transformation pass
  where the score for substitutions was wrongly calculated when the gate
  errors are zero.

.. releasenotes/notes/add-inverse-ecr-e03720252a0c9c1e.yaml @ b'3d91d02a23fcdce22f3f47c105a5327087911ff2'

- The method :meth:`.ECRGate.inverse` now returns another :class:`.ECRGate` instance
  rather than a custom gate, since it is self inverse.

.. releasenotes/notes/clip-quantumstate-probabilities-5c9ce05ffa699a63.yaml @ b'7dc7a1cc7111b80f6cb7eea6de867e36db3ab1a8'

- Clip probabilities in the :meth:`.QuantumState.probabilities` and
  :meth:`.QuantumState.probabilities_dict` methods to the interval ``[0, 1]``.
  This fixes roundoff errors where probabilities could e.g. be larger than 1, leading
  to errors in the shot emulation of the sampler.
  Fixed `#9761 <https://github.com/Qiskit/qiskit-terra/issues/9761>`__.

This produces HTML like this:

<div class="section" id="bug-fixes">
<span id="release-notes-terra-0-23-3-bug-fixes"></span><h5>Bug Fixes<a class="headerlink" href="[#bug-fixes](view-source:https://qiskit.org/documentation/release_notes.html#bug-fixes)" title="Permalink to this heading">ยถ</a></h5>
<ul class="simple">
<li><p>Fixes a bug in the <a class="reference internal" href="[stubs/qiskit.transpiler.passes.Optimize1qGatesDecomposition.html#qiskit.transpiler.passes.Optimize1qGatesDecomposition](view-source:https://qiskit.org/documentation/stubs/qiskit.transpiler.passes.Optimize1qGatesDecomposition.html#qiskit.transpiler.passes.Optimize1qGatesDecomposition)" title="qiskit.transpiler.passes.Optimize1qGatesDecomposition"><code class="xref py py-class docutils literal notranslate"><span class="pre">Optimize1qGatesDecomposition</span></code></a> transformation pass
where the score for substitutions was wrongly calculated when the gate
errors are zero.</p></li>
</ul>
<ul class="simple">
<li><p>The method <a class="reference internal" href="[stubs/qiskit.circuit.library.ECRGate.inverse.html#qiskit.circuit.library.ECRGate.inverse](view-source:https://qiskit.org/documentation/stubs/qiskit.circuit.library.ECRGate.inverse.html#qiskit.circuit.library.ECRGate.inverse)" title="qiskit.circuit.library.ECRGate.inverse"><code class="xref py py-meth docutils literal notranslate"><span class="pre">ECRGate.inverse()</span></code></a> now returns another <a class="reference internal" href="[stubs/qiskit.circuit.library.ECRGate.html#qiskit.circuit.library.ECRGate](view-source:https://qiskit.org/documentation/stubs/qiskit.circuit.library.ECRGate.html#qiskit.circuit.library.ECRGate)" title="qiskit.circuit.library.ECRGate"><code class="xref py py-class docutils literal notranslate"><span class="pre">ECRGate</span></code></a> instance
rather than a custom gate, since it is self inverse.</p></li>
</ul>
<ul class="simple">
<li><p>Clip probabilities in the <a class="reference internal" href="[stubs/qiskit.quantum_info.QuantumState.probabilities.html#qiskit.quantum_info.QuantumState.probabilities](view-source:https://qiskit.org/documentation/stubs/qiskit.quantum_info.QuantumState.probabilities.html#qiskit.quantum_info.QuantumState.probabilities)" title="qiskit.quantum_info.QuantumState.probabilities"><code class="xref py py-meth docutils literal notranslate"><span class="pre">QuantumState.probabilities()</span></code></a> and
<a class="reference internal" href="[stubs/qiskit.quantum_info.QuantumState.probabilities_dict.html#qiskit.quantum_info.QuantumState.probabilities_dict](view-source:https://qiskit.org/documentation/stubs/qiskit.quantum_info.QuantumState.probabilities_dict.html#qiskit.quantum_info.QuantumState.probabilities_dict)" title="qiskit.quantum_info.QuantumState.probabilities_dict"><code class="xref py py-meth docutils literal notranslate"><span class="pre">QuantumState.probabilities_dict()</span></code></a> methods to the interval <code class="docutils literal notranslate"><span class="pre">[0,</span> <span class="pre">1]</span></code>.
This fixes roundoff errors where probabilities could e.g. be larger than 1, leading
to errors in the shot emulation of the sampler.
Fixed <a class="reference external" href="[https://github.com/Qiskit/qiskit-terra/issues/9761](view-source:https://github.com/Qiskit/qiskit-terra/issues/9761)">#9761</a>.</p></li>
</ul>

Notably, the comments reno inserts mess with the docutils parsing, and cause each bullet point to be placed in its own ul.

I think it's possible to fiddle with the spacing around the comments or the indentation of them to get the correct parsing, but I don't remember precisely.

Refactor "Summary of Quantum Operations" page

Tasks

Replace "What is Qiskit" section

The docs should have a page defining Qiskit, designed to be a "single source of truth" that others can refer to. Ideally when people google "what is qiskit" this should be the first page they see.

What the new page should cover:

  • Qiskit, Primitives, Runtime, Provider
  • Qiskit ecosystem, i.e. what is not Qiskit
  • maybe: information about qiskit 1.0? some background info about historical versions/naming?
  • maybe: introduction to Qiskit Patterns?

SME collaborators (involve for planning and review):

@lerongil , Tushar, Blake, @1ucian0 , @javabster

supporting resources:

Qiskit definition from Qiskit readme:

Qiskit is an open-source SDK for working with quantum computers at the level of extended quantum circuits, operators, and primitives.

This library is the core component of Qiskit, which contains the building blocks for creating and working with quantum circuits, quantum operators, and primitive functions (sampler and estimator). It also contains a transpiler that supports optimizing quantum circuits and a quantum information toolbox for creating advanced quantum operators

Tutorial improvement & deduplication ideas

Built off of Qiskit/qiskit-tutorials#1473.

Quantum circuits

Advanced circuits

Operators -> Remove in 0.45

Maybe deprecate in 0.44 now.

  • operator_flow: remove since optflow is deprecated.
  • gradients_framework: remove since optflow is deprecated.

Epic: Prepare for open source contributions

Before starting this epic we should decide the following:

  • What types of contributions do we want to encourage/accept?
  • Who should we accept contributions from?
  • How can we make it as easy as possible for people to submit feedback or suggestions?
  • How do we alert the appropriate people for new open issues and PRs?
  • What branching/PR strategy should we enforce in this new repo -> do we need a dev contract?
  • How should we document requirements/expectations/procedures for contributions?

Tasks

  1. content migration ๐Ÿš’
    abbycross javabster
  2. content migration ๐Ÿš’
  3. infra ๐Ÿ—๏ธ
    arnaucasau frankharkins
  4. content migration ๐Ÿš’
    abbycross
  5. infra ๐Ÿ—๏ธ
  6. abbycross

Refactor "Primitives examples" page

this page was originally written only with the runtime primitives in mind, but now that we are also including qiskit docs we should update this page to include more information about the qiskit primitives as well.

Additionally, the title "primitives examples" is a bit vague, any suggestions for a new title?

Set up link checker

We should make sure that internal links are valid for the state of the docs in the PR, i.e. HEAD. That is, if we reorganize HTML pages, that's fine as long as we update the right links.

External links should be valid no matter what.

Tasks

No tasks being tracked yet.

migrate files from `qiskit` to `Qiskit/docs` and convert `.rst` files to `.mdx`

The following pages currently live in https://github.com/Qiskit/qiskit/tree/main/docs and and https://github.com/Qiskit/qiskit-tutorials/tree/master/tutorials. They should be moved to this repo and stored in either the start, build, test, run or optimize folders.

Important: Files in .ipynb format should be migrated over without changes, maintaining the git history. Files in .rst format should first be moved over in their existing format (with git history maintained) and then converted to .mdx once the file has been moved here

Files to migrate to docs/start

Files to migrate to docs/transpile

Files to migrate to docs/test

Files to migrate to docs/run

Files to migrate to docs/other

Note: the following pages should not be moved over:

Discussion: What to do with extra docs pages?

The following pages exist in qiskit.org/documentation but it is unclear where they should live in docs.quantum-computing.com (or if they should be moved at all). We should decide whether or not to migrate them to this repo and include them in 1docs or not

Also for both qiskit and qiskit runtime there are release notes pages that don't currently have a home in 1docs:

cc @1ucian0

Epic: Migrate docs files to docs repo

For the next release of 1docs we need to combine multiple existing sources of documentation into this repo. Depending on the current location/format of each file they will need one of the following action items:

  • The file already exists in .mdx and just needs to be moved over as is
  • The file already exists in .mdx, it needs to be moved over and co-authors added
  • the file already exists in .ipynb, it needs to be moved over and co-authors added
  • The file already exists in ipynb in an open source repo and can be moved over as is (preserving authors and commit history)
  • The file exists in .rst format, it needs to be moved over (preserving authors and commit history) and then converted to .mdx

NOTE: to make this migration as smooth as possible we should aim to move the files over with as little changes to the content/pedagogy as possible. Many of these pages will indeed require content improvements at a later stage, but for this migration the only changes we should be making are adding co-authors, adjusting file names/paths, converting .rst to .mdx.

Tasks

  1. 38 of 39
    content migration ๐Ÿš’
    Eric-Arellano
  2. 0 of 17
    content migration ๐Ÿš’
    Eric-Arellano
  3. 0 of 2
    content migration ๐Ÿš’
    Eric-Arellano

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.