Giter VIP home page Giter VIP logo

qiskit_sphinx_theme'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 quantum 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 them 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

qiskit_sphinx_theme's People

Contributors

1ucian0 avatar airwoodix avatar arnaucasau avatar coruscating avatar delapuente avatar eric-arellano avatar frankharkins avatar garrison avatar guillermo-mijares-vilarino avatar huangjunye avatar jakelishman avatar javabster avatar karlaspuldaro avatar maldoalberto avatar mtreinish avatar nonhermitian avatar paniash avatar taalexander avatar y4izus avatar

Stargazers

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

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

qiskit_sphinx_theme's Issues

Migrate metapackage `docs/index.rst` to `qiskit_sphinx_theme` repo

This file in the metapackage defines the content for the main landing page for qiskit.org/documentation.

It would be better if this page could be refactored into an html file that could be kept here and deployed straight to IBM COS.

Converting to html and removing the sphinx build from the equation will make this easier to maintain and allow us to develop more complex frontend features in futures that are not well supported by .rst

Migrate 'QC in a nutshell' page from metapackage to `qiskit_sphinx_theme`

This file in the metapackage defines the content for https://qiskit.org/documentation/qc_intro.html.

It would be better if this page could be refactored into an html file that could be kept here and deployed straight to IBM COS.

Converting to html and removing the sphinx build from the equation will make this easier to maintain and allow us to develop more complex frontend features in futures that are not well supported by .rst

Automatically add permalink to Dropdown and Tabs components created by `sphinx-design`

The theme adds permalinks to section headers by default but not for components that are created by sphinx-design such as Dropdown and Tabs. It would be great to add permalinks to those components as well so that those sections can be directly referred to elsewhere.

A use case is the dropdown in the Supplementary Information section of qiskit.circuit module level documentation page.

image

In Qiskit/qiskit#8443, we are adding another dropdown. Dropdown are great for hidden unnecessary information by default.

Dropdown in sphinx-design are implemented as the standard HTML <details> and <summary> tags. Below is the source code of the dropdown in qiskit.circuit module level documentation page.

<details class="sd-sphinx-override sd-dropdown sd-card sd-mb-3 sd-fade-in-slide-down">
<summary class="sd-summary-title sd-card-header">
Quantum Circuit Properties<div class="sd-summary-down docutils">
<svg version="1.1" width="1.5em" height="1.5em" class="sd-octicon sd-octicon-chevron-down" viewBox="0 0 24 24" aria-hidden="true"><path fill-rule="evenodd" d="M5.22 8.72a.75.75 0 000 1.06l6.25 6.25a.75.75 0 001.06 0l6.25-6.25a.75.75 0 00-1.06-1.06L12 14.44 6.28 8.72a.75.75 0 00-1.06 0z"></path></svg></div>
<div class="sd-summary-up docutils">
<svg version="1.1" width="1.5em" height="1.5em" class="sd-octicon sd-octicon-chevron-up" viewBox="0 0 24 24" aria-hidden="true"><path fill-rule="evenodd" d="M18.78 15.28a.75.75 0 000-1.06l-6.25-6.25a.75.75 0 00-1.06 0l-6.25 6.25a.75.75 0 101.06 1.06L12 9.56l5.72 5.72a.75.75 0 001.06 0z"></path></svg></div>
</summary><div class="sd-summary-content sd-card-body docutils">
...
...
</details>

This is how section links are implemented. I think it's pretty standard, but I have on idea about HTML and CSS ><.

<section id="supplementary-information">
<h2>Supplementary Information<a class="headerlink" href="[#supplementary-information](view-source:file:///Users/junye/Documents/GitHub/qiskit-dev/terra-repos/qiskit-terra-2/docs/_build/html/apidocs/circuit.html#supplementary-information)" title="Permalink to this heading"></a></h2>
...
...
</section>

Add Segment to the qiskit documentation page

Requires some investigation, but would be great to add segment tracking to the sphinx theme layout.html.

Set up should be dynamic enough to handle each qiskit repo pulling in the layout.html

(description updated 22 Aug by @javabster)

