Skip to content

P
pytensor
提交 eedc5e88 authored 作者: Brandon T. Willard's avatar Brandon T. Willard 提交者： Brandon T. Willard
浏览文件
操作

Update the developer start guide

上级 1798404b
隐藏空白字符变更
内嵌 并排
正在显示 包含 87 行增加 和 521 行删除
.github/PULL_REQUEST_TEMPLATE.md
浏览文件 @ eedc5e88
......@@ -6,7 +6,7 @@ Here are a few important guidelines and requirements to check before your PR can
+ [ ] The description and/or commit message(s) references the relevant GitHub issue(s).
+ [ ] [`pre-commit`](https://pre-commit.com/#installation) is installed and [set up](https://pre-commit.com/#3-install-the-git-hook-scripts).
+ [ ] The commit messages follow [these guidelines](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+ [ ] The commits correspond to [_relevant logical changes_](https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes), and there are **no commits that fix changes introduced by other commits in the same branch/BR**. If your commit description starts with "Fix...", then you're probably making this mistake.
+ [ ] The commits correspond to [_relevant logical changes_](https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes), and there are **no commits that fix changes introduced by other commits in the same branch/BR**.
+ [ ] There are tests covering the changes introduced in the PR.
Don't worry, your PR doesn't need to be in perfect order to submit it. As development progresses and/or reviewers request changes, you can always [rewrite the history](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_rewriting_history) of your feature/PR branches.
......
aesara/misc/doubleop.py deleted 100644 → 0
浏览文件 @ 1798404b
# This is the example in the Aesara/doc/tutorial/extending_aesara.txt
import aesara
from aesara.graph.basic import Apply
from aesara.graph.op import Op
class DoubleOp(Op):
"""
Double each element of a tensor.
Parameters
----------
x : tensor
Input tensor
Returns
-------
tensor
a tensor of the same shape and dtype as the input with all
values doubled.
Notes
-----
this is a test note
See Also
--------
:class:`~aesara.tensor.elemwise.Elemwise` : You can use this to replace
this example. Just execute `x * 2` with x being an Aesara variable.
.. versionadded:: 0.6
"""
def __eq__(self, other):
return type(self) == type(other)
def __hash__(self):
return hash(type(self))
def __str__(self):
return self.__class__.__name__
def make_node(self, x):
x = aesara.tensor.as_tensor_variable(x)
return Apply(self, [x], [x.type()])
def perform(self, node, inputs, output_storage):
x = inputs[0]
z = output_storage[0]
z[0] = x * 2
def infer_shape(self, fgraph, node, i0_shapes):
return i0_shapes
def grad(self, inputs, output_grads):
return [output_grads[0] * 2]
def R_op(self, inputs, eval_points):
# R_op can receive None as eval_points.
# That means there is no differentiable path through that input.
# If this implies that you cannot compute some outputs,
# return None for those.
if eval_points[0] is None:
return eval_points
return self.grad(inputs, eval_points)
doc/dev_start_guide.rst
浏览文件 @ eedc5e88
......@@ -31,215 +31,44 @@ The Theano Google group is also relevant to (early) Aesara versions:
.. _theano-dev: https://groups.google.com/group/theano-dev
To get up to speed, you'll need to
- Learn some non-basic Python to understand what's going on in some of the
trickier files (like tensor.py).
- Go through the `NumPy documentation`_.
- Learn to write reStructuredText_ for Sphinx_.
- Learn about how unittest_ and pytest_ work
.. _Sphinx: http://sphinx.pocoo.org/
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
.. _NumPy documentation: http://docs.scipy.org/numpy/
.. _unittest: http://docs.python.org/library/unittest.html
.. _pytest: http://docs.pytest.org/en/latest/
.. _quality_contributions:
Requirements for Quality Contributions
======================================
* All code should be accompanied by quality unit tests.
* The code should be compatible with Python 3.6 and above.
* All the code should respect the
`PEP8 Code Style Guide <http://www.python.org/dev/peps/pep-0008>`_.
* The docstrings of all the classes and functions should respect the
`PEP257 <https://www.python.org/dev/peps/pep-0257/>`_ rules and follow the
`Numpy docstring standard
<https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt>`_.
Each point will be referred to more in detail in the following.
Unit tests
----------
When you submit a pull request, your changes will automatically be
tested via our continuous integration (CI).
Just because the tests run automatically does not mean you shouldn't
run them yourself to make sure everything is all right. You can run
only the portion you are modifying to go faster and have CI
make sure there are no broader problems.
To run the test suite with the default options, see
:ref:`test_aesara`.
Setting up your Editor for PEP8
-------------------------------
Here are instructions for :ref:`Vim <vim_pep8>` and :ref:`Emacs
<emacs_pep8>`. If you have similar instructions for other text editors
or IDE, please let us know and we will update this documentation.
.. _vim_pep8:
Vim
~~~
Detection of warnings and errors is done by the `pep8`_ script
(or `flake8`_, that also checks for other things, like syntax
errors). Syntax highlighting and general integration into Vim is done by
the `Syntastic`_ plugin for Vim.
To setup VIM:
#. Install flake8 (if not already installed) with::
pip install flake8
.. warning:: Starting version 3.0.0, flake8 changed its dependencies and
moved its Python API to a legacy module, breaking Aesara's flake8 tests.
We recommend using a version prior to 3.
.. note:: You can use ``easy_install`` instead of ``pip``, and ``pep8``
instead of ``flake8`` if you prefer. The important thing is that the
``flake8`` or ``pep8`` executable ends up in your ``$PATH``.
#. Install vundle with::
git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim
#. Edit ``~/.vimrc`` and add the lines:
.. code-block:: python
set nocompatible " be iMproved, required
filetype off " required
" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'gmarik/Vundle.vim' " let Vundle manage Vundle (required!)
Plugin 'scrooloose/syntastic'
Plugin 'jimf/vim-pep8-text-width'
The following are requirements for a quality pull request (PR)/contribution:
call vundle#end()
* All code should be accompanied by quality unit tests that provide complete
coverage of the features added.
* There is an informative high-level description of the changes, or a reference to an issue describing the changes.
* The description and/or commit messages reference any relevant GitHub issues.
* `pre-commit <https://pre-commit.com/#installation>`_ is installed and `set up <https://pre-commit.com/#3-install-the-git-hook-scripts>`_.
* The commit messages follow `these guidelines <https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>`_.
* The commits correspond to `relevant logical changes <https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes>`_, and there are **no commits that fix changes introduced by other commits in the same branch/BR**.
* There are tests, implemented within the pytest_ framework, covering the changes introduced by the PR.
* `Type hints <https://www.python.org/dev/peps/pep-0484/>`_ are added where appropriate.
" Syntastic settings
" You can run checkers explicitly by calling :SyntasticCheck <checker
let g:syntastic_python_checkers = ['flake8'] "use one of the following checkers:
" flake8, pyflakes, pylint, python (native checker)
let g:syntastic_enable_highlighting = 1 "highlight errors and warnings
let g:syntastic_style_error_symbol = ">>" "error symbol
let g:syntastic_warning_symbol = ">>" "warning symbol
let g:syntastic_check_on_open = 1
let g:syntastic_auto_jump = 0 "do not jump to errors when detected
Don't worry, your PR doesn't need to be in perfect order to submit it. As development progresses and/or reviewers request changes, you can always `rewrite the history <https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_rewriting_history>`_ of your feature/PR branches.
#. Open a new vim and run ``:PluginInstall`` to automatically install the
plugins. When the installation is done, close the installation "window"
with ``:q``.
From now on Vim will check for PEP8 errors and highlight them whenever a
file is saved.
If your PR is an ongoing effort and you would like to involve us in the process,
simply make it a `draft PR <https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests>`_.
A few useful commands
"""""""""""""""""""""
When you submit a PR, your changes will automatically be tested via our
continuous integration (CI). Just because the tests run automatically does not
mean you shouldn't run them yourself to make sure everything is all right. You
can run only the portion you are modifying to go faster and have CI make sure
there are no broader problems.
* Open the list of errors: ``:lopen``, that can be abbreviated in ``:lop``
(denoted ``:lop[en]``).
* Close that list: ``:lcl[ose]``.
* Next error: ``:lne[xt]``.
* Previous error: ``:lp[revious]``.
To run the test suite with the default options, see :ref:`test_aesara`.
Once you fix errors, messages and highlighting will still appear in the
fixed file until you save it again.
We can also configure the ``~/.vimrc`` to make it easier to work with Syntastic.
For instance, to add a summary in the status bar, you can add::
set statusline+=%{SyntasticStatuslineFlag()}
To bind F2 and F3 to navigate to previous and next error, you can add::
map <F2> :lprevious<CR>
map <F3> :lnext<CR>
You can prefix those by ``autocmd FileType python`` if you want these
bindings to work only on Python files.
.. _pep8: http://pypi.python.org/pypi/pep8
.. _flake8: http://pypi.python.org/pypi/flake8
.. _Syntastic: https://github.com/scrooloose/syntastic/
.. _pathogen.vim: https://github.com/tpope/vim-pathogen
.. _quickfix: http://vimdoc.sourceforge.net/htmldoc/quickfix.html#quickfix
.. _emacs_pep8:
Emacs
~~~~~
There is an **excellent** system to configure emacs for Python:
`emacs-for-python
<https://github.com/gabrielelanaro/emacs-for-python>`_. It gathers many
emacs config into one, and modifies them to behave together nicely. You
can use it to check for pep8 compliance and for Python syntax errors.
To install it on Linux, you can do like this:
.. code-block:: bash
cd
git clone https://github.com/gabrielelanaro/emacs-for-python.git ~/.emacs.d/emacs-for-python
Then in your ``~/.emacs`` file, add this:
.. code-block:: common-lisp
;; Mandatory
(load-file "~/.emacs.d/emacs-for-python/epy-init.el")
(add-to-list 'load-path "~/.emacs.d/emacs-for-python/") ;; tell where to load the various files
;; Each of them enables different parts of the system.
;; Only the first two are needed for pep8, syntax check.
(require 'epy-setup) ;; It will setup other loads, it is required!
(require 'epy-python) ;; If you want the python facilities [optional]
(require 'epy-completion) ;; If you want the autocompletion settings [optional]
(require 'epy-editing) ;; For configurations related to editing [optional]
;; [newer version of emacs-for-python]
;; Define f10 to previous error
;; Define f11 to next error
(require 'epy-bindings) ;; For my suggested keybindings [optional]
;; Some shortcut that do not collide with gnome-terminal,
;; otherwise, "epy-bindings" define f10 and f11 for them.
(global-set-key [f2] 'flymake-goto-prev-error)
(global-set-key [f3] 'flymake-goto-next-error)
;; Next two lines are the checks to do. You can add more if you wish.
(epy-setup-checker "pyflakes %f") ;; For python syntax check
(epy-setup-checker "pep8 -r %f") ;; For pep8 check
.. note::
The script highlights problematic lines. This can make part of the
line not readable depending on the background. To replace the line
highlight by an underline, add this to your emacs configuration
file:
.. _Sphinx: http://sphinx.pocoo.org/
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
.. _pytest: http://docs.pytest.org/en/latest/
;; Make lines readable when there is an warning [optional]
(custom-set-faces
'(flymake-errline ((((class color)) (:underline "red"))))
'(flymake-warnline ((((class color)) (:underline "yellow")))))
Documentation and docstrings
----------------------------
* The documentation and the API documentation are generated using `Sphinx`_.
* The documentation should be written in `reStructuredText`_ and the
......@@ -264,24 +93,12 @@ Here is an example on how to add a docstring to a class.
.. testcode:: python
import aesara
from aesara.graph.basic import Variable
from aesara.graph.op import Op
class DoubleOp(Op):
"""
Double each element of a tensor.
Parameters
----------
x : tensor
Input tensor
Returns
-------
tensor
a tensor of the same shape and dtype as the input with all
values doubled.
"""Double each element of a tensor.
Notes
-----
......@@ -289,29 +106,31 @@ Here is an example on how to add a docstring to a class.
See Also
--------
:class:`~aesara.tensor.elemwise.Elemwise` : You can use this to replace
this example. Just execute `x * 2` with x being an Aesara variable.
`Elemwise`: This functionality is already available; just execute
``x * 2`` with ``x`` being an Aesara variable.
"""
def make_node(self, x: Variable):
"""Construct an `Apply` node for this `Op`.
.. versionadded:: 0.6
"""
Parameters
----------
x
Input tensor
This is how it will show up for files that we auto-list in the library
documentation:
"""
...
.. automodule:: aesara.misc.doubleop
:members:
Installation and configuration
==============================
To obtain developer access: register with `GitHub
<http://www.github.com/>`_ and create a fork of `Aesara
<http://www.github.com/aesara-devs/aesara>`_.
To submit PRs, create an account on `GitHub <http://www.github.com/>`_ and fork
`Aesara <http://www.github.com/aesara-devs/aesara>`_.
This will create your own Aesara project on GitHub, referred later
as "YourProfile/Aesara", or "origin", from which you will be able to
contribute to the original Aesara/Aesara, also called "central".
This will create your own clone of the Aesara project on GitHub. It is customary
to assign this Git remote the name "origin", and the official Aesara repository
the name "upstream".
Create a local copy
......@@ -323,254 +142,68 @@ Clone your fork locally with
git clone git@github.com:YOUR_GITHUB_LOGIN/Aesara.git
For this URL to work, you must set your public ssh keys inside your
`github account setting <https://github.com/settings/ssh>`_.
From your local repository, your own fork on GitHub will be called "origin".
Then, add a reference to the original ("central") Aesara repository with
.. code-block:: bash
git remote add central git://github.com/aesara-devs/aesara.git
You can choose another name than "central" to reference Aesara/Aesara
(for instance, NumPy uses "upstream"), but this documentation will stick
to "central."
You can then test your installation of Aesara by following the steps of
:ref:`test_aesara`.
Using your local copy
---------------------
To update your library to the latest revision, you should have a local branch
that tracks ``origin/main``. You can add one (named "trunk" here) with:
.. code-block:: bash
git fetch origin
git branch trunk origin/main
Once you have such a branch, in order to update it, do:
.. code-block:: bash
git checkout trunk
git pull
Keep in mind that this branch should be "read-only": if you want to
patch Aesara, you should work in another branch, like described in the
:ref:`dev_workflow` section below.
Configure Git
-------------
On your local machine, you need to configure git with basic information:
.. code-block:: bash
git config --global user.email you@yourdomain.example.com
git config --global user.name "Your Name Comes Here"
You can also instruct git to use color in diff. For this, you need to
add those lines in the file ~/.gitconfig
.. code-block:: cfg
[color]
branch = auto
diff = auto
interactive = auto
status = auto
.. _dev_workflow:
Development Workflow
====================
Start a new local branch
------------------------
When working on a new feature in your own fork, start from an up-to-date copy
of the `main` branch (the principal one) of the central repository
(Aesara/Aesara on GitHub):
.. code-block:: bash
git fetch origin
git checkout -b my_shiny_feature origin/main
.. note::
This last line is a shortcut for:
For this URL to work, you must set your public SSH keys inside your
`GitHub account setting <https://github.com/settings/ssh>`_.
.. code-block:: bash
From your local repository, your fork on GitHub will be called "origin" by default.
git branch my_shiny_feature origin/main
git checkout my_shiny_feature
Submit your changes to the central repository
---------------------------------------------
Once your code is ready for others to review, you need to commit all the changes and then push your
branch to your GitHub fork first:
Next, add a reference to the original ("upstream") Aesara repository with
.. code-block:: bash
git commit -a -m "Your message here"
.. code-block:: bash
git remote add upstream git://github.com/aesara-devs/aesara.git
git push -u origin my_shiny_feature
You can choose a name other than "upstream" to reference the official Aesara
repository, but this documentation will stick to "upstream."
Then, go to your fork's GitHub page on the GitHub website, select your
feature branch and hit the "Pull Request" button in the top right
corner. This will signal the maintainers that you wish to submit your
changes for inclusion in ``origin/main``.
You can then test your installation of Aesara by following the steps of :ref:`test_aesara`.
Address reviewer comments
-------------------------
Your pull request will be reviewed by members of the core development
team. If your branch is not directly accepted, the reviewers will use
GitHub's system to add "notes", either general (on the entire commit),
or "line notes", relative to a particular line of code.
In order to have the pull request accepted, you may have to answer
the reviewer's questions, you can do that on GitHub.
You may also have to edit your code to address their concerns. Some
of the usual requests include fixing typos in comments, adding or
correcting comments, adding unit tests in the test suite. In order to
do that, you should continue your edits in the same branch you used (in
this example, "my_shiny_feature"). For instance, if you changed your
working branch, you should first:
.. code-block:: bash
Setting up the your local development environment
-------------------------------------------------
git checkout my_shiny_feature
You will need to create a virtual environment and install the project requirements within it.
Then, edit your code, and test it appropriately (see
:ref:`quality_contributions` below), and push it again to your GitHub
fork, like the first time (except the ``-u`` option is only needed the
first time):
The recommended approach is to install `conda <https://conda.io/projects/conda/en/latest/user-guide/install/index.html>`_ and
create a virtual environment in the project directory with the following:
.. code-block:: bash
git push origin my_shiny_feature
conda env create -n aesara-dev -f environment.yaml
conda activate aesara-dev
The pull request to the central repository will then be automatically
updated by GitHub. However, the reviewers will not be automatically
notified of your revision, so it is advised to reply to the comments on
GitHub, to let them know that you have submitted a fix.
More Advanced Git Usage
=======================
You can find information and tips in the `numpy development
<http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html>`_
page. Here are a few.
Cleaning up branches
--------------------
When your pull request has been merged, you can delete the branch from
your GitHub fork's list of branches. This is useful to avoid having too
many branches staying there. Deleting this remote branch is achieved
with:
Afterward, you can install the development dependencies with the following:
.. code-block:: bash
git push origin :my_shiny_feature
This lines pushes to the "origin" repository (your fork of Aesara on
GitHub), into the branch "my_shiny_feature", an empty content (that's
why there is nothing before the colon), effectively removing it.
pip install -r requirements.txt
The branch will still be present in your local clone of the repository.
If you want to delete it from there, too, you can run:
Next, ``pre-commit`` needs to be configured so that the linting and code quality
checks are performed before each commit:
.. code-block:: bash
git branch -d my_shiny_feature
pre-commit install
Amending a submitted pull request
---------------------------------
The virtual environment will need to be activated in any environment
(e.g. shells, IDEs, etc.) that plans to run the Aesara tests or add commits to the
project repository.
If you want to fix a commit already submitted within a pull request
(e.g. to fix a small typo), before the pull request is accepted, you can
do it like this to keep history clean:
.. code-block:: bash
git checkout my_shiny_feature
git commit --amend
git push origin my_shiny_feature:my_shiny_feature
Do not abuse that command, and please use it only when there are only
small issues to be taken care of. Otherwise, it becomes difficult to
match the comments made by reviewers with the new modifications.
In the general case, you should stick with the approach described above.
Cleaning up history
-------------------
Sometimes you may have commits in your feature branch that
are not needed in the final pull request. There is a `page
<http://sandofsky.com/blog/git-workflow.html>`_ that talks about
this. In summary:
* Commits to the trunk should be a lot cleaner than commits to your
feature branch; not just for ease of reviewing but also
because intermediate commits can break blame (the bisecting tool).
* `git merge --squash` will put all of the commits from your feature branch into one commit.
* There are other tools that are useful if your branch is too big for one squash.
Add another distant repository
------------------------------
To collaborate with another user on some feature he is developing, and
that is not ready for inclusion in central, the easiest way is to use a
branch of their Aesara fork (usually on GitHub).
Just like we added Aesara/Aesara as a remote repository, named
"central", you can add (on your local machine) a reference to their fork
as a new remote repository. REPO_NAME is the name you choose to name
this fork, and GIT_REPO_PATH is the URL of the fork in question.
.. code-block:: bash
git remote add REPO_NAME GIT_REPO_PATH
Then, you can create a new local branch (LOCAL_BRANCH_NAME) based on
a specific branch (REMOTE_BRANCH_NAME) from the remote repository
(REPO_NAME):
.. code-block:: bash
git checkout -b LOCAL_BRANCH_NAME REPO_NAME/REMOTE_BRANCH_NAME
For a general guide on how to provide open source contributions see `here
<https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution>`_.
For a good overview of the development workflow (e.g. relevant ``git`` commands)
see the `NumPy development guide <https://numpy.org/doc/stable/dev/>`_.
Other tools that can help you
=============================
Other tools that might help
===========================
* `cProfile <http://docs.python.org/library/profile.html>`_: time profiler that work at function level.
* `Yep <http://pypi.python.org/pypi/yep>`_: A module for profiling compiled extensions.
* `autopep8 <http://pypi.python.org/pypi/autopep8/>`_: A tool that automatically formats Python code to conform to the PEP 8 style guide.
* `line_profiler <http://pypi.python.org/pypi/line_profiler/>`_: Line-by-line profiler.
* `memory_profiler <http://fseoane.net/blog/2012/line-by-line-report-of-memory-usage/>`_: memory profiler
* `runsnake <http://www.vrplumber.com/programming/runsnakerun/>`_: Gui for cProfile(time profiler) and Meliae(memory profiler)
* `Guppy <https://pypi.python.org/pypi/guppy/>`_: Supports object and heap memory sizing, profiling and debugging.
* `hub <https://github.com/defunkt/hub>`_: A tool that adds github commands to the git command line.
* `git pull-requests <http://www.splitbrain.org/blog/2011-06/19-automate_github_pull_requests>`_: Another tool for git/github command line.
* `cProfile <http://docs.python.org/library/profile.html>`_: Time profiler that work at function level
* `line_profiler <http://pypi.python.org/pypi/line_profiler/>`_: Line-by-line profiler
* `memory_profiler <http://fseoane.net/blog/2012/line-by-line-report-of-memory-usage/>`_: A memory profiler
* `runsnake <http://www.vrplumber.com/programming/runsnakerun/>`_: GUI for cProfile (time profiler) and Meliae (memory profiler)
* `Guppy <https://pypi.python.org/pypi/guppy/>`_: Supports object and heap memory sizing, profiling, and debugging
* `hub <https://github.com/defunkt/hub>`_: A tool that adds GitHub commands to the git command line
* `git pull-requests <http://www.splitbrain.org/blog/2011-06/19-automate_github_pull_requests>`_: Another command line tool for ``git``/GitHub
doc/extending/extending_aesara.rst
浏览文件 @ eedc5e88
......@@ -853,7 +853,6 @@ The section :ref:`Other Ops <other_ops>` includes more instructions for
the following specific cases:
- :ref:`scalar_ops`
- :ref:`scipy_ops`
- :ref:`sparse_ops`
- :ref:`Random ops <random_ops>`
- :ref:`openmp_ops`
......
doc/extending/scan.rst
浏览文件 @ eedc5e88
......@@ -143,16 +143,16 @@ through time for these variables.
To synthesize :
=========================================================== ===================================================== ========================================================== =========================================================== ========================================================= ======================================================
Type of `Scan` variables Corresponding outer input Corresponding inner input at timestep ``t`` (indexed from 0) Corresponding inner output at timestep ``t`` (indexed from 0) Corresponding outer output ``t`` Corresponding argument of the `aesara.scan` function
=========================================================== ===================================================== ========================================================== =========================================================== ========================================================= ======================================================
Sequence Sequence of elements ``X`` Individual sequence element ``X[t]`` *No corresponding inner output* *No corresponding outer output* `sequences`
Non-Sequence Any variable ``X`` Variable identical to ``X`` *No corresponding inner output* *No corresponding outer output* `non_sequences`
Non-recurring output (NITSOT) *No corresponding outer input* *No corresponding inner input* Output value at timestep ``t`` Concatenation of the values of the output at all timestep `outputs_info`
=========================================================== ======================================================= ============================================================ ============================================================= ========================================================= ======================================================
Type of `Scan` variables Corresponding outer input Corresponding inner input at timestep ``t`` (indexed from 0) Corresponding inner output at timestep ``t`` (indexed from 0) Corresponding outer output ``t`` Corresponding argument of the `aesara.scan` function
=========================================================== ======================================================= ============================================================ ============================================================= ========================================================= ======================================================
Sequence Sequence of elements ``X`` Individual sequence element ``X[t]`` *No corresponding inner output* *No corresponding outer output* `sequences`
Non-Sequence Any variable ``X`` Variable identical to ``X`` *No corresponding inner output* *No corresponding outer output* `non_sequences`
Non-recurring output (NITSOT) *No corresponding outer input* *No corresponding inner input* Output value at timestep ``t`` Concatenation of the values of the output at all timestep `outputs_info`
Singly-recurrent output (SITSOT) Initial value (value at timestep ``-1``) Output value at previous timestep (``t-1``) Output value at timestep ``t`` Concatenation of the values of the output at all timestep `outputs_info`
Multiply-recurrent output (MITSOT) Initial values for the required timesteps where ``t<0`` Output value at previous required timesteps Output value at timestep ``t`` Concatenation of the values of the output at all timestep `outputs_info`
Multiply-recurrent multiple outputs (MITMOT) Initial values for the required timesteps where ``t<0`` Output value at previous required timesteps Output values for current and multiple future timesteps Concatenation of the values of the output at all timestep *No corresponding argument*
=========================================================== ===================================================== ========================================================== =========================================================== ========================================================= ======================================================
Multiply-recurrent output (MITSOT) Initial values for the required timesteps where ``t<0`` Output value at previous required timesteps Output value at timestep ``t`` Concatenation of the values of the output at all timestep `outputs_info`
Multiply-recurrent multiple outputs (MITMOT) Initial values for the required timesteps where ``t<0`` Output value at previous required timesteps Output values for current and multiple future timesteps Concatenation of the values of the output at all timestep *No corresponding argument*
=========================================================== ======================================================= ============================================================ ============================================================= ========================================================= ======================================================
.. _scan_internals_optimizations:
......
Markdown 格式
0% 或
您添加了 0 人 到此讨论。请谨慎行事。
请先完成此评论的编辑！
请 注册 或者 后发表评论