# PyTorch Sphinx Theme2

> PyTorch Sphinx Theme2 documentation.


---

```
%matplotlib inline
```

# Sphinx Gallery Demo

This is a simple example demonstrating the Sphinx Gallery integration
with the PyTorch Sphinx Theme.

## NumPy Arrays

Let's create some arrays and demonstrate basic operations.

```
import numpy as np
```

First, let's create some arrays:

```
z = np.zeros((5, 3))
print(z)
print(z.dtype)
```

```
[[0. 0. 0.]
 [0. 0. 0.]
 [0. 0. 0.]
 [0. 0. 0.]
 [0. 0. 0.]]
float64
```

We can also create arrays with random values:

```
x = np.random.randn(3, 3)
print(x)
```

```
[[ 0.70596858 0.03586909 -0.32731732]
 [-0.61857127 -0.21895023 -0.48648998]
 [-0.6048682 0.34501182 1.88101271]]
```

## Plotting with Matplotlib

The gallery can also display plots:

```
import matplotlib.pyplot as plt

fig, ax = plt.subplots()
ax.plot([1, 2, 3, 4], [1, 4, 2, 3])
ax.set_xlabel('X axis')
ax.set_ylabel('Y axis')
ax.set_title('Simple Plot')
plt.show()
```

![../_images/26d7d6565a3fceec4de237b386b226f86add863efe8e97e041dab8184f60d681.png](../_images/26d7d6565a3fceec4de237b386b226f86add863efe8e97e041dab8184f60d681.png)

---

![Sphinx Gallery Demo](../_images/sphx_glr_example_demo_thumb.png)

sphx_glr_auto_examples_example_demo.py

Sphinx Gallery Demo

[`Download all examples in Python source code: auto_examples_python.zip`](../_downloads/07fcc19ba03226cd3d83d4e40ec44385/auto_examples_python.zip)

[`Download all examples in Jupyter notebooks: auto_examples_jupyter.zip`](../_downloads/6f1e7a639e0699d6164445b55e6c116d/auto_examples_jupyter.zip)