Links to sub headings not present

Back when we used the rtd theme there was a nice feature where a section, subsection, etc would have a pilcrow next to it which would give a direct link to that. Since moving the qiskit documentation to the qiskit_sphinx_theme this doesn't seem to exist anymore. It's an issue for me primarily in the release notes https://qiskit.org/documentation/release_notes.html#notable-changes where its very useful to have a direct link to the section notes for a particular release to point someone to it.

Migrate Maintainers Guide page from metapackage to `qiskit_sphinx_theme`

This file in the metapackage defines the content for https://qiskit.org/documentation/maintainers_guide.html.

It would be better if this page could be refactored into an .html file that could be kept here and deployed straight to IBM COS.

Converting to html and removing the sphinx build from the equation will make this easier to maintain and allow us to develop more complex frontend features in futures that are not well supported by .rst

Migrate Contributing Guide page from metapackage to `qiskit_sphinx_theme`

This file in the metapackage defines the content for https://qiskit.org/documentation/contributing_to_qiskit.html.

It would be better if this page could be refactored into an .html file that could be kept here and deployed straight to IBM COS.

Converting to html and removing the sphinx build from the equation will make this easier to maintain and allow us to develop more complex frontend features in futures that are not well supported by .rst

Decouple top menu structure from content

In the theme, the top menu structure and its content are in the same file so is not possible to reuse the layout if we need a different content. It would be nice to have this two things decoupled and start reusing layouts instead of creating new ones

Migrate Deprecation Policy page from metapackage to `qiskit_sphinx_theme`

This file in the metapackage defines the content for https://qiskit.org/documentation/deprecation_policy.html.

It would be better if this page could be refactored into an .html file that could be kept here and deployed straight to IBM COS.

Converting to html and removing the sphinx build from the equation will make this easier to maintain and allow us to develop more complex frontend features in futures that are not well supported by .rst

As a Qiskit User I need to know that the sidebar options and search bar are specific to the repo I am currently viewing

The new Runtime tutorials sidebar looks great, but if we are going to have the same style of sidebar for each package, perhaps we need a way of indicating in the sidebar (e,g. a subheading or something) that those links and search bar are for that specific repo. Otherwise for example a user might think they are searching through the whole docs site when in reality they are only seeing info for a specific package. I suggest doing something like this:

Image

API doc "methods" level docstring keywords are not rendered with special headings

Environment

  • Qiskit Terra version:
  • Python version:
  • Operating system:

What is happening?

In the "Class" level docstring, "Parameters", "Returns", "Raises" keywords are rendered nicely while this is not true in the "methods" level docstrings

https://qiskit.org/documentation/stubs/qiskit.circuit.QuantumCircuit.html

image

https://qiskit.org/documentation/stubs/qiskit.circuit.QuantumCircuit.combine.html
image

How can we reproduce the issue?

Go to API reference, choose a class and then a method, for example: https://qiskit.org/documentation/stubs/qiskit.circuit.QuantumCircuit.combine.html

What should happen?

API doc "methods" level docstring keywords should be rendered with special headings similar to "Class" level dosctring.

Any suggestions?

I am still not familiar with the doc building process yet but I suspect this is something we can address in https://github.com/Qiskit/qiskit_sphinx_theme Please move the issue to that repo if it is more appropriate

Create a How-To example

On Qiskit docs 2.0 we would like to divide documentation in different types using the divio framework. For that, we are working on a tutorials audit to see what kind of documentation we already have. It's not been easy because no file fits 100% the framework.

Following @HuangJunye suggestion, having an example of every type of documentation could help us with the categorization.

The idea is convert one of the tutorials we already have in a How-To that follows divio framework. It would be nice to have both to compare the old and the new in order to understand what we need for that update. If we already have an example of How-To, please, you could just add the link :)

Single Dispatch function type annotations overlap with function signature

In Qiskit/rustworkx#241 I'm adding a dispatch API that runs type specific functions based on the input type. These are built using the functools single dispatch decorator: https://docs.python.org/3/library/functools.html#functools.singledispatch

With the qiskit_sphinx_docs theme this render the signature for each supported input type separately and list the input type as an annotation on this dispatched argument, to each signature which is good way to show the supported types and any differences between them. But the input type is not spaced correctly and looks like it's not even part of the signature string so it overlaps with other text in the function signature making it hard to read. For example:

Screenshot_2021-01-27_11-48-40

Add Right to Left support for Qiskit Documentation

Who are we building this for?

Few Qiskit enthusiasts have reached out to volunteer to translate the Qiskit Documentation to Urdu any right to left language scripts.

“Wants to”

The current documentation theme - Qiskit sphinx theme doesn't support RTL languages.

“So that”:

The team can focus better in translating and increasing the reach of Qiskit among the community speaking languages that use right to left scripts.

Create a standard sidebar structure in `layout.html`

The layout.html should have a standard structure that can be pulled in by all qiskit repos.

Current plan:

[language dropdown]

[search box]

Qiskit {Repo Name} Documentation
   Overview
   Getting Started
   Tutorials
   How to Guides
   API Reference
   FAQs
   Release Notes
   GitHub

[previous releases list]

Open questions for discussion:

  • Should we require every page listed above or just some or none?
  • Which pages should we insist be there and which should be optional?
  • Should we allow individual repos to add their own links to the sidebar list?

cc: @HuangJunye @agebbie

Feedback buttons in Tutorials (and similar places)

What is the expected behavior?

It would be great to get user feedback directly in places where they interact with our code. One option could be to add a feedback button in the Qiskit tutorials (or how-tos once we have them) that would send users to an airtable/feedback form/GitHub repo. That way users don't have to actively search for a place to give feedback but we make it very easy and we can get information that's fresh out of the oven 😄

Jupyter notebooks should support buttons/links and maybe we can use the same interface for feedback we use in other places (like qiskit.org).

Create an explanation example

On Qiskit docs 2.0 we would like to divide documentation in different types using the divio framework. For that, we are working on a tutorials audit to see what kind of documentation we already have. It's not been easy because no file fits 100% the framework.

Following @HuangJunye suggestion, having an example of every type of documentation could help us with the categorization.

The idea is convert one of the tutorials we already have in an explanation that follows divio framework. It would be nice to have both to compare the old and the new in order to understand what we need for that update. If we already have an example of explanation, please, you could just add the link :)

Content audit for qiskit documentation

Content on documentation comes from different repos and in different ways, so we need to know where those files live:

In addition, the idea is to organize the documentation following the structure proposed by divio. Right now we have 3 types of documentation: API References, getting started files and tutorials. First one is attached to the code but the second and third ones are on different folders. We would like to know if those tutorials and getting started files fits the tutorials definition given on divio or if they belongs to any of the other categories: API References, how-to guides or explanations.

A proposal is to come up with a summary with this structure (I've added an example):

Project Tutorial Source File Doc type
Qiskit Nature Electronic Structure Link on qiskit-nature repo Tutorial

Where:

  • Project can be:
    • Qiskit core
    • Qiskit machine learning
    • Qiskit nature
    • Qiskit finance
    • Qiskit optimization
    • Qiskit experiments
    • Qiskit dynamics
    • Qiskit metal
    • Qiskit partners
  • Tutorial is the name of the tutorial and point to the page under qiskit.org/documentation. If the tutorial is under a category, you can add it too
  • Source file is the name to the repo where the tutorial lives and point to its code file
  • Doc Type can be:
    • API Reference
    • Tutorial
    • How-to guide
    • Explanation

There is a lot of content to review, so I'm gonna split this task in smaller ones

Create a tutorial example

On Qiskit docs 2.0 we would like to divide documentation in different types using the divio framework. For that, we are working on a tutorials audit to see what kind of documentation we already have. It's not been easy because no file fits 100% the framework.

Following @HuangJunye suggestion, having an example of every type of documentation could help us with the categorization.

The idea is convert one of the tutorials we already have in one that follows divio framework. It would be nice to have both to compare the old and the new in order to understand what we need for that update. If we already have an example of tutorial, please, you could just add the link :)