[Gallery generated by Sphinx-Gallery](https://sphinx-gallery.github.io)

---

# Computation times

**00:00.064** total execution time for **auto_examples** files:

| sphx_glr_auto_examples_example_demo.py (`example_demo.py`) | 00:00.064 | 0.0 MB |
| --- | --- | --- |

---

# Changelog

v0.0.1

---

# PyTorch Governance | Build + CI

## How to Add a New Maintainer

For the person to be a maintainer, a person needs to:

- Land at least six commits to the related part of the PyTorch repository
- At least one of these commits must be submitted in the last six months

To add a qualified person to the maintainers' list, please create
a PR that adds a person to the [persons of interests](https://pytorch.org/docs/main/community/persons_of_interest.html) page and
[merge_rules](https://github.com/pytorch/pytorch/blob/main/.github/merge_rules.yaml) files. Current maintainers will cast their votes of
support. Decision criteria for approving the PR:

- Not earlier than two business days passed before merging (ensure the majority of the contributors have seen it)
- PR has the correct label (module: ci)
- There are no objections from the current maintainers
- There are at least three net *thumbs up* from current maintainers (or all maintainers vote *thumbs up* when the module has less than 3 maintainers).

---

Note

This page has been deprecated. Please refer to the [Contribution Guide](https://github.com/pytorch/pytorch/wiki/The-Ultimate-Guide-to-PyTorch-Contributions) on the PyTorch Wiki.

# PyTorch Contribution Guide

PyTorch is a GPU-accelerated Python tensor computation package for
building deep neural networks using a tape-based autograd systems.

## Contribution Process

The PyTorch organization is governed by [PyTorch
Governance](governance.html) and the technical guide to contributing
can be found in [CONTRIBUTING.md](https://github.com/pytorch/pytorch/blob/main/CONTRIBUTING.md).

The PyTorch development process involves a healthy amount of open
discussions between the core development team and the community.

PyTorch operates similarly to most open source projects on GitHub.
However, if you've never contributed to an open source project before,
here is the basic process.

- **Figure out what you're going to work on.** The majority of open
source contributions come from people scratching their own itches.
However, if you don't know what you want to work on, or are just
looking to get more acquainted with the project, here are some tips
for how to find appropriate tasks:

- Look through the [issue
tracker](https://github.com/pytorch/pytorch/issues/) and see if
there are any issues you know how to fix. Issues that are
confirmed by other contributors tend to be better to investigate.
We also maintain some labels for issues that are likely to be
good for new people, e.g., **bootcamp** and **1hr**, although
these labels are less well maintained.
- Join us on [dev discuss](https://dev-discuss.pytorch.org/)
and let us know you're interested in getting to
know PyTorch. We're very happy to help out researchers and
partners get up to speed with the codebase.
- **Figure out the scope of your change and reach out for design
comments on a GitHub issue if it's large.** The majority of pull
requests are small; in that case, no need to let us know about what
you want to do, just get cracking. But if the change is going to be
large, it's usually a good idea to get some design comments about it
first by [submitting an RFC](https://github.com/pytorch/rfcs/blob/master/README.md).

- If you don't know how big a change is going to be, we can help you
figure it out! Just post about it on
[issues](https://github.com/pytorch/pytorch/issues/) or
[dev discuss](https://dev-discuss.pytorch.org/).
- Some feature additions are very standardized; for example, lots of
people add new operators or optimizers to PyTorch. Design
discussion in these cases boils down mostly to, "Do we want this
operator/optimizer?" Giving evidence for its utility, e.g., usage
in peer reviewed papers, or existence in other frameworks, helps a
bit when making this case.

- **Adding operators / algorithms from recently-released research**
is generally not accepted unless there is overwhelming evidence that
this newly published work has ground-breaking results and will eventually
become a standard in the field. If you are not sure where your method falls,
open an issue first before implementing a PR.
- Core changes and refactors can be quite difficult to coordinate
since the pace of development on the PyTorch main branch is quite fast.
Definitely reach out about fundamental or cross-cutting changes;
we can often give guidance about how to stage such changes into
more easily reviewable pieces.
- **Code it out!**

- See the [CONTRIBUTING.md](https://github.com/pytorch/pytorch/blob/main/CONTRIBUTING.md) file for advice for working with PyTorch in a
technical form.
- **Open a pull request.**

- If you are not ready for the pull request to be reviewed, create a draft
pull request first - you can later convert it to a full PR by pressing
"Ready for review" button. You can also prepend the title of the PR with
"[WIP]" ("work in progress") while it's still in draft. We will ignore
draft PRs when doing review passes. If you are working on a complex change,
it's good to start things off as a draft, because you will need to spend
time looking at CI results to see if things worked out or not.
- Find an appropriate reviewer for your change. We have some folks
who regularly go through the PR queue and try to review
everything, but if you happen to know who the maintainer for a
given subsystem affected by your patch is, feel free to include
them directly on the pull request. You can learn more about
[Persons of Interest](https://pytorch.org/docs/main/community/persons_of_interest.html)
that could review your code.
- **Iterate on the pull request until it's accepted!**

- We'll try our best to minimize the number of review round trips and
block PRs only when there are major issues. For the most common
issues in pull requests, take a look at Common Mistakes.
- Once a pull request is accepted and CI is passing, there is
nothing else you need to do; we will merge the PR for you.

## Getting Started

### Proposing New Features

New feature ideas are best discussed on a specific issue. Please include
as much information as you can, any accompanying data, and your proposed
solution. The PyTorch team and community frequently review new issues
and comments where they think they can help. If you feel confident in
your solution, go ahead and implement it.

### Reporting Issues

If you've identified an issue, first search through the [list of
existing issues](https://github.com/pytorch/pytorch/issues) on the
repo. If you are unable to find a similar issue, then create a new one.
Supply as much information you can to reproduce the problematic
behavior. Also, include any additional insights like the behavior you
expect.

### Implementing Features or Fixing Bugs

If you want to fix a specific issue, it's best to comment on the
individual issue with your intent. However, we do not lock or assign
issues except in cases where we have worked with the developer before.
It's best to strike up a conversation on the issue and discuss your
proposed solution. The PyTorch team can provide guidance that saves you
time.

Issues that are labeled first-new-issue, low, or medium priority provide
the best entrance points and are great places to start.

### Adding Tutorials

A great deal of the tutorials on [pytorch.org](https://pytorch.org/)
come from the community itself and we welcome additional contributions.
To learn more about how to contribute a new tutorial you can learn more
here: [PyTorch.org Tutorial Contribution Guide on
GitHub](https://github.com/pytorch/tutorials/#contributing)

### Improving Documentation & Tutorials

We aim to produce high quality documentation and tutorials. On rare
occasions that content includes typos or bugs. If you find something you
can fix, send us a pull request for consideration.

Take a look at the Documentation section to learn how our system
works.

### Participating in Online Discussions

You can find active discussions happening on the [PyTorch Discussion
Forums](https://discuss.pytorch.org/) for users as well as the
[PyTorch Dev Discussion Forums](https://dev-discuss.pytorch.org/)
for developers and maintainers.

### Submitting Pull Requests to Fix Open Issues

You can view a list of all open issues
[here](https://github.com/pytorch/pytorch/issues). Commenting on an
issue is a great way to get the attention of the team. From here you can
share your ideas and how you plan to resolve the issue.

For more challenging issues, the team will provide feedback and
direction for how to best solve the issue.

If you're not able to fix the issue yourself, commenting and sharing
whether you can reproduce the issue can help the team
identify problem areas.

### Reviewing Open Pull Requests

We appreciate your help reviewing and commenting on pull requests. Our
team strives to keep the number of open pull requests at a manageable
size, we respond quickly for more information if we need it, and we
merge PRs that we think are useful. However, due to the high level of
interest, additional eyes on the pull requests are always appreciated.

### Improving Code Readability

Improving code readability helps everyone. It is often better to submit a
small number of pull requests that touch a few files versus a large pull
request that touches many files. Starting a discussion in the PyTorch
forum [here](https://discuss.pytorch.org/) or on an issue related to
your improvement is the best way to get started.

### Adding Test Cases to Make the Codebase More Robust

Additional test coverage is appreciated.

### Promoting PyTorch

Your use of PyTorch in your projects, research papers, write ups, blogs,
or general discussions around the internet helps to raise awareness for
PyTorch and our growing community. Please reach out to
[marketing@pytorch.org](mailto:marketing%40pytorch.org)
for marketing support.

### Triaging Issues

If you feel that an issue could benefit from a particular tag or level
of complexity, comment on the issue and share your opinion. If you
feel an issue isn't categorized properly, comment and let the team know.

## About Open Source Development

If this is your first time contributing to an open source project, some
aspects of the development process may seem unusual to you.

- **There is no way to "claim" issues.** People often want to "claim"
an issue when they decide to work on it, to ensure that there isn't
wasted work when someone else ends up working on it. This doesn't
really work too well in open source, since someone may decide to work
on something, and end up not having time to do it. Feel free to give
information in an advisory fashion, but at the end of the day, we
will take running code and rough consensus to move forward quickly.
- **There is a high bar for new functionality.** Unlike
in a corporate environment, where the person who wrote code
implicitly "owns" it and can be expected to take care of it for the
code's lifetime, once a pull request is merged into an open
source project, it immediately becomes the collective responsibility
of all maintainers on the project. When we merge code, we are saying
that we, the maintainers, can review subsequent changes and
make a bugfix to the code. This naturally leads to a higher standard
of contribution.

## Common Mistakes To Avoid

- **Did you add tests?** (Or if the change is hard to test, did you
describe how you tested your change?)

- We have a few motivations for why we ask for tests:

1. to help us tell if we break it later
2. to help us tell if the patch is correct in the first place
(yes, we did review it, but as Knuth says, "beware of the
following code, for I have not run it, merely proven it
correct")
- When is it OK not to add a test? Sometimes a change can't be
conveniently tested, or the change is so obviously correct (and
unlikely to be broken) that it's OK not to test it. On the
contrary, if a change seems likely (or is known to be likely)
to be accidentally broken, it's important to put in the time to
work out a testing strategy.
- **Is your PR too long?**

- It's easier for us to review and merge small PRs. The difficulty of
reviewing a PR scales nonlinearly with its size.
- When is it OK to submit a large PR? It helps a lot if there was a
corresponding design discussion in an issue, with sign off from
the people who are going to review your diff. We can also help
give advice about how to split up a large change into individually
shippable parts. Similarly, it helps if there is a complete
description of the contents of the PR: it's easier to review code
if we know what's inside!
- **Comments for subtle things?** In cases where the behavior of your code
is nuanced, please include extra comments and documentation to allow
us to better understand the intention of your code.
- **Did you add a hack?** Sometimes, the right answer is a hack. But
usually, we will have to discuss it.
- **Do you want to touch a very core component?** To prevent
major regressions, pull requests that touch core components receive
extra scrutiny. Make sure you've discussed your changes with the team
before undertaking major changes.
- **Want to add a new feature?** If you want to add new features,
comment your intention on the related issue. Our team tries to
comment on and provide feedback to the community. It's better to have
an open discussion with the team and the rest of the community before
building new features. This helps us stay aware of what you're
working on and increases the chance that it'll be merged.
- **Did you touch code unrelated to the PR?** To aid in code review,
please only include files in your pull request that are directly
related to your changes.

## Frequently Asked Questions

- **How can I contribute as a reviewer?** There is lots of value if
community developers reproduce issues, try out new functionality, or
otherwise help us identify or troubleshoot issues. Commenting on
tasks or pull requests with your environment details is helpful and
appreciated.
- **CI tests failed, what does it mean?** Maybe your PR is based
off a broken main branch? You can try to rebase your change on top
of the latest main branch. You can also see the current status of
main branch's CI at [https://hud.pytorch.org/](https://hud.pytorch.org/).
- **What are the most high risk changes?** Anything that touches build
configuration is a risky area. Please avoid changing these unless
you've had a discussion with the team beforehand.
- **Hey, a commit showed up on my branch, what's up with that?**
Sometimes another community member will provide a patch or fix to
your pull request or branch. This is often needed for getting CI tests
to pass.

## On Documentation

### Python Docs

PyTorch documentation is generated from python source using
[Sphinx](https://www.sphinx-doc.org/en/master/). Generated HTML is
copied to the docs folder in the main branch of
[pytorch.github.io](https://github.com/pytorch/pytorch.github.io/tree/master/docs),
and is served via GitHub pages.

- Site: [https://pytorch.org/docs](https://pytorch.org/docs)
- GitHub: [pytorch/pytorch](https://github.com/pytorch/pytorch/tree/main/docs)
- Served from:
[pytorch/pytorch.github.io](https://github.com/pytorch/pytorch.github.io/tree/master/docs)

### C++ Docs

For C++ code we use Doxygen to generate the content files. The C++ docs
are built on a special server and the resulting files are copied to the
[pytorch/cppdocs](https://github.com/pytorch/cppdocs) repo, and are served from GitHub
pages.

- Site: [https://pytorch.org/cppdocs](https://pytorch.org/cppdocs)
- GitHub: [pytorch/pytorch](https://github.com/pytorch/pytorch/tree/main/docs/cpp)
- Served from: [pytorch/cppdocs](https://github.com/pytorch/cppdocs)

## Tutorials

PyTorch tutorials are documents used to help understand using PyTorch to
accomplish specific tasks or to understand more holistic concepts.
Tutorials are built using
[Sphinx-Gallery](https://sphinx-gallery.readthedocs.io/en/latest/index.html)
from executable python source files, or from restructured-text (rst)
files.

- Site: [https://pytorch.org/tutorials](https://pytorch.org/tutorials)
- GitHub: [pytorch/tutorials](https://github.com/pytorch/tutorials)

### Tutorials Build Overview

For tutorials, [pull
requests](https://github.com/pytorch/tutorials/pulls) trigger a
rebuild of the entire site using CircleCI to test the effects of the
change. This build is sharded into 9 worker builds and takes around 40
minutes total. At the same time, we do a Netlify build using *make
html-noplot*, which builds the site without rendering the notebook
output into pages for quick review.

After a PR is accepted, the site is rebuilt and deployed using GitHub
Actions.

### Contributing a New Tutorial

See [PyTorch.org Tutorial Contribution
Guide](https://github.com/pytorch/tutorials/#contributing).

---

# PyTorch Design Philosophy

This document is designed to help contributors and module maintainers
understand the high-level design principles that have developed over
time in PyTorch. These are not meant to be hard-and-fast rules, but to
serve as a guide to help trade off different concerns and to resolve
disagreements that may come up while developing PyTorch. For more
information on contributing, module maintainership, and how to escalate a
disagreement to the Core Maintainers, please see [PyTorch
Governance](https://pytorch.org/docs/main/community/governance.html).

## Design Principles

### Principle 1: Usability over Performance

This principle may be surprising! As one Hacker News poster wrote:
*PyTorch is amazing! [...] Although I'm confused. How can a ML framework be
not obsessed with speed/performance?* See [Hacker News discussion on
PyTorch](https://news.ycombinator.com/item?id=28066093).

Soumith's blog post on [Growing the PyTorch
Community](https://soumith.ch/posts/2021/02/growing-opensource/?fbclid=IwAR1bvN_xZ8avGvu14ODJzS8Zp7jX1BOyfuGUf-zoRawpyL-s95Vjxf88W7s)
goes into this in some depth, but at a high-level:

- PyTorch's primary goal is usability
- A secondary goal is to have *reasonable* performance

We believe the ability to maintain our flexibility to support
researchers who are building on top of our abstractions remains
critical. We can't see what the future of what workloads will be, but we
know we want them to be built first on PyTorch and that requires
flexibility.

In more concrete terms, we operate in a *usability-first* manner and try
to avoid jumping to *restriction-first* regimes (for example, static shapes,
graph-mode only) without a clear-eyed view of the tradeoffs. Often there
is a temptation to impose strict user restrictions upfront because it
can simplify implementation, but this comes with risks:

- The performance may not be worth the user friction, either because
the performance benefit is not compelling enough or it only applies to
a relatively narrow set of subproblems.
- Even if the performance benefit is compelling, the restrictions can
fragment the ecosystem into different sets of limitations that can
quickly become incomprehensible to users.

We want users to be able to seamlessly move their PyTorch code to
different hardware and software platforms, to interoperate with
different libraries and frameworks, and to experience the full richness
of the PyTorch user experience, not a least common denominator subset.

### Principle 2: Simple Over Easy

Here, we borrow from [The Zen of
Python](https://peps.python.org/pep-0020/):

- *Explicit is better than implicit*
- *Simple is better than complex*

A more concise way of describing these two goals is [Simple Over
Easy](https://www.infoq.com/presentations/Simple-Made-Easy/). Let's start with an example because *simple* and *easy* are
often used interchangeably in everyday English. Consider how one may
model [devices](https://pytorch.org/docs/main/tensor_attributes.html#torch.device)
in PyTorch:

- **Simple / Explicit (to understand, debug):** every tensor is associated
with a device. The user explicitly specifies tensor device movement.
Operations that require cross-device movement result in an error.
- **Easy / Implicit (to use):** the user does not have to worry about
devices; the system figures out the globally optimal device
placement.

In this specific case, and as a general design philosophy, PyTorch
favors exposing simple and explicit building blocks rather than APIs
that are easy-to-use by practitioners. The simple version is immediately
understandable and debuggable by a new PyTorch user: you get a clear
error if you call an operator requiring cross-device movement at the
point in the program where the operator is actually invoked. The easy
solution may let a new user move faster initially, but debugging such a
system can be complex: How did the system make its determination? What
is the API for plugging into such a system and how are objects
represented in its IR?

Some classic arguments in favor of this sort of design come from [A
Note on Distributed
Computation](https://dl.acm.org/doi/book/10.5555/974938) (TLDR: Do not
model resources with very different performance characteristics
uniformly, the details will leak) and the [End-to-End
Principle](http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf)
(TLDR: building smarts into the lower-layers of the stack can prevent
building performant features at higher layers in the stack, and often
doesn't work anyway). For example, we could build operator-level or
global device movement rules, but the precise choices aren't obvious and
building an extensible mechanism has unavoidable complexity and latency
costs.

A caveat here is that this does not mean that higher-level "easy" APIs
are not valuable; certainly there is a value in, for example,
higher-levels in the stack to support efficient tensor computations
across heterogeneous compute in a large cluster. Instead, what we mean
is that focusing on simple lower-level building blocks helps inform the
easy API while still maintaining a good experience when users need to
leave the beaten path. It also allows space for innovation and the
growth of more opinionated tools at a rate we cannot support in the
PyTorch core library, but ultimately benefit from, as evidenced by
our [rich ecosystem](https://pytorch.org/ecosystem/). In other
words, not automating at the start allows us to potentially reach levels
of good automation faster.

### Principle 3: Python First with Best In Class Language Interoperability

This principle began as **Python First**:

> PyTorch is not a Python binding into a monolithic C++ framework.
> It is built to be deeply integrated into Python. You can use it
> naturally like you would use [NumPy](https://www.numpy.org/),
> [SciPy](https://www.scipy.org/), [scikit-learn](https://scikit-learn.org/),
> or other Python libraries. You can write your new neural network
> layers in Python itself, using your favorite libraries and use
> packages such as [Cython](https://cython.org/) and
> [Numba](http://numba.pydata.org/). Our goal is to not reinvent
> the wheel where appropriate.

One thing PyTorch has needed to deal with over the years is Python
overhead: we first rewrote the autograd engine in C++, then the majority
of operator definitions, then developed TorchScript and the C++
frontend.

Still, working in Python provides easily the best experience for our
users: it is flexible, familiar, and perhaps most importantly, has a
huge ecosystem of scientific computing libraries and extensions
available for use. This fact motivates a few of our most recent
contributions, which attempt to hit a Pareto optimal point close to the
Python usability end of the curve:

- [TorchDynamo](https://dev-discuss.pytorch.org/t/torchdynamo-an-experiment-in-dynamic-python-bytecode-transformation/361),
a Python frame evaluation tool capable of speeding up existing
eager-mode PyTorch programs with minimal user intervention.
- [torch_function](https://pytorch.org/docs/main/notes/extending.html#extending-torch)
and [torch_dispatch](https://dev-discuss.pytorch.org/t/what-and-why-is-torch-dispatch/557)
extension points, which have enabled Python-first functionality to be
built on-top of C++ internals, such as the [torch.fx
tracer](https://pytorch.org/docs/stable/fx.html)
and [functorch](https://github.com/pytorch/functorch)
respectively.

These design principles are not hard-and-fast rules, but hard won
choices and anchor how we built PyTorch to be the debuggable, hackable
and flexible framework it is today. As we have more contributors and
maintainers, we look forward to applying these core principles with you
across our libraries and ecosystem. We are also open to evolving them as
we learn new things and the AI space evolves, as we know it will.

---

# PyTorch Governance | Mechanics

## Summary

PyTorch adopts a technical governance structure that is hierarchical.

- A community of **contributors** who file issues, make pull requests,
and contribute to the project.
- A small set of **module maintainers** drive each module of the PyTorch
project.
- They are overseen by **core maintainers**, who drive the
overall project direction.
- The core maintainers have a **lead core maintainer**
who is the catch-all decision maker.

All maintainers are expected to have a strong bias towards
PyTorch's design philosophy.

Beyond the maintainers, the community is encouraged to contribute,
file issues, make proposals, review pull requests and be present
in the community. Given contributions and willingness to invest,
anyone can be accepted as a maintainer and provided write access
or ownership of parts of the codebase.

Technical governance is strictly separated from business governance.
Separating technical from business governance ensures that there is
no way for any person or company to "buy their way into" the
technical guidance of the project. Additionally, membership in
the technical governance process is for **individuals**, not companies.
That is, there are no seats reserved for specific companies, and
membership is associated with the person rather than the company
employing that person.

## Module Maintainers

Modules are defined as GitHub repositories within the PyTorch org,
or as directories within the core repository
[pytorch/pytorch](https://github.com/pytorch/pytorch).
Each module will have its own maintainer group. Maintainer
groups are responsible for reviewing and approving commits,
improving design, and changing the scope of the module.
Each maintainer group may adopt its own rules and procedures
for making decisions (majority vote being default). Module
maintainers have the right to dispute decisions made by other
module maintainers - especially if it affects them. When
disputes are made, the module maintainer group should
provide a reasonable and public explanation of the dispute,
the relevant arguments, and the resolution. In the exceptional
cases where module maintainers cannot come to a conclusion
themselves, they will escalate to core maintainers for review.
The escalations are resolved by the core maintainers in
accordance with their rules and procedures.

Each maintainer group should publish publicly available
communication for their module (a vision, rough roadmap,
design docs, any disputes and dispute resolutions) so that
contributors and other interested parties understand the
future direction of the project and can participate in discussion.

Responsibilities of the maintainer includes:

- Triaging high priority issues of the module
- Triaging and reviewing and landing high priority pull requests of the module
- Supporting public documentation related to the module
- Running public developer meetings

## Core Maintainers

The core maintainers are expected to have a deep understanding
of the PyTorch code base and design philosophies. Their responsibilities
include:

- Articulating a cohesive long-term vision for the project
- Negotiating and resolving contentious issues in ways
acceptable to all parties involved
- Receiving broad requests for changes from stakeholders of
PyTorch and evaluating / accepting them (small module-level
requests are handled by module maintainers)

The core maintainers as a group have the power to veto any
decision made at a Module maintainer level. The core
maintainers have power to resolve disputes as they see fit.
The core maintainers should publicly articulate their
decision-making, and give a clear reasoning for their
decisions, vetoes and dispute resolution.

The core maintainers are admins of the PyTorch GitHub Org
and are listed in [Maintainers](https://pytorch.org/docs/stable/community/persons_of_interest.html).

## Lead Core Maintainer (BDFL)

There may be decisions in which the core maintainers cannot
come to a consensus. To make such difficult decisions, the
core maintainers have an assigned and publicly declared Lead
Core Maintainer amongst them, also commonly known in open-source
governance models as a BDFL.

The Lead Core Maintainer should publicly articulate their
decision-making, and give a clear reasoning for their
decisions. The Lead Core Maintainer is also responsible for
confirming or removing core maintainers.

## Nominating, Confirming and Removing Maintainers

### The Principles

- Membership in module maintainer groups is given to **individuals**
on **merit basis** after they demonstrated strong expertise of the
component through contributions, reviews and discussions and are
aligned with how the component fits in overall PyTorch direction.
- For membership in the maintainer group the individual has to
demonstrate strong and continued alignment with the overall
PyTorch principles.
- No term limits for module maintainers or core maintainers
- Light criteria of moving module maintenance to 'emeritus'
status if they don't actively participate over long periods
of time. Each module maintainer group may define the inactive
period that's appropriate for that module.
- The membership is for an individual, not a company.

### The Process for Nomination

- Each module has its own process. Please contact module maintainers for more information.
However, if there is no process identified, you can file a request to the core
maintainers by submitting [this form](https://share.hsforms.com/1fh3SpHFMR2ihEBQ2orgN8A4tvhy).
Core maintainers are meeting every three months.
- If you are submitting a request to the core maintainers, the information in your request
must include the following items:

- The nominees depth and breadth of code, review and design
contributions on the module
- Testimonials (positive and negative) of the nominee's interactions
with the maintainers, users, and the community
- General testimonials of support from the maintainers
- The core maintainers then evaluate all information and make
a final decision to Confirm or Decline the nomination. The
decision of the core maintainers has to be articulated well
and would be public.

### The Process for Removal

- Similar to the process for nomination, anyone in the community
can nominate a person to be removed from a Module maintainer
position or a Core maintainer position.
- A person can also self-nominate to be removed
- The core maintainers (excluding persons with conflict of
interest) will request or put together more information around
the following:

- Their activity (or lack of) on the project
- Their changing thinking of the space, which results in
conflict with the overall direction of the project
- Other information that makes them unfit to be a maintainer,
such as Code of Conduct issues, their activity outside the
scope of the project that conflicts with the project's values
- **Conflicts of interest**: filial or romantic relationships
- The core maintainers then evaluate all information and make
a final decision to Confirm or Decline the removal. The decision
of the core maintainers has to be articulated well and would be
public.

### Nominating Core Maintainers

- Any core or module maintainer can nominate someone to become a
core maintainer
- The lead maintainer (BDFL) is responsible for evaluating the
nomination.
- The lead maintainer requests or puts together more information
around the strength of the candidate to be a core maintainer:

- Letters of support from other core and module maintainers
- General letters of support from stakeholders within the PyTorch
community
- Any new relevant information that is befitting for the candidacy
- The lead maintainer evaluates all information and makes a final
decision to Confirm or Decline the nomination, with a clear public
articulation of their reasoning behind the decision.

### Removing the Lead Core Maintainer and Nominating a New Lead Core Maintainer

- A super-majority of core maintainers (75%) can choose to
remove the Lead Core Maintainer
- After a removal of the Lead Core Maintainer or in unforeseen
circumstances (such as permanent unavailability of the Lead Core
Maintainer), the core maintainers follow a Ranked-Choice voting
method to elect a new Lead Core Maintainer.

## Add, Remove, and Re-Scope Modules and Projects

The core maintainers together are responsible for taking
decisions on adding, removing and re-scoping new modules
in the PyTorch org, either as new repositories in the
PyTorch GitHub org, or as folders in the
[pytorch/pytorch](https://github.com/pytorch/pytorch)
repository.

They invite proposals from members in the community
(including themselves) for such changes.
The proposals are open-ended, but should have some basic
ground-work to make a convincing case to make change. The
following is an example approach to this process:

1. Interview researchers / stakeholders, talk to community, gather issues;
2. Read papers, attend conferences, build example pipelines based on experience;
3. Create a state of the world - make sure this change is necessary,
for example adding a new project or module is worth the maintenance
cost; or removing a project or module will not remove too much value
from PyTorch;
4. Create a proposal; the proposal covers the maintainership, development
and community plan once the proposal is approved.

The core maintainers take final decisions on the proposal, articulating
the reasoning behind the decision publicly.

## Decision Making

### Uncontroversial Changes

Primary work happens through issues and pull requests on
GitHub. Maintainers should avoid pushing their changes directly to
the PyTorch repository, instead relying on pull requests. Approving a
pull request by a core or module maintainer allows it to be merged
without further process. Core and module maintainers, as listed on
the [Maintainers](https://pytorch.org/docs/stable/community/persons_of_interest.html)
page and within [CODEOWNERS](https://github.com/pytorch/pytorch/blob/master/CODEOWNERS)
ultimately approve these changes.

Notifying relevant experts about an issue or a pull request
is important. Reviews from experts in the given interest area are
strongly preferred, especially on pull request approvals. Failure to do
so might end up with the change being reverted by the relevant expert.

### Controversial Decision Process

Substantial changes in a given interest area require a GitHub issue to
be opened for discussion. This includes:

- Any semantic or syntactic change to the PyTorch framework or library.
- Backwards-incompatible changes to the Python or C++ API.
- Additions to the core framework or library, including substantial new
functionality within an existing library.
- Removal of core features or platform support

Core and module maintainers ultimately approve these changes.

### General Project Policies

PyTorch has been established as PyTorch a Series of LF Projects, LLC.
Policies applicable to PyTorch and participants in PyTorch, including
guidelines on the usage of trademarks, are located at [https://www.lfprojects.org/policies/](https://www.lfprojects.org/policies/).

PyTorch participants acknowledge that the copyright in all new contributions
will be retained by the copyright holder as independent works of authorship
and that no contributor or copyright holder will be required to assign copyrights
to the project. Except as described below, all code contributions to the project
must be made using the 3-Clause-BSD License available here:
[https://opensource.org/licenses/BSD-3-Clause](https://opensource.org/licenses/BSD-3-Clause) (the "Project License").
All outbound code will be made available under the Project License.
The Maintainers may approve the use of an alternative open license or
licenses for inbound or outbound contributions on an exception basis.

## FAQ

**Q: What if I would like to own (or partly own) a part of the project
such as a feature area or domain library, for example** [Linear Algebra](https://github.com/pytorch/pytorch/tree/master/torch/linalg)
**or** [Torch Vision](https://github.com/pytorch/vision) **?**
This is absolutely possible.
The first step is to start contributing to the existing project area and
supporting its health and success. In addition to this, you can
make a proposal through a GitHub issue for new functionality or changes
to improve the project area.

**Q: What if I am a company looking to use PyTorch internally for
development, can I be granted or purchase a board seat to drive the
project direction?** No, the PyTorch project is strictly driven by the
a maintainer project philosophy and clearly separates technical
governance from business governance. However, if you want to be
involved in sponsorship and support, you can become involved in the
PyTorch Foundation (PTF) and sponsorship through this. You can also
have individual engineers look to become maintainers, but this is
not guaranteed and is merit-based.

**Q: Does the PyTorch project support grants or ways to support
independent developers using or contributing to the project?** No, not
at this point. We are however looking at ways to better support the
community of independent developers around PyTorch. If you have
suggestions or inputs, please reach out on the PyTorch forums to
discuss.

**Q: How do I contribute code to the project?** If the change is
relatively minor, a pull request on GitHub can be opened up immediately
for review and merge by the project committers. For larger changes,
please open an issue to make a proposal to discuss prior. Please also
see the [PyTorch Contributor
Wiki](https://github.com/pytorch/pytorch/wiki/The-Ultimate-Guide-to-PyTorch-Contributions) for contribution
for a walkthrough.

**Q: Can I become a committer on the project?** Unfortunately, the
current commit process to PyTorch involves an interaction with Facebook
infrastructure that can only be triggered by Facebook employees. We are
however looking at ways to expand the committer base to individuals
outside of Facebook and will provide an update when the tooling exists
to allow this.

**Q: What if I would like to deliver a PyTorch tutorial at a conference
or otherwise? Do I need to be 'officially' a committer to do this?** No,
we encourage community members to showcase their work wherever and
whenever they can. Please reach out to
[marketing@pytorch.org](mailto:marketing%40pytorch.org)
for marketing support.

---

# Community

- [PyTorch Governance | Build + CI](build_ci_governance.html)
- [PyTorch Contribution Guide](contribution_guide.html)
- [PyTorch Design Philosophy](design.html)
- [PyTorch Governance | Mechanics](governance.html)
- [PyTorch Governance | Maintainers](persons_of_interest.html)

---

# PyTorch Governance | Maintainers

## Responsibilities

- Triage and fix high priority issues assigned to the module or library
- Triage, review, and land high priority pull requests assigned to the module or library
- Answer module or library questions on [discuss.pytorch.org](https://discuss.pytorch.org/)
and [dev-discuss.pytorch.org](https://dev-discuss.pytorch.org/)
- Maintain public user and development documentation
- Run meetings and share minutes plus roadmap on a half or quarterly basis

## Lead Core Maintainer (BDFL)

- Soumith Chintala ([soumith](https://github.com/soumith))

## Core Maintainers

- Soumith Chintala ([soumith](https://github.com/soumith))
- Edward Yang ([ezyang](https://github.com/ezyang))
- Greg Chanan ([gchanan](https://github.com/gchanan))
- Dmytro Dzhulgakov ([dzhulgakov](https://github.com/dzhulgakov))
- Nikita Shulga ([malfet](https://github.com/malfet))
- Alban Desmaison ([albanD](https://github.com/albanD))
- Piotr Bialecki ([ptrblck](https://github.com/ptrblck))

## Module-level maintainers

### NN APIs (torch.nn)

- Mikayla Gawarecki ([mikaylagawarecki](https://github.com/mikaylagawarecki))
- Alban Desmaison ([albanD](https://github.com/albanD))
- Joel Schlosser ([jbschlosser](https://github.com/jbschlosser))
- (emeritus) Greg Chanan ([gchanan](https://github.com/gchanan))
- (emeritus) Soumith Chintala ([soumith](https://github.com/soumith))
- (emeritus) Sam Gross ([colesbury](https://github.com/colesbury))
- (emeritus) Adam Paszke ([apaszke](https://github.com/apaszke))

### Optimizers (torch.optim)

- Jane Xu ([janeyx99](https://github.com/janeyx99))
- Alban Desmaison ([albanD](https://github.com/albanD))
- Joel Schlosser ([jbschlosser](https://github.com/jbschlosser))
- (emeritus) Soumith Chintala ([soumith](https://github.com/soumith))
- (emeritus) Ilqar Ramazanli ([iramazanli](https://github.com/iramazanli))
- (emeritus) Vincent Quenneville-Belair ([vincentqb](https://github.com/vincentqb))

### Autograd (torch.autograd)

- Jeffrey Wan ([soulitzer](https://github.com/soulitzer))
- Alban Desmaison ([alband](https://github.com/alband))
- Edward Yang ([ezyang](https://github.com/ezyang))
- (emeritus) Adam Paszke ([apaszke](https://github.com/apaszke))

### TorchDynamo

- Animesh Jain ([anijain2305](https://github.com/anijain2305))
- Jason Ansel ([jansel](https://github.com/jansel))
- Edward Yang ([ezyang](https://github.com/ezyang))

### TorchInductor

- Elias Ellison ([eellison](https://github.com/eellison))
- Horace He ([Chillee](https://github.com/Chillee))
- Shunting Zhang ([shunting314](https://github.com/shunting314))
- Jason Ansel ([jansel](https://github.com/jansel))
- Jiong Gong ([jgong5](https://github.com/jgong5))

### Cudagraph Tree

- Elias Ellison ([eellison](https://github.com/eellison))

### PT2 Dispatcher

- Brian Hirsh ([bdhirsh](https://github.com/bdhirsh))
- Richard Zou ([zou3519](https://github.com/zou3519))
- Horace He ([Chillee](https://github.com/Chillee))
- Edward Yang ([ezyang](https://github.com/ezyang))

### PT2 Export (torch.export)

- Avik Chaudhuri ([avikchaudhuri](https://github.com/avikchaudhuri))
- Yanan Cao ([gmagogsfm](https://github.com/gmagogsfm))

### AOT Inductor (AOTI) & AOTI Runtime

- Bin Bao ([desertfire](https://github.com/desertfire))
- Angela Yi ([angelayi](https://github.com/angelayi))
- Yang Chen ([chenyang78](https://github.com/chenyang78))

### Compilers (JIT / TorchScript / Package / Deploy)

- (emeritus) Elias Ellison ([eellison](https://github.com/eellison))
- (emeritus) Michael Suo ([suo](https://github.com/suo))
- (emeritus) Yanan Cao ([gmagogsfm](https://github.com/gmagogsfm))
- (emeritus) James Reed ([jamesr66a](https://github.com/jamesr66a))
- (emeritus) Jason Ansel ([jansel](https://github.com/jansel))
- (emeritus) Jiong Gong ([jgong5](https://github.com/jgong5))
- (emeritus) Zach Devito ([zdevito](https://github.com/zdevito))

### Distributions & RNG

- Fritz Obermeyer ([fritzo](https://github.com/fritzo))
- Neeraj Pradhan ([neerajprad](https://github.com/neerajprad))
- Alican Bozkurt ([alicanb](https://github.com/alicanb))
- (emeritus) Vishwak Srinivasan ([vishwakftw](https://github.com/vishwakftw))

### Distributed

- Will Constable ([wconstab](https://github.com/wconstab))
- Howard Huang ([H-Huang](https://github.com/H-Huang))
- Wanchao Liang ([wanchaol](https://github.com/wanchaol))
- Ke Wen ([kwen2501](https://github.com/kwen2501))
- Chien-Chin Huang ([fegin](https://github.com/fegin))
- Tristan Rice ([d4l3k](https://github.com/d4l3k))
- (emeritus) Shen Li ([mrshenli](https://github.com/mrshenli))
- (emeritus) Pritam Damania ([pritamdamania87](https://github.com/pritamdamania87))
- (emeritus) Yanli Zhao ([zhaojuanmao](https://github.com/zhaojuanmao))
- (emeritus) Rohan Varma ([rohan-varma](https://github.com/rohan-varma))
- (emeritus) Junjie Wang ([fduwjj](https://github.com/fduwjj))
- (emeritus) Alisson Azzolini ([aazzolini](https://github.com/aazzolini))
- (emeritus) James Reed ([jamesr66a](https://github.com/jamesr66a))
- (emeritus) Kiuk Chung ([kiukchung](https://github.com/kiukchung))
- (emeritus) Pieter Noordhuis ([pietern](https://github.com/pietern))
- (emeritus) Mingzhe Li ([mingzhe09088](https://github.com/mingzhe09088))
- (emeritus) Omkar Salpekar ([osalpekar](https://github.com/osalpekar))

### Multiprocessing

- (emeritus) Simon Wang ([SsnL](https://github.com/SsnL))
- (emeritus) Vitaly Fedyunin ([VitalyFedyunin](https://github.com/VitalyFedyunin))
- (emeritus) Adam Paszke ([apaszke](https://github.com/apaszke))

### Linear Algebra (torch.linalg)

- Mario Lezcano ([lezcano](https://github.com/lezcano))
- (emeritus) Mike Ruberry ([mruberry](https://github.com/mruberry))
- (emeritus) Ivan Yashchuk ([IvanYashchuk](https://github.com/IvanYashchuk))
- (emeritus) Vishwak Srinivasan ([vishwakftw](https://github.com/vishwakftw))
- (emeritus) Nikita Vedeneev ([nikitaved](https://github.com/nikitaved))

### Sparse (torch.sparse)

- (emeritus) Pearu Peterson ([pearu](https://github.com/pearu))
- (emeritus) Nikita Vedeneev ([nikitaved](https://github.com/nikitaved))
- (emeritus) Ivan Yashchuk ([IvanYashchuk](https://github.com/IvanYashchuk))
- (emeritus) Christian Puhrsch ([cpuhrsch](https://github.com/cpuhrsch))
- (emeritus) Andrew James ([amjames](https://github.com/amjames))

### NestedTensor (torch.nested)

- Joel Schlosser ([jbschlosser](https://github.com/jbschlosser))
- Christian Puhrsch ([cpuhrsch](https://github.com/cpuhrsch))
- Driss Guessous ([drisspg](https://github.com/drisspg))
- Mikayla Gawarecki ([mikaylagawarecki](https://github.com/mikaylagawarecki))
- Alban Desmaison ([albanD](https://github.com/albanD))
- (emeritus) Natalia Gimelshein ([ngimel](https://github.com/ngimel))

### MaskedTensor (torch.masked)

- Christian Puhrsch ([cpuhrsch](https://github.com/cpuhrsch))
- (emeritus) George Qi ([george-qi](https://github.com/george-qi))

### Fast Fourier Transform (torch.fft)

- (emeritus) Mike Ruberry ([mruberry](https://github.com/mruberry))
- (emeritus) Peter Bell ([peterbell10](https://github.com/peterbell10))

### MKLDNN

- Xiaobing Zhang ([XiaobingSuper](https://github.com/XiaobingSuper))
- Mingfei Ma ([mingfeima](https://github.com/mingfeima))
- Jiong Gong ([jgong5](https://github.com/jgong5))
- (emeritus) Xiaoqiang Zheng ([zheng-xq](https://github.com/zheng-xq))
- (emeritus) Sam Gross ([colesbury](https://github.com/colesbury))
- (emeritus) Christian Puhrsch ([cpuhrsch](https://github.com/cpuhrsch))
- (emeritus) Ilia Cherniavskii ([ilia-cher](https://github.com/ilia-cher))
- (emeritus) Junjie Bai ([bddppq](https://github.com/bddppq))
- (emeritus) Yinghai Lu ([yinghai](https://github.com/yinghai))
- (emeritus) Vitaly Fedyunin ([VitalyFedyunin](https://github.com/VitalyFedyunin))
- (emeritus) Jianhui Li ([Jianhui-Li](https://github.com/Jianhui-Li))

### CUDA

- Natalia Gimelshein ([ngimel](https://github.com/ngimel))
- Edward Yang ([ezyang](https://github.com/ezyang))
- Piotr Bialecki ([ptrblck](https://github.com/ptrblck))
- Christian Sarofeen ([csarofeen](https://github.com/csarofeen))
- (emeritus) Andrew Tulloch ([ajtulloch](https://github.com/ajtulloch))
- (emeritus) Xiaoqiang Zheng ([zheng-xq](https://github.com/zheng-xq))

### AMD/ROCm/HIP

- Jeff Daily ([jeffdaily](https://github.com/jeffdaily))
- Jithun Nair ([jithunnair-amd](https://github.com/jithunnair-amd))
- (emeritus) Junjie Bai ([bddppq](https://github.com/bddppq))

### Build + CI

- Nikita Shulga ([malfet](https://github.com/malfet))
- Eli Uriegas ([seemethere](https://github.com/seemethere))
- Alban Desmaison ([alband](https://github.com/alband))
- Andrey Talman ([atalman](https://github.com/atalman))
- Zain Rizvi ([ZainRizvi](https://github.com/ZainRizvi))
- (emeritus) Mikey Dagitses ([dagitses](https://github.com/dagitses))
- (emeritus) Omkar Salpekar ([osalpekar](https://github.com/osalpekar))
- (emeritus) Nirav Mehta ([mehtanirav](https://github.com/mehtanirav))
- (emeritus) Zhuojie Zhou ([zhouzhuojie](https://github.com/zhouzhuojie))
- (emeritus) Edward Yang ([ezyang](https://github.com/ezyang))
- (emeritus) Karl Ostmo ([kostmo](https://github.com/kostmo))

### Performance Tools

- Taylor Robie ([robieta](https://github.com/robieta))
- Xu Zhao ([xuzhao9](https://github.com/xuzhao9))
- (emeritus) Victor Bittorf ([bitfort](https://github.com/bitfort))
- (emeritus) Gisle Dankel ([gdankel](https://github.com/gdankel))
- (emeritus) Natalia Gimelshein ([ngimel](https://github.com/ngimel))
- (emeritus) Mingzhe Li ([mingzhe09088](https://github.com/mingzhe09088))

### C++ API

- (emeritus) Joel Schlosser ([jbschlosser](https://github.com/jbschlosser))
- (emeritus) Will Feng ([yf225](https://github.com/yf225))

### C10 utils and operator dispatch

- Brian Hirsh ([bdhirsh](https://github.com/bdhirsh))
- Edward Yang ([ezyang](https://github.com/ezyang))
- (emeritus) Dmytro Dzhulgakov ([dzhulgakov](https://github.com/dzhulgakov))
- (emeritus) Sebastian Messmer ([smessmer](https://github.com/smessmer))

### ONNX exporter

- Shubham Bhokare ([shubhambhokare1](https://github.com/shubhambhokare1))
- Justin Chu ([justinchuby](https://github.com/justinchuby))
- Xavier Dupré ([xadupre](https://github.com/xadupre))
- Titai Wang ([titaiwangms](https://github.com/titaiwangms))
- (emeritus) Bowen Bao ([BowenBao](https://github.com/BowenBao))
- (emeritus) Thiago Crepaldi ([thiagocrepaldi](https://github.com/thiagocrepaldi))
- (emeritus) Aaron Bockover ([abock](https://github.com/abock))
- (emeritus) Gary Miguel ([garymm](https://github.com/garymm))
- (emeritus) Lara Haidar ([lara-hdr](https://github.com/lara-hdr))
- (emeritus) Lu Fang ([houseroad](https://github.com/houseroad))
- (emeritus) Negin Raoof ([neginraoof](https://github.com/neginraoof))
- (emeritus) Spandan Tiwari ([spandantiwari](https://github.com/spandantiwari))

### LiteInterpreter

- (emeritus) David Reiss ([dreiss](https://github.com/dreiss))
- (emeritus) Raziel Guevara ([raziel](https://github.com/raziel))
- (emeritus) Linbin Yu ([linbinyu](https://github.com/linbinyu))
- (emeritus) Ivan Kobzarev ([IvanKobzarev](https://github.com/IvanKobzarev))
- (emeritus) Tao Xu ([xta0](https://github.com/xta0))

### Quantization (torch/ao)

- Mark Saroufim ([msaroufim](https://github.com/msaroufim))
- Vasiliy Kuznetsov ([vkuzo](https://github.com/vkuzo))
- Jerry Zhang ([jerryzh168](https://github.com/jerryzh168))
- (emeritus) Zafar Takhirov ([z-a-f](https://github.com/z-a-f))
- (emeritus) Raghuraman Krishnamoorthi ([raghuramank100](https://github.com/raghuramank100))

### Windows

- (emeritus) Guoliang Hua ([nbcsm](https://github.com/nbcsm))
- (emeritus) Teng Gao ([gaoteng-git](https://github.com/gaoteng-git))
- (emeritus) Peter Johnson ([peterjc123](https://github.com/peterjc123))

### Apple M1/MPS/Metal

- Kulin Seth ([kulinseth](https://github.com/kulinseth))
- Alban Desmaison ([alband](https://github.com/alband))
- Nikita Shulga ([malfet](https://github.com/malfet))
- (emeritus) Ramin Azarmehr ([razarmehr](https://github.com/razarmehr))

### PowerPC

- (emeritus) Alfredo Mendoza ([avmgithub](https://github.com/avmgithub))

### x86 CPU

- Mingfei Ma ([mingfeima](https://github.com/mingfeima))
- Jiong Gong ([jgong5](https://github.com/jgong5))

### AArch64 CPU

- Sunita Nadampalli ([snadampal](https://github.com/snadampal))

### Docs / Tutorials

- Svetlana Karslioglu ([svekars](https://github.com/svekars))

## Library-level maintainers

### XLA

- Jack Cao ([JackCaoG](https://github.com/JackCaoG))
- Daniel Sohn ([jysohn23](https://github.com/jysohn23))
- Zach Cain ([zcain117](https://github.com/zcain117))
- Brian Hirsh ([bdhirsh](https://github.com/bdhirsh))
- Gregory Chanan ([gchanan](https://github.com/gchanan))
- (emeritus) Ailing Zhang ([ailzhang](https://github.com/ailzhang))
- (emeritus) Davide Libenzi ([dlibenzi](https://github.com/dlibenzi))
- (emeritus) Alex Suhan ([asuhan](https://github.com/asuhan))

### TorchServe

- Li Ning ([lxning](https://github.com/lxning))
- Ankith Gunapal ([agunapal](https://github.com/agunapal))
- Hamid Shojanazeri ([HamidShojanazeri](https://github.com/HamidShojanazeri))
- (emeritus) Mark Saroufim ([msaroufIm](https://github.com/msaroufIm))
- (emeritus) Manoj Rao ([mycpuorg](https://github.com/mycpuorg))
- (emeritus) Vamshi Dantu ([vdantu](https://github.com/vdantu))
- (emeritus) Dhanasekar Karuppasamy ([dhanainme](https://github.com/dhanainme))

### TorchVision

- Nicolas Hug ([NicolasHug](https://github.com/NicolasHug))
- Philip Meier ([pmeier](https://github.com/pmeier))
- Victor Fomin ([vfdev-5](https://github.com/vfdev-5))
- (emeritus) Francisco Massa ([fmassa](https://github.com/fmassa))
- (emeritus) Vasilis Vryniotis ([datumbox](https://github.com/datumbox))
- (emeritus) Yosua Michael Maranatha ([YosuaMichael](https://github.com/YosuaMichael))
- (emeritus) Joao Gomes ([jdsgomes](https://github.com/jdsgomes))

### TorchText

- (emeritus) Nayef Ahmed ([Nayef211](https://github.com/Nayef211))
- (emeritus) Parmeet Singh Bhatia ([parmeet](https://github.com/parmeet))
- (emeritus) Guanheng George Zhang ([zhangguanheng66](https://github.com/zhangguanheng66))
- (emeritus) Christian Puhrsch ([cpuhrsch](https://github.com/cpuhrsch))

### TorchAudio

- Moto Hira ([mthrok](https://github.com/mthrok))
- (emeritus) Jeff Hwang ([hwangjeff](https://github.com/hwangjeff))
- (emeritus) Caroline Chen ([carolineechen](https://github.com/carolineechen))
- (emeritus) Xiaohui Zhang ([xiaohui-zhang](https://github.com/xiaohui-zhang))
- (emeritus) Zhaoheng Ni ([nateanl](https://github.com/nateanl))
- (emeritus) Christian Puhrsch ([cpuhrsch](https://github.com/cpuhrsch))
- (emeritus) Vincent QB ([vincentqb](https://github.com/vincentqb))

### TorchRec

- Colin Taylor ([colin2328](https://github.com/colin2328))
- Paul Zhang ([PaulZhang12](https://github.com/PaulZhang12))
- (emeritus) Dmytro Ivchenko ([divchenko](https://github.com/divchenko))

### TorchX

- (emeritus) Tristan Rice ([d4l3k](https://github.com/d4l3k))
- (emeritus) Kiuk Chung ([kiukchung](https://github.com/kiukchung))

### TorchData

- Andrew Ho ([andrewkho](https://github.com/andrewkho))
- Divyansh Khanna ([divyanshk](https://github.com/divyanshk))

### TorchArrow

- (emeritus) Wenlei Xie ([wenleix](https://github.com/wenleix))
- (emeritus) Vitaly Fedyunin ([VitalyFedyunin](https://github.com/VitalyFedyunin))

### ExecuTorch (Edge, Mobile)

- Mergen Nachin ([mergennachin](https://github.com/mergennachin))
- Kimish Patel ([kimishpatel](https://github.com/kimishpatel))
- Dave Bort ([dbort](https://github.com/dbort))
- Martin Yuan ([iseeyuan](https://github.com/iseeyuan))

### TorchTune

- Kartikay Khandelwal ([kartikayk](https://github.com/kartikayk))
- Evan Smothers ([ebsmothers](https://github.com/ebsmothers))
- Joe Cummings ([joecummings](https://github.com/joecummings))

### TorchChat

- Jack Khuu ([Jack-Khuu](https://github.com/Jack-Khuu))
- Jesse White ([byjlw](https://github.com/byjlw))
- (emeritus) Michael Gschwind ([mikekgfb](https://github.com/mikekgfb))

### TorchCodec

- Nicolas Hug ([nicolashug](https://github.com/nicolashug))
- Ahmad Sharif ([ahmadsharif1](https://github.com/ahmadsharif1))
- Scott Schneider ([scotts](https://github.com/scotts))

---

# Configuration

You can configure different parts of the theme.

## Project-wide Configuration

### HTML Theme Options

The theme's project-wide options are defined in the `pytorch_sphinx_theme/theme.conf`
file of this repository, and can be defined in your project's `conf.py` via
`html_theme_options`. For example:

```
html_theme_options = {
 'canonical_url': '',
 'analytics_id': '',
 'logo_only': False,
 'display_version': True,
 'prev_next_buttons_location': 'bottom',
 'style_external_links': False,
 'vcs_pageview_mode': '',
 # Toc options
 'collapse_navigation': True,
 'sticky_navigation': True,
 'navigation_depth': 4,
 'includehidden': True,
 'titles_only': False
}
```

The following options are available:

#### Base options

- `canonical_url` String. This will specify a [canonical url](https://en.wikipedia.org/wiki/Canonical_link_element)
to let search engines know they should give higher ranking to latest version of the docs.
The url points to the root of the documentation and requires a trailing slash.
- `analytics_id` String. Change the Google Analytics ID that is included on pages.
- `display_version` Bool. With this disabled, the version number isn't shown at the top of the sidebar.
- `prev_next_buttons_location` String. can take the value `bottom`, `top`, `both` , or `None`
and will display the "Next" and "Previous" buttons accordingly.
- `style_external_links` Bool. Add an icon next to external links. Defaults to `False`.
- `vcs_pageview_mode` String. Changes how to view files when using display_github, display_gitlab, etc.
When using Github or Gitlab this can be: blob (default), edit, or raw,
on Bitbucket, this can be either: view (default) or edit.

#### TOC Options

These effect how we display the Table of Contents in the side bar. You can read more about them here: [http://www.sphinx-doc.org/en/stable/templating.html#toctree](http://www.sphinx-doc.org/en/stable/templating.html#toctree)

- `collapse_navigation` Bool. With this enabled, you will lose the `[+]` drop downs next to each section in the sidebar.
- `sticky_navigation` Bool. This causes the sidebar to scroll with the main page content as you scroll the page.
- `navigation_depth` Int. Indicate the max depth of the tree; by default, 4 levels are included;
set it to -1 to allow unlimited depth.
- `includehidden` Bool. Specifies if the sidebar includes toctrees marked with the `:hidden:` option
- `titles_only` Bool. If True, removes headers within a page from the sidebar.

Note

Setting `collapse_navigation` to False and using a high `navigation_depth`
can cause projects with many files and a deep file structure to generate HTML files
that are significantly larger in file size and much longer compilation times.

### HTML Context Options

TODO.

## Page-level Configuration

Pages support metadata that changes how the theme renders.
You can currently add the following:

- `:github_url:` This will force the "Edit on GitHub" to the configured URL
- `:bitbucket_url:` This will force the "Edit on Bitbucket" to the configured URL
- `:gitlab_url:` This will force the "Edit on GitLab" to the configured URL

## How the Table of Contents builds

Currently the left menu will build based upon any `toctree(s)` defined in your `index.rst` file.
It outputs 2 levels of depth, which should give your visitors a high level of access to your
docs. If no toctrees are set the theme reverts to sphinx's usual local toctree.

It's important to note that if you don't follow the same styling for your rST headers across
your documents, the toctree will misbuild, and the resulting menu might not show the correct
depth when it renders.

Also note that by default the table of contents is set with `includehidden=True`. This allows you
to set a hidden toc in your index file with the [:hidden:](http://sphinx-doc.org/markup/toctree.html) property that will allow you
to build a toc without it rendering in your index.

By default, the navigation will "stick" to the screen as you scroll. However if your toc
is vertically too large, it will revert to static positioning. To disable the sticky nav
altogether change the setting in `conf.py`.

---

# 5. `test_py_module`

## 5.1. Generated Index

Part of the sphinx build process in generate and index file: [Index](../genindex.html).

## 5.2. Optional parameter args

At this point optional parameters [cannot be generated from code](https://groups.google.com/forum/#!topic/sphinx-users/_qfsVT5Vxpw).
However, some projects will manually do it, like so:

This example comes from [django-payments module docs](http://django-payments.readthedocs.org/en/latest/modules.html#payments.authorizenet.AuthorizeNetProvide).

*class*payments.dotpay.DotpayProvider(*seller_id*, *pin*[, *channel=0*[, *lock=False*], *lang='pl'*])

This backend implements payments using a popular Polish gateway, [Dotpay.pl](http://www.dotpay.pl).

Due to API limitations there is no support for transferring purchased items.

Parameters:

- **seller_id** - Seller ID assigned by Dotpay
- **pin** - PIN assigned by Dotpay
- **channel** - Default payment channel (consult reference guide)
- **lang** - UI language
- **lock** - Whether to disable channels other than the default selected above

## 5.3. Data

Data_item_1

Data_item_2

Data_item_3

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce congue elit eu hendrerit mattis.

Some data link `Data_item_1`.

---

# 3. Paragraph Level Markup

## 3.1. Inline Markup

Paragraphs contain text and may contain inline markup: *emphasis*, **strong emphasis**, `inline literals`,
standalone hyperlinks ([http://www.python.org](http://www.python.org)), external hyperlinks ([Python](http://www.python.org/) [5]), internal cross-references (example),
external hyperlinks with embedded URIs ([Python web site](http://www.python.org)), footnote references
(manually numbered [1], anonymous auto-numbered [3], labeled auto-numbered [2], or symbolic [*]),
citation references ([12]), substitution references ([![EXAMPLE](../_images/yi_jing_01_chien.jpg)](../_images/yi_jing_01_chien.jpg)), and inline hyperlink targets
(see Targets below for a reference back to here). Character-level inline markup is also possible
(although exceedingly ugly!) in *re*`Structured`*Text*. Problems are indicated by |problematic|
text (generated by processing errors; this one is intentional).

Also with `sphinx.ext.autodoc`, which I use in the demo, I can link to `test_py_module.test.Foo`.
It will link you right my code documentation for it.

The default role for interpreted text is Title Reference. Here are some explicit interpreted text roles:
a PEP reference ([**PEP 287**](https://peps.python.org/pep-0287/)); an RFC reference ([**RFC 2822**](https://datatracker.ietf.org/doc/html/rfc2822.html)); a subscript; a superscript;
and explicit roles for *standard* **inline** `markup`.

GUI labels are a useful way to indicate that Some action is to be taken by the user.
The GUI label should not run over `line-height` so as not to interfere with text from adjacent lines.

Key-bindings indicate that the read is to press a button on the keyboard or mouse,
for example MMB and Shift-MMB. Another useful markup to indicate a user action
is to use `menuselection` this can be used to show short and long menus in software.
For example, and `menuselection` can be seen here that breaks is too long to fit on this line.
My ‣ Software ‣ Some menu ‣ Some sub menu 1 ‣ sub menu 2.

Let's test wrapping and whitespace significance in inline literals:
`This is an example of --inline-literal --text, --including some--
strangely--hyphenated-words. Adjust-the-width-of-your-browser-window
to see how the text is wrapped. -- ---- -------- Now note the
spacing between the words of this sentence (words
should be grouped in pairs).`

If the `--pep-references` option was supplied, there should be a live link to PEP 258 here.

## 3.2. Math

This is a test. Here is an equation:
\(X_{0:5} = (X_0, X_1, X_2, X_3, X_4)\).
Here is another:

(1)\[\nabla^2 f =
\frac{1}{r^2} \frac{\partial}{\partial r}
\left( r^2 \frac{\partial f}{\partial r} \right) +
\frac{1}{r^2 \sin \theta} \frac{\partial f}{\partial \theta}
\left( \sin \theta \, \frac{\partial f}{\partial \theta} \right) +
\frac{1}{r^2 \sin^2\theta} \frac{\partial^2 f}{\partial \phi^2}\]

You can add a link to equations like the one above (1) by using `:eq:`.

## 3.3. Meta

## 3.4. Blocks

### 3.4.1. Literal Blocks

Literal blocks are indicated with a double-colon ("::") at the end of
the preceding paragraph (over there `-->`). They can be indented:

```
if literal_block:
 text = 'is left as-is'
 spaces_and_linebreaks = 'are preserved'
 markup_processing = None
```

Or they can be quoted without indentation:

```
>> Great idea!
>
> Why didn't I think of that?
```

### 3.4.2. Line Blocks

This is a line block. It ends with a blank line.

Each new line begins with a vertical bar ("|").
Line breaks and initial indents are preserved.

Continuation lines are wrapped portions of long lines;
they begin with a space in place of the vertical bar.

The left edge of a continuation line need not be aligned with
the left edge of the text above it.

This is a second line block.

Blank lines are permitted internally, but they must begin with a "|".

Take it away, Eric the Orchestra Leader!

> A one, two, a one two three four
> 
> 
> Half a bee, philosophically,
> 
> must, *ipso facto*, half not be.
> 
> But half the bee has got to be,
> 
> *vis a vis* its entity. D'you see?
> 
> 
> 
> But can a bee be said to be
> 
> or not to be an entire bee,
> 
> when half the bee is not a bee,
> 
> due to some ancient injury?
> 
> 
> 
> 
> 
> Singing...

### 3.4.3. Block Quotes

Block quotes consist of indented body elements:

> My theory by A. Elk. Brackets Miss, brackets. This theory goes
> as follows and begins now. All brontosauruses are thin at one
> end, much much thicker in the middle and then thin again at the
> far end. That is my theory, it is mine, and belongs to me and I
> own it, and what it is too.
> 
> 
> 
> 
> --Anne Elk (Miss)

### 3.4.4. Doctest Blocks

```
>>> print 'Python-specific usage examples; begun with ">>>"'
Python-specific usage examples; begun with ">>>"
>>> print '(cut and pasted from interactive Python sessions)'
(cut and pasted from interactive Python sessions)
```

### 3.4.5. Code Blocks

```
# parsed-literal test
curl -O http://someurl/release-2.10.tar-gz
```

Code Blocks can have captions.

```
{
"windows": [
 {
 "panes": [
 {
 "shell_command": [
 "echo 'did you know'",
 "echo 'you can inline'"
 ]
 },
 {
 "shell_command": "echo 'single commands'"
 },
 "echo 'for panes'"
 ],
 "window_name": "long form"
 }
],
"session_name": "shorthands"
}
```

#### 3.4.5.1. Emphasized lines with line numbers

```
1def some_function():
2 interesting = False
3 print 'This line is highlighted.'
4 print 'This one is not...'
5 print '...but this one is.'
```

## 3.5. Sidebar

The first hexagram is made up of six unbroken lines. These unbroken lines stand for the primal power,
which is light-giving, active, strong, and of the spirit. The hexagram is consistently strong in character,
and since it is without weakness, its essence is power or energy. Its image is heaven.
Its energy is represented as unrestricted by any fixed conditions in space and is therefore conceived of as motion.
Time is regarded as the basis of this motion.
Thus the hexagram includes also the power of time and the power of persisting in time, that is, duration.

The power represented by the hexagram is to be interpreted in a dual sense in terms of its action
on the universe and of its action on the world of men. In relation to the universe, the hexagram expresses the strong,
creative action of the Deity. In relation to the human world, it denotes the creative action of the holy man or sage,
of the ruler or leader of men, who through his power awakens and develops their higher nature.

### 3.5.1. Code with Sidebar

Literal includes can also have captions.

```
1# -*- coding: utf-8 -*-
 2"""Test Module for sphinx_rtd_theme."""
 3
 4
 5class Foo:
 6
 7 """Docstring for class Foo.
 8
 9 This text tests for the formatting of docstrings generated from output
10 ``sphinx.ext.autodoc``. Which contain reST, but sphinx nests it in the
11 ``<dl>``, and ``<dt>`` tags. Also, ``<tt>`` is used for class, method names
12 and etc, but those will *always* have the ``.descname`` or
13 ``.descclassname`` class.
14
15 Normal ``<tt>`` (like the <tt> I just wrote here) needs to be shown with
16 the same style as anything else with ````this type of markup````.
17
18 It's common for programmers to give a code example inside of their
19 docstring::
20
21 from test_py_module import Foo
22
23 myclass = Foo()
24 myclass.dothismethod('with this argument')
25 myclass.flush()
26
27 print(myclass)
28
29
30 Here is a link to :py:meth:`capitalize`.
31 Here is a link to :py:meth:`__init__`.
32
33 """
34
35 #: Doc comment for class attribute Foo.bar.
36 #: It can have multiple lines.
37 bar = 1
38
39 flox = 1.5 #: Doc comment for Foo.flox. One line only.
40
```

## 3.6. References

### 3.6.1. Footnotes

### 3.6.2. Citations

Here's a reference to the above, [12], and a [nonexistent] citation.

Here is another type of citation: citation

### 3.6.3. Glossary

This is a glossary with definition terms for thing like Writing:

Documentation

Provides users with the knowledge they need to use something.

Reading

The process of taking information into ones mind through the use of eyes.

Writing

The process of putting thoughts into a medium for other people to read.

### 3.6.4. Targets

This paragraph is pointed to by the explicit "example" target.
A reference can be found under Inline Markup, above. Inline
hyperlink targets are also possible.

Section headers are implicit targets, referred to by name. See
Targets, which is a subsection of `Body Elements`_.

Explicit external targets are interpolated into references such as "[Python](http://www.python.org/) [5]".

Targets may be indirect and anonymous. Thus this phrase may also
refer to the Targets section.

Here's a `hyperlink reference without a target`_, which generates an error.

## 3.7. Directives

### 3.7.1. Contents

These are just a sample of the many reStructuredText Directives. For others, please see:
[http://docutils.sourceforge.net/docs/ref/rst/directives.html](http://docutils.sourceforge.net/docs/ref/rst/directives.html).

### 3.7.2. Centered text

You can create a statement with centered text with `.. centered::`

**This is centered text!**

### 3.7.3. Images & Figures

#### 3.7.3.1. Images

An image directive (also clickable - a hyperlink reference):

![../_images/yi_jing_01_chien.jpg](../_images/yi_jing_01_chien.jpg)

#### 3.7.3.2. Figures

![reStructuredText, the markup syntax](../_images/yi_jing_01_chien.jpg)

A figure is an image with a caption and/or a legend:

| re | Revised, revisited, based on 're' module. |
| --- | --- |
| Structured | Structure-enhanced text, structuredtext. |
| Text | Well it is, isn't it? |

This paragraph is also part of the legend.

A figure directive with center alignment

![../_images/yi_jing_01_chien.jpg](../_images/yi_jing_01_chien.jpg)

This caption should be centered.

### 3.7.4. Admonitions

Attention

Directives at large.

Caution

Don't take any wooden nickels.

Danger

Mad scientist at work!

Error

Does not compute.

Hint

It's bigger than a bread box.

Important

- Wash behind your ears.
- Clean up your room.

- Including the closet.
- The bathroom too.

- Take the trash out of the bathroom.
- Clean the sink.
- Call your mother.
- Back up your data.

Note

This is a note.
Equations within a note:
\(G_{\mu\nu} = 8 \pi G (T_{\mu\nu} + \rho_\Lambda g_{\mu\nu})\).

Tip

15% if the service is good.

| Example |
| --- |
| Thing1 |
| Thing2 |
| Thing3 |

Warning

Strong prose may provoke extreme mental exertion.
Reader discretion is strongly advised.

And, by the way...

You can make up your own admonition too.

### 3.7.5. Topics, Sidebars, and Rubrics

This is a rubric

### 3.7.6. Target Footnotes

### 3.7.7. Replacement Text

I recommend you try [Python, *the* best language around](http://www.python.org/) [5].

### 3.7.8. Compound Paragraph

This paragraph contains a literal block:

```
Connecting... OK
Transmitting data... OK
Disconnecting... OK
```

and thus consists of a simple paragraph, a literal block, and
another simple paragraph. Nonetheless it is semantically *one*
paragraph.

This construct is called a *compound paragraph* and can be produced
with the "compound" directive.

## 3.8. Download Links

[`This long long long long long long long long long long long long long long long download link should be blue, normal weight text with a leading icon, and should wrap white-spaces`](../_downloads/64d5ed2a09e9d7815be87c81948753c9/yi_jing_01_chien.jpg)

---

# 4. Lists & Tables

## 4.1. Lists

### 4.1.1. Enumerated Lists

1. Arabic numerals.

1. lower alpha)

1. (lower roman)

1. upper alpha.

1. upper roman)
2. Lists that don't start at 1:

1. Three
2. Four

1. C
2. D

1. iii
2. iv
3. List items may also be auto-enumerated.

### 4.1.2. Definition Lists

Term

Definition

Termclassifier

Definition paragraph 1.

Definition paragraph 2.

Term

Definition

### 4.1.3. Option Lists

For listing command-line options:

-a

command-line option "a"

-b file

options can have arguments
and long descriptions

--long

options can be long also

--input=file

long options can also have
arguments

--very-long-option

The description can also start on the next line.

The description may contain multiple body elements,
regardless of where it starts.

-x, -y, -z

Multiple options are an "option group".

-v, --verbose

Commonly-seen: short & long options.

-1 file, --one=file, --two file

Multiple options with arguments.

/V

DOS/VMS-style options too

There must be at least two spaces between the option and the description.

### 4.1.4. Field list

Author:

David Goodger

Address:

123 Example Street
Example, EX Canada
A1B 2C3

Contact:

[docutils-develop@lists.sourceforge.net](mailto:docutils-develop%40lists.sourceforge.net)

Authors:

Me; Myself; I

organization:

humankind

date:

$Date: 2012-01-03 19:23:53 +0000 (Tue, 03 Jan 2012) $

status:

This is a "work in progress"

revision:

$Revision: 7302 $

version:

1

copyright:

This document has been placed in the public domain. You
may do with it as you wish. You may copy, modify,
redistribute, reattribute, sell, buy, rent, lease,
destroy, or improve it, quote it at length, excerpt,
incorporate, collate, fold, staple, or mutilate it, or do
anything else to it that your or anyone else's heart
desires.

field name:

This is a generic bibliographic field.

field name 2:

Generic bibliographic fields may contain multiple body elements.

Like this.

Dedication:

For Docutils users & co-developers.

abstract:

This document is a demonstration of the reStructuredText markup
language, containing examples of all basic reStructuredText
constructs and many advanced constructs.

### 4.1.5. Bullet Lists

- A bullet list

- Nested bullet list.
- Nested item 2.
- Item 2.

Paragraph 2 of item 2.

- Nested bullet list.
- Nested item 2.

- Third level.
- Item 2.
- Nested item 3.
- `inline literall`
- `inline literall`
- `inline literall`

#### 4.1.5.1. Second list level

- here is a list in a second-level section.
- [yahoo](http://www.yahoo.com)
- [yahoo](http://www.yahoo.com)

- [yahoo](http://www.yahoo.com)
- here is an inner bullet `oh`

- one more `with an inline literally`. [yahoo](http://www.yahoo.com)

heh heh. child. try to beat this embed:

```
1# -*- coding: utf-8 -*-
 2"""Test Module for sphinx_rtd_theme."""
 3
 4
 5class Foo:
 6
 7 """Docstring for class Foo.
 8
 9 This text tests for the formatting of docstrings generated from output
10 ``sphinx.ext.autodoc``. Which contain reST, but sphinx nests it in the
```
- and another. [yahoo](http://www.yahoo.com)
- [yahoo](http://www.yahoo.com)
- `hi`
- and hehe

##### 4.1.5.1.1. But deeper down the rabbit hole

- I kept saying that, "deeper down the rabbit hole". [yahoo](http://www.yahoo.com)

- I cackle at night [yahoo](http://www.yahoo.com).
- I'm so lonely here in GZ `guangzhou`
- A man of python destiny, hopes and dreams. [yahoo](http://www.yahoo.com)

- [yahoo](http://www.yahoo.com)

- [yahoo](http://www.yahoo.com) `hi`
- `destiny`

### 4.1.6. Hlists

| - First item - Second item - Third item | - Forth item - Fifth item - Sixths item |
| --- | --- |

Hlist with images

| - ![../_images/yi_jing_01_chien.jpg](../_images/yi_jing_01_chien.jpg) This is a short caption for a figure. | - ![../_images/yi_jing_01_chien.jpg](../_images/yi_jing_01_chien.jpg) This is a long caption for a figure. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec porttitor dolor in odio posuere, vitae ornare libero mattis. In lobortis justo vestibulum nibh aliquet, non. |
| --- | --- |

### 4.1.7. Numbered List

1. One,
2. Two.
3. Three with long text. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Sed feugiat sagittis neque quis eleifend. Duis rutrum lectus sit amet mattis suscipit.

- 1. Using bullets and letters. (A)
- 1. Using bullets and letters. (B)
- 1. Using bullets and letters. (C)

## 4.2. Tables

### 4.2.1. Grid Tables

Here's a grid table followed by a simple table:

| Header row, column 1 (header rows optional) | Header 2 | Header 3 | Header 4 |
| --- | --- | --- | --- |
| body row 1, column 1 | column 2 | column 3 | column 4 |
| body row 2 | Cells may span columns. | | |
| body row 3 | Cells may span rows. | - Table cells - contain - body elements. | |
| body row 4 | | | |
| body row 5 | Cells may also be empty: `-->` | | |

| Inputs | Output |
| --- | --- |
| A | B |
| False | False |
| True | False |
| False | True |
| True | True |

#### 4.2.1.1. Giant Tables

| Header 1 | Header 2 | Header 3 | Header 1 | Header 2 | Header 3 | Header 1 | Header 2 | Header 3 | Header 1 | Header 2 | Header 3 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 |
| body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 |
| body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 |
| body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 | body row 1 | column 2 | column 3 |

### 4.2.2. List Tables

| List table | Header 1 | Header 2 | Header 3 long. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet mauris arcu. |
| --- | --- | --- | --- |
| Stub Row 1 | Row 1 | Column 2 | Column 3 long. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet mauris arcu. |
| Stub Row 2 | Row 2 | Column 2 | Column 3 long. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet mauris arcu. |
| Stub Row 3 | Row 3 | Column 2 | Column 3 long. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam sit amet mauris arcu. |

| ![../_images/yi_jing_01_chien.jpg](../_images/yi_jing_01_chien.jpg) This is a short caption for a figure. | ![../_images/yi_jing_01_chien.jpg](../_images/yi_jing_01_chien.jpg) This is a long caption for a figure. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec porttitor dolor in odio posuere, vitae ornare libero mattis. In lobortis justo vestibulum nibh aliquet, non. |
| --- | --- |

---

# 1. Long Sticky Nav

This section demonstrates how the 'sticky_navigation' setting behaves when the menu is very long.
When this section is selected, it will make the menu and the main area scroll when you are at the top of the page.

## 1.1. Example Menu 1

Just a place holder...

## 1.2. Example Menu 2

Just a place holder...

## 1.3. Example Menu 3

Just a place holder...

## 1.4. Example Menu 4

Just a place holder...

## 1.5. Example Menu 5

Just a place holder...

## 1.6. Example Menu 6

Just a place holder...

## 1.7. Example Menu 7

Just a place holder...

## 1.8. Example Menu 8

Just a place holder...

## 1.9. Example Menu 9

Just a place holder...

## 1.10. Example Menu 10

Just a place holder...

## 1.11. Example Menu 11

Just a place holder...

## 1.12. Example Menu 12

Just a place holder...

## 1.13. Example Menu 13

Just a place holder...

## 1.14. Example Menu 14

Just a place holder...

## 1.15. Example Menu 15

Just a place holder...

## 1.16. Example Menu 16

Just a place holder...

## 1.17. Example Menu 17

Just a place holder...

## 1.18. Example Menu 18

Just a place holder...

## 1.19. Example Menu 19

Just a place holder...

## 1.20. Example Menu 20

Just a place holder...

## 1.21. Example Submenu 1

Just a place holder...

### 1.21.1. Submenu 1

Just a place holder...

#### 1.21.1.1. Subsubmenu 1

Just a place holder...

#### 1.21.1.2. Subsubmenu 2

Just a place holder...

### 1.21.2. Submenu 2

Just a place holder...

#### 1.21.2.1. Subsubmenu 1

Just a place holder...

### 1.21.3. Submenu 3

Just a place holder...

### 1.21.4. Submenu 4

Just a place holder...

### 1.21.5. Submenu 5

Just a place holder...

## 1.22. Example Submenu 2

Just a place holder...

### 1.22.1. Submenu 1

Just a place holder...

#### 1.22.1.1. Subsubmenu 1

Just a place holder...

### 1.22.2. Submenu 2

Just a place holder...

#### 1.22.2.1. Subsubmenu 1

Just a place holder...

### 1.22.3. Submenu 3

Just a place holder...

### 1.22.4. Submenu 4

Just a place holder...

### 1.22.5. Submenu 5

Just a place holder...

---

# 1. Structural Elements

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec lorem neque, interdum in ipsum nec,
finibus dictum velit. Ut eu efficitur arcu, id aliquam erat. In sit amet diam gravida, imperdiet tellus eu,
gravida nisl. Praesent aliquet odio eget libero elementum, quis rhoncus tellus tincidunt.
Suspendisse quis volutpat ipsum. Sed lobortis scelerisque tristique. Aenean condimentum risus tellus,
quis accumsan ipsum laoreet ut. Integer porttitor maximus suscipit. Mauris in posuere sapien.
Aliquam accumsan feugiat ligula, nec fringilla libero commodo sed. Proin et erat pharetra.

---

Etiam turpis ante, luctus sed velit tristique, finibus volutpat dui. Nam sagittis vel ante nec malesuada.
Praesent dignissim mi nec ornare elementum. Nunc eu augue vel sem dignissim cursus sed et nulla.
Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.
Pellentesque dictum dui sem, non placerat tortor rhoncus in. Sed placerat nulla at rhoncus iaculis.

## 1.1. Document Section

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum nulla vel neque venenatis,
nec placerat lorem placerat. Cras purus eros, gravida vitae tincidunt id, vehicula nec nulla.
Fusce aliquet auctor cursus. Phasellus ex neque, vestibulum non est vitae, viverra fringilla tortor.
Donec vestibulum convallis justo, a faucibus lorem vulputate vel. Aliquam cursus odio eu felis sodales aliquet.
Aliquam erat volutpat. Maecenas eget dictum mauris. Suspendisse arcu eros, condimentum eget risus sed,
luctus efficitur arcu. Cras ut dictum mi. Nulla congue interdum lorem, semper semper enim commodo nec.

### 1.1.1. Document Subsection

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam efficitur in eros et blandit. Nunc maximus,
nisl at auctor vestibulum, justo ex sollicitudin ligula, id faucibus urna orci tristique nisl.
Duis auctor rutrum orci, in ornare lacus condimentum quis. Quisque arcu velit, facilisis quis interdum ac,
hendrerit auctor mauris. Curabitur urna nibh, porttitor at ante sit amet, vestibulum interdum dolor.
Duis dictum elit orci, tincidunt imperdiet sem pellentesque et. In vehicula pellentesque varius.
Phasellus a turpis sollicitudin, bibendum massa et, imperdiet neque. Integer quis sapien in magna rutrum bibendum.
Integer cursus ex sed magna vehicula finibus. Proin tempus orci quis dolor tempus, nec condimentum odio vestibulum.
Etiam efficitur sollicitudin libero, tincidunt volutpat ligula interdum sed.

#### 1.1.1.1. Document Subsubsection

Donec non rutrum lorem. Aenean sagittis metus at pharetra fringilla. Nunc sapien dolor, cursus sed nisi at,
pretium tristique lectus. Sed pellentesque leo lectus, et convallis ipsum euismod a.
Integer at leo vitae felis pretium aliquam fringilla quis odio. Sed pharetra enim accumsan feugiat pretium.
Maecenas at pharetra tortor. Morbi semper eget mi vel finibus. Cras rutrum nulla eros, id feugiat arcu pellentesque ut.
Sed finibus tortor ac nisi ultrices viverra. Duis feugiat malesuada sapien, at commodo ante porttitor ac.
Curabitur posuere mauris mi, vel ornare orci scelerisque sit amet. Suspendisse nec fringilla dui.

##### 1.1.1.1.1. Document Paragraph

Pellentesque nec est in odio ultrices elementum. Vestibulum et hendrerit sapien, quis vulputate turpis.
Suspendisse potenti. Curabitur tristique sit amet lectus non viverra. Phasellus rutrum dapibus turpis sed imperdiet.
Mauris maximus viverra ante. Donec eu egestas mauris. Morbi vulputate tincidunt euismod. Integer vel porttitor neque.
Donec at lacus suscipit, lacinia lectus vel, sagittis lectus.

# 2. Structural Elements 2

Etiam turpis ante, luctus sed velit tristique, finibus volutpat dui. Nam sagittis vel ante nec malesuada.
Praesent dignissim mi nec ornare elementum. Nunc eu augue vel sem dignissim cursus sed et nulla.
Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.
Pellentesque dictum dui sem, non placerat tortor rhoncus in. Sed placerat nulla at rhoncus iaculis.

## 2.1. Document Section

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum nulla vel neque venenatis,
nec placerat lorem placerat. Cras purus eros, gravida vitae tincidunt id, vehicula nec nulla.
Fusce aliquet auctor cursus. Phasellus ex neque, vestibulum non est vitae, viverra fringilla tortor.
Donec vestibulum convallis justo, a faucibus lorem vulputate vel. Aliquam cursus odio eu felis sodales aliquet.
Aliquam erat volutpat. Maecenas eget dictum mauris. Suspendisse arcu eros, condimentum eget risus sed,
luctus efficitur arcu. Cras ut dictum mi. Nulla congue interdum lorem, semper semper enim commodo nec.

### 2.1.1. Document Subsection

![../_images/yi_jing_01_chien.jpg](../_images/yi_jing_01_chien.jpg)

This is a caption for a figure. Text should wrap around the caption.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam efficitur in eros et blandit. Nunc maximus,
nisl at auctor vestibulum, justo ex sollicitudin ligula, id faucibus urna orci tristique nisl.
Duis auctor rutrum orci, in ornare lacus condimentum quis. Quisque arcu velit, facilisis quis interdum ac,
hendrerit auctor mauris. Curabitur urna nibh, porttitor at ante sit amet, vestibulum interdum dolor.
Duis dictum elit orci, tincidunt imperdiet sem pellentesque et. In vehicula pellentesque varius.
Phasellus a turpis sollicitudin, bibendum massa et, imperdiet neque. Integer quis sapien in magna rutrum bibendum.
Integer cursus ex sed magna vehicula finibus. Proin tempus orci quis dolor tempus, nec condimentum odio vestibulum.
Etiam efficitur sollicitudin libero, tincidunt volutpat ligula interdum sed. Praesent congue sagittis nisl et suscipit.
Vivamus sagittis risus et egestas commodo.Cras venenatis arcu in pharetra interdum.
Donec quis metus porttitor tellus cursus lobortis. Quisque et orci magna. Fusce rhoncus mi mi,
at vehicula massa rhoncus quis. Mauris augue leo, pretium eget molestie vitae, efficitur nec nulla.
In hac habitasse platea dictumst. Sed sit amet imperdiet purus.

---

# Test Docs

Generated

---

# Welcome to PyTorch Sphinx Theme 2 Docs

Theme Documentation

- [Install PyTorch](https://pytorch.org/get-started/locally/)
- [Installation](installing.html)
- [Configuration](configuring.html)
- [Changelog](changelog.html)

Community

- [Community](community/index.html)

Demo Documents

- [1. Structural Elements](demo/structure.html)

- [1.1. Document Section](demo/structure.html#document-section)
- [2. Structural Elements 2](demo/structure.html#structural-elements-2)

- [2.1. Document Section](demo/structure.html#id1)
- [3. Paragraph Level Markup](demo/demo.html)

- [3.1. Inline Markup](demo/demo.html#inline-markup)
- [3.2. Math](demo/demo.html#math)
- [3.3. Meta](demo/demo.html#meta)
- [3.4. Blocks](demo/demo.html#blocks)
- [3.5. Sidebar](demo/demo.html#sidebar)
- [3.6. References](demo/demo.html#references)
- [3.7. Directives](demo/demo.html#directives)
- [3.8. Download Links](demo/demo.html#download-links)
- [4. Lists & Tables](demo/lists_tables.html)

- [4.1. Lists](demo/lists_tables.html#lists)
- [4.2. Tables](demo/lists_tables.html#tables)
- [5. `test_py_module`](demo/api.html)

- [5.1. Generated Index](demo/api.html#generated-index)
- [5.2. Optional parameter args](demo/api.html#optional-parameter-args)
- [5.3. Data](demo/api.html#data)

This is an incredibly long caption for a long menu

- [1. Long Sticky Nav](demo/long.html)

Test Pages

- [Test Myst-NB cells](test-myst.html)
- [SD-Cards Test Page](test-cards.html)
- [IRs](test-glossary.html)
- [Welcome to PyTorch Tutorials](test_tutorials_landing_page.html)
- [Additional Resources](test_tutorials_landing_page.html#additional-resources)

Gallery Examples

Prototype/Unstable

- [Test Prototype Page](prototype/test.html)
- [Unstable Test](unstable/test.html)

- [PyTorch Glossary](_glossary.html)

---

# Installation

## Via Git or Download

Symlink or subtree the `pytorch_sphinx_theme` repository into your documentation at
`docs/_themes/pytorch_sphinx_theme` then add the following two settings to your Sphinx
`conf.py` file:

```
html_theme = "pytorch_sphinx_theme"
html_theme_path = ["_themes", ]
```

---

# Test Prototype Page

Testing a prototype page.

---

# SD-Cards Test Page

This page tests sd-card components for mobile responsiveness.

## Basic 2-Column Grid

Learn the Basics

A step-by-step interactive series for those just starting out
with PyTorch.

Code

[https://pytorch.org/tutorials/beginner/basics/intro.html](https://pytorch.org/tutorials/beginner/basics/intro.html)

Introduction to PyTorch - YouTube Series

Learn the fundamentals of PyTorch through our video series,
perfect for those who prefer learning from videos.

Code Video

[https://pytorch.org/tutorials/beginner/introyt/introyt_index.html](https://pytorch.org/tutorials/beginner/introyt/introyt_index.html)

## Single Card in Grid

Learning PyTorch

Quickly grasp the basics of PyTorch with these bite-sized
foundational recipes.

Code

[https://pytorch.org/tutorials/beginner/deep_learning_60min_blitz.html](https://pytorch.org/tutorials/beginner/deep_learning_60min_blitz.html)

## What You Will Learn / Prerequisites Cards

These are the cards that appear at the top of tutorials (similar to the mobile screenshot):

 What you will learn

- Fundamentals of embeddings and their role in recommendation systems
- How to implement embeddings with PyTorch and TorchRec
- Handling large embedding tables through distributed training
- Advanced optimizations for embedding-based models

 Prerequisites

- PyTorch v2.5 or later with CUDA 11.8 or later
- Python 3.9 or later
- [FBGEMM](https://github.com/pytorch/FBGEMM)
- Basic understanding of neural networks

## 3-Column Grid Test

Card 1

Content for the first card in a 3-column layout.

Card 2

Content for the second card in a 3-column layout.

Card 3

Content for the third card in a 3-column layout.

## 4-Column Grid Test

Item A

Short content.

Item B

Short content.

Item C

Short content.

Item D

Short content.

---

# IRs

PyTorch 2.0 offers two set of IRs for backends to interface with: Core [ATen](_glossary.html#term-ATen) IR and Prims IR.

## Core ATen IR

Core [aten](_glossary.html#term-ATen) ops is the core subset of [aten](_glossary.html#term-ATen) operators that can be used to compose other operators.
Core [aten](_glossary.html#term-ATen) IR is fully functional, and there is no `inplace` or `_out` variants in this opset.
In contrast to Prims IR, core [aten](_glossary.html#term-ATen) ops reuses the existing [aten](_glossary.html#term-ATen) ops in "native_functions.yaml",
and it doesn't further decompose ops into explicit type promotion and broadcasting ops.
This opset is designed to serve as the functional IR to interface with backends.

Warning

This opset is still under active development, more ops will be added in the future.

## Prims IR

Prims IR is a set of primitive operators that can be used to compose other operators.
Prims IR is a lower level opset than core aten IR, and it further decomposes ops into explicit
type promotion and broadcasting ops: prims.convert_element_type and prims.broadcast_in_dim.
This opset is designed to interface with compiler backends.

Warning

This opset is still under active development, more ops will be added in the future.

## Glossary Terms Demo

This section demonstrates tooltips for various glossary terms. Hover over the highlighted terms to see their definitions.

### Operations

An [Operation](_glossary.html#term-Operation) is a unit of work in PyTorch. There are different types of operations:

- **[Native Operation](_glossary.html#term-Native-Operation)**: Operations that come natively with PyTorch ATen
- **[Custom Operation](_glossary.html#term-Custom-Operation)**: Operations defined by users, usually a [Compound Operation](_glossary.html#term-Compound-Operation)
- **[Leaf Operation](_glossary.html#term-Leaf-Operation)**: Basic operations that always have dispatch functions defined
- **[Compound Operation](_glossary.html#term-Compound-Operation)**: Operations composed of other operations (also known as [Composite Operation](_glossary.html#term-Composite-Operation) or [Non-Leaf Operation](_glossary.html#term-Non-Leaf-Operation))

### Kernels

A [Kernel](_glossary.html#term-Kernel) is the implementation of a PyTorch operation. There are two main types:

- **[Device Kernel](_glossary.html#term-Device-Kernel)**: Device-specific kernel of a [Leaf Operation](_glossary.html#term-Leaf-Operation)
- **[Compound Kernel](_glossary.html#term-Compound-Kernel)**: Device-agnostic kernels that belong to [Compound Operations](_glossary.html#term-Compound-Operation)

### JIT Compilation

PyTorch supports [JIT](_glossary.html#term-JIT) (Just-In-Time) compilation through [TorchScript](_glossary.html#term-TorchScript). There are two main approaches:

1. **[Tracing](_glossary.html#term-Tracing)**: Using `torch.jit.trace` on a function to get an executable that can be optimized
2. **[Scripting](_glossary.html#term-Scripting)**: Using `torch.jit.script` to inspect source code and compile it as [TorchScript](_glossary.html#term-TorchScript) code

### Summary Table

| Term | Type | Description |
| --- | --- | --- |
| [ATen](_glossary.html#term-ATen) | Library | Foundational tensor library |
| [Operation](_glossary.html#term-Operation) | Concept | Unit of work |
| [Kernel](_glossary.html#term-Kernel) | Implementation | What happens when an operation executes |
| [JIT](_glossary.html#term-JIT) | Technique | Just-In-Time Compilation |
| [TorchScript](_glossary.html#term-TorchScript) | Interface | JIT compiler and interpreter |

## Intersphinx References

Note: Intersphinx tooltips only work with documentation hosted on Read the Docs that has the embed API enabled.
Most external documentation sites (docs.python.org, docs.pytorch.org, numpy.org) do not support this feature.

The following are standard intersphinx links (clickable but without tooltips):

- [`torch.Tensor`](https://docs.pytorch.org/docs/stable/tensors.html#torch.Tensor) - The main tensor class
- [`torch.zeros()`](https://docs.pytorch.org/docs/stable/generated/torch.zeros.html#torch.zeros) - Create a tensor of zeros
- [`list`](https://docs.python.org/3/library/stdtypes.html#list) - Python's built-in list type

---

# Test Myst-NB cells

Below is an example of a simple myst-nb cell:

```
def print_message():
 message = "Hello, this is a simple print statement!"
 print(message)

print_message()
```

```
Hello, this is a simple print statement!
```

```
def print_message_and_math():
 message = "Hello, this is a simple print statement!"
 math_result = 5 + 3 # Example math operation
 print(message)
 print(f"The result of 5 + 3 is: {math_result}")

print_message_and_math()
```

```
Hello, this is a simple print statement!
The result of 5 + 3 is: 8
```

---

# Welcome to PyTorch Tutorials

**What's new in PyTorch tutorials?**

- [Utilizing Torch Function modes with torch.compile](https://pytorch.org/tutorials/recipes/torch_compile_torch_function_modes.html)
- [Context Parallel Tutorial](https://pytorch.org/tutorials/prototype/context_parallel.html)
- [PyTorch 2 Export Quantization with Intel GPU Backend through Inductor](https://pytorch.org/tutorials/prototype/pt2e_quant_xpu_inductor.html)
- [(beta) Explicit horizontal fusion with foreach_map and torch.compile](https://pytorch.org/tutorials/recipes/foreach_map.html)
- Updated [Inductor Windows CPU Tutorial](https://pytorch.org/tutorials/prototype/inductor_windows.html)

### Learn the Basics

Familiarize yourself with PyTorch concepts and modules. Learn how to load data, build deep neural networks, train and save your models in this quickstart guide.

[Get started with PyTorch](beginner/basics/intro.html)

### PyTorch Recipes

Bite-size, ready-to-deploy PyTorch code examples.

[Explore Recipes](recipes/recipes_index.html)

---

[#### Learn the Basics

A step-by-step guide to building a complete ML workflow with PyTorch.

Getting-Started

![](_static/img/thumbnails/cropped/60-min-blitz.png)](installing.html)

[#### Introduction to PyTorch on YouTube

An introduction to building a complete ML workflow with PyTorch. Follows the PyTorch Beginner Series on YouTube.

Changelog

![](_static/img/thumbnails/cropped/generic-pytorch-logo.png)](changelog)

[#### Learn the Basics

A step-by-step guide to building a complete ML workflow with PyTorch.

Getting-Started

![](_static/img/thumbnails/cropped/60-min-blitz.png)](installing.html)

[#### Introduction to PyTorch on YouTube

An introduction to building a complete ML workflow with PyTorch. Follows the PyTorch Beginner Series on YouTube.

Changelog

![](_static/img/thumbnails/cropped/generic-pytorch-logo.png)](changelog)

[#### Learn the Basics

A step-by-step guide to building a complete ML workflow with PyTorch.

Getting-Started

![](_static/img/thumbnails/cropped/60-min-blitz.png)](installing.html)

[#### Introduction to PyTorch on YouTube

An introduction to building a complete ML workflow with PyTorch. Follows the PyTorch Beginner Series on YouTube.

Changelog

![](_static/img/thumbnails/cropped/generic-pytorch-logo.png)](changelog)

[#### Learn the Basics

A step-by-step guide to building a complete ML workflow with PyTorch.

Getting-Started

![](_static/img/thumbnails/cropped/60-min-blitz.png)](installing.html)

[#### Introduction to PyTorch on YouTube

An introduction to building a complete ML workflow with PyTorch. Follows the PyTorch Beginner Series on YouTube.

Changelog

![](_static/img/thumbnails/cropped/generic-pytorch-logo.png)](changelog)

[#### Learn the Basics

A step-by-step guide to building a complete ML workflow with PyTorch.

Getting-Started

![](_static/img/thumbnails/cropped/60-min-blitz.png)](installing.html)

[#### Introduction to PyTorch on YouTube

An introduction to building a complete ML workflow with PyTorch. Follows the PyTorch Beginner Series on YouTube.

Changelog

![](_static/img/thumbnails/cropped/generic-pytorch-logo.png)](changelog)

[#### Learn the Basics

A step-by-step guide to building a complete ML workflow with PyTorch.

Getting-Started

![](_static/img/thumbnails/cropped/60-min-blitz.png)](installing.html)

[#### Introduction to PyTorch on YouTube

An introduction to building a complete ML workflow with PyTorch. Follows the PyTorch Beginner Series on YouTube.

Changelog

![](_static/img/thumbnails/cropped/generic-pytorch-logo.png)](changelog)

# Additional Resources

### Examples of PyTorch

A set of examples around PyTorch in Vision, Text, Reinforcement Learning that you can incorporate in your existing work.

[Check Out Examples](https://pytorch.org/examples?utm_source=examples&utm_medium=examples-landing)

### PyTorch Cheat Sheet

Quick overview to essential PyTorch elements.

[Open](beginner/ptcheat.html)

### Tutorials on GitHub

Access PyTorch Tutorials from GitHub.

[Go To GitHub](https://github.com/pytorch/tutorials)

### Run Tutorials on Google Colab

Learn how to copy tutorial data into Google Drive so that you can run tutorials on Google Colab.

[Open](beginner/colab.html)

---

# Unstable Test

Just testing if banner works.