Default values for attributes in API reference should display original case instead of All Caps

Default values for attributes in API reference should display original case instead of All Caps, because some arguments are case sensitive.

For example, name_format = re.compile("[a-z][a-zA-Z0-9_]*") in QuantumRegister is displayed as name_format = re.compile('[A-Z][A-ZA-Z0-9_]*')

image

I am not sure where to fix in the theme to address this. It could also be not due to the theme. In that case, please transfer the issue to the appropriate repo.

Show level 3 headings in "table of content" on the right hand side of the page

Currently only 2 levels of headings are shown. For example: https://qiskit.org/documentation/apidoc/circuit.html
image

Level 1 is used and only used by the title of the page and therefore only level 2 headings are useful. It should be great to show level 3 headings as well to give more information for users to navigate.

For the same example page: https://qiskit.org/documentation/apidoc/circuit.html, showing level 3 headings will show the subsections under "Quantum Circuit API":

  • Quantum Circuit API
    • Quantum Circuit Construction
    • Gates and Instructions
    • Control Flow Operations
    • Parametric Quantum Circuits
    • Random Circuits

Improve README

The README for this repo should be able to tell maintaienrs of other qiskit repos how to set up their /docs folder so that they are pulling in this theme correctly and not overriding the styles

The readme should include:

  • explanation of what the theme provides (top bar, left side bar, footer, optional analytics)
  • how to install the theme and set up their docs folder structure
  • users should NOT override the theme with their own files (i.e. their _templates folder should be empty)
  • user's conf.py must include a html_context variable including analytics_enabled, e.g.
html_context = {
     'analytics_enabled': True
}

Add more info to the README file

We can provide more info related with the project in order to give an overview of it. I could include, for example, directory structure, technology used, how to modify the theme, ...

Set up COS deployment

As a Qiskit docs dev,
I need to be able to deploy html files from this repository to COS when work is merged into main
So that frontend development work can be more efficient (i.e. decoupled from qiskit releases)

As a Qiskit docs dev,
I need the deployment process to documented
So that I can understand the process better and be onboarded quicker

Table header columns do not line wrap or scale horizontally

Table header columns with long header text do not seem to be formatting correctly. For example from: https://qiskit.org/documentation/release_notes.html the text for Qiskit Metpackage Version overlaps with qiskit-terra

image (7)

I've seen this happen on other tables too. I think we just need either line wrap or fix the column width scaling. (it's interesting on my browser it initially looks fine at first, but only overlaps when it renders the grey bar for alternating lines)

As a user, I would like to have just one top menu across all the qiskit.org domain pages

Right now, the top menu under qiskit.org change between the home page and the documentation page. In addition, inside the documentation page, the top menu changes 11 times. We need to have just one top menu in order to improve the UX and also the maintainability (just one place to update instead of 12).

Needed tasks:

  • [Design] Create a prototype for the top menu
  • [Dev] Implement the top menu as web component and serve it on a cdn
  • [Dev] Add the web component to the qiskit.org project
  • [Dev] Add the web component to the qiskit sphinx theme
  • [Dev] Remove top menu from the Qiskit/qiskit repo
  • [Dev] Remove top menu from the Qiskit/qiskit-nature repo
  • [Dev] Remove top menu from the Qiskit/qiskit-finance repo
  • [Dev] Remove top menu from the Qiskit/qiskit-optimization repo
  • [Dev] Remove top menu from the Qiskit/qiskit-machine-learning repo
  • [Dev] Remove top menu from the Qiskit/qiskit-metal repo
  • [Dev] Remove top menu from the Qiskit/qiskit-dynamics repo
  • [Dev] Remove top menu from the Qiskit/qiskit-experiments repo
  • [Dev] Remove top menu from the Qiskit-Partners/mthree repo
  • [Dev] Remove top menu from the Qiskit-Partners/qiskit-ionq repo

Add unified top menu bar to `layout.html`

A new unified top menu for qiskit.org is being developed including an extended dropdown for documentation. The web component development is being tracked here.

Once the top menu component is complete this should be integrated into the theme here in the layout.html

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.