Fix typos in docs

CONTRIBUTING.md

@@ -3,7 +3,7 @@ https://aesara.readthedocs.io/en/latest/dev_start_guide.html
 
 
 ## Migrating PRs from the original Theano Repo
-Aesara is actively merging new changes. If you have a pull request on the original Theano respository and would like to move it here use the following commands in your local Aesara repository:
+Aesara is actively merging new changes. If you have a pull request on the original Theano repository and would like to move it here use the following commands in your local Aesara repository:
 
 ```
 # Go to your Aesara repo

doc/extending/cop.rst

@@ -235,7 +235,7 @@ There are less methods to define for a `COp` than for a `Type`:
        this undefined.
 
        This attribute is internal and may go away at any point during
-       developpment if a better solution is found.
+       development if a better solution is found.
 
 The ``name`` argument is currently given an invalid value, so steer
 away from it. As was the case with `Type`, ``sub['fail']`` provides

doc/extending/ctype.rst

@@ -137,7 +137,7 @@ prefix. The complete list can be found in the documentation for
        for a matrix of 32-bit signed NumPy integers, it should return
        ``"npy_int32"``. If C type may change from an instance to another
        (e.g. ``Scalar('int32')`` vs ``Scalar('int64')``), consider
-       implementing this method. If C type is fixed accross instances,
+       implementing this method. If C type is fixed across instances,
        this method may be useless (as you already know the C type
        when you work with the C code).
 

doc/extending/extending_aesara.rst

@@ -126,7 +126,7 @@ implementation methods, either :func:`perform`, :meth:`COp.c_code`
 or :func:`make_thunk`.
 
   :func:`make_node` method creates an Apply node representing the application
-  of the ``Op`` on the inputs provided. This method is reponsible for three things:
+  of the ``Op`` on the inputs provided. This method is responsible for three things:
 
     - it first checks that the input ``Variable``s types are compatible
       with the current ``Op``. If the ``Op`` cannot be applied on the provided
@@ -166,7 +166,7 @@ or :func:`make_thunk`.
   :func:`perform` method must be determined by the inputs. That is to say,
   when applied to identical inputs the method must return the same outputs.
 
-  :class:`Op` allows some other way to define the ``Op`` implentation.
+  :class:`Op` allows some other way to define the ``Op`` implementation.
   For instance, it is possible to define :meth:`COp.c_code` to provide a
   C-implementation to the ``Op``. Please refers to tutorial
   :ref:`extending_aesara_c` for a description of :meth:`COp.c_code` and other
@@ -223,10 +223,10 @@ There are other methods that can be optionally defined by the ``Op``:
   should return the same output when they are applied on the same inputs.
 
   The :attr:`__props__` lists the properties
-  that influence how the computation is performed (Ususally these are those
+  that influence how the computation is performed (Usually these are those
   that you set in  :func:`__init__`). It must be a tuple.
   If you don't have any properties, then you should set this attribute to the
-  emtpy tuple `()`.
+  empty tuple `()`.
 
   :attr:`__props__` enables the  automatic generation of appropriate
   :func:`__eq__` and :func:`__hash__`.
@@ -242,7 +242,7 @@ There are other methods that can be optionally defined by the ``Op``:
   The :func:`infer_shape` method allows an `Op` to infer the shape of its
   output variables without actually computing them.
   It takes as input ``fgraph``, a `FunctionGraph`; ``node``, a reference to the ``Op`` Apply node;
-  and a list of Aesara symbolic Varables (``i0_shape``, ``i1_shape``, ...)
+  and a list of Aesara symbolic Variables (``i0_shape``, ``i1_shape``, ...)
   which are the shape of the ``Op`` input ``Variable``s.
   :func:`infer_shape` returns a list where each element is a tuple representing
   the shape of one output.
@@ -586,7 +586,7 @@ We call ``utt.assert_allclose(expected_value, value)`` to compare
 NumPy ndarray.This raise an error message with more information. Also,
 the default tolerance can be changed with the Aesara flags
 ``config.tensor__cmp_sloppy`` that take values in 0, 1 and 2. The
-defaul value do the most strict comparison, 1 and 2 make less strict
+default value do the most strict comparison, 1 and 2 make less strict
 comparison.
 
 Testing the infer_shape

doc/extending/extending_aesara_c.rst

@@ -67,11 +67,11 @@ two macros most often used in Aesara C ops.
 The general principle, in the reference counting paradigm, is that the owner
 of a reference to an object is responsible for disposing properly of it.
 This can be done by decrementing the reference count once the reference is no
-longer used or by transfering ownership; passing on the reference to a new
+longer used or by transferring ownership; passing on the reference to a new
 owner which becomes responsible for it.
 
 Some functions return "borrowed references"; this means that they return a
-reference to an object **without** transfering ownership of the reference to the
+reference to an object **without** transferring ownership of the reference to the
 caller of the function. This means that if you call a function which returns a
 borrowed reference, you do not have the burden of properly disposing of that
 reference. You should **not** call Py_XDECREF() on a borrowed reference.
@@ -120,9 +120,9 @@ NumPy ndarrays
 In the NumPy C-API, NumPy arrays are represented as instances of the
 PyArrayObject class which is a descendant of the PyObject class. This means
 that, as for any other Python object that you manipulate from C code, you
-need to appropriatedly manage the reference counts of PyArrayObject instances.
+need to appropriately manage the reference counts of PyArrayObject instances.
 
-Unlike in a standard multidimensionnal C array, a NumPy array's internal data
+Unlike in a standard multidimensional C array, a NumPy array's internal data
 representation does not have to occupy a continuous region in memory. In fact,
 it can be C-contiguous, F-contiguous or non-contiguous. C-contiguous means
 that the data is not only contiguous in memory but also that it is organized
@@ -347,7 +347,7 @@ commonly used.
     to raise a ValueError Python exception with the specified message.
     The function ``PyErr_Format()`` supports string formatting so it is
     possible to tailor the error message to the specifics of the error
-    that occured. If ``PyErr_Format()`` is called with more than two
+    that occurred. If ``PyErr_Format()`` is called with more than two
     arguments, the subsequent arguments are used to format the error message
     with the same behavior as the function `PyString_FromFormat()
     <https://docs.python.org/2/c-api/string.html#c.PyString_FromFormat>`_. The
@@ -579,7 +579,7 @@ method must be valid in every setting your op supports. If the op is meant
 to supports inputs of various dtypes, the C code in this method should be
 generic enough to work with every supported dtype. If the op operates on
 inputs that can be vectors or matrices, the C code in this method should
-be able to accomodate both kinds of inputs.
+be able to accommodate both kinds of inputs.
 
 In our example, the method ``c_support_code`` is used to declare a C
 function to validate that two vectors have the same shape. Because our
@@ -891,10 +891,10 @@ If you pass a function name to the ``__init__()`` method of the
 
 *       It must receive one argument for each input to the `Op` followed
         by one pointer to an argument for each output of the `Op`.  The
-        types for the argument is dependant on the Types (that is
+        types for the argument is dependent on the Types (that is
         aesara Types) of your inputs and outputs.
 
-*       You can sepcify the number of inputs and outputs for your `Op`
+*       You can specify the number of inputs and outputs for your `Op`
         by setting the ``_cop_num_inputs`` and ``_cop_num_outputs``
         attributes on your `COp`.  The main function will always be
         called with that number of arguments, using NULL to fill in
@@ -924,7 +924,7 @@ discussed below.
 *      ``APPLY_SPECIFIC(str)`` which will automatically append a name
        unique to the :ref:`Apply` node that applies the `Op` at the end
        of the provided ``str``. The use of this macro is discussed
-       futher below.
+       further below.
 
 For every input which has a :attr:`dtype` attribute (this means
 Tensors, and equivalent types on GPU), the following macros will be
@@ -1012,7 +1012,7 @@ sometimes tricky.  The key thing to remember is that things that can
 be shared between instances of the `Op` should be apply-agnostic and go
 into a section which does not end in ``_apply`` or ``_struct``.  The
 distinction of ``_apply`` and ``_struct`` mostly hinghes on how you
-want to manange the lifetime of the object.  Note that to use an
+want to manage the lifetime of the object.  Note that to use an
 apply-specific object, you have to be in a apply-specific section, so
 some portions of the code that might seem apply-agnostic may still be
 apply-specific because of the data they use (this does not include

doc/extending/inplace.rst

@@ -129,7 +129,7 @@ operation on ``x``.
    it does allow *optimizations* to substitute them in in a later
    phase. Therefore, typically, if you define an inplace operation,
    you will define a pure equivalent and an optimization which
-   subsitutes one for the other. Aesara will automatically verify if
+   substitutes one for the other. Aesara will automatically verify if
    it is possible to do so and will refuse the substitution if it
    introduces inconsistencies.
 

doc/extending/jax_op.rst

@@ -79,7 +79,7 @@ the ``test_jax.py`` test suite. The test should ensure that Aesara Op,
 when included as part of a function graph, passes the tests in
 ``compare_jax_and_py`` test method. What this test method does is
 compile the same function graph in Python and JAX and check that the
-numerical output is similar betwen the JAX and Python output, as well
+numerical output is similar between the JAX and Python output, as well
 object types to ensure correct compilation.
 
 https://github.com/pymc-devs/aesara/blob/main/tests/link/test_jax.py
@@ -148,7 +148,7 @@ https://docs.python.org/3/library/functools.html#functools.singledispatch
 
     Mooooo
     Woof
-    Animal has not been registerd
+    Animal has not been registered
 
 
 This is what allows the JAX Linker to determine which the correct

doc/extending/op.rst

@@ -252,7 +252,7 @@ Optional methods or attributes
    .. note::
 
      If you set `__props__`, this will be automatically generated.
-     You can still overide it for custom output.
+     You can still override it for custom output.
 
 .. function:: do_constant_folding(fgraph, node)
 
@@ -537,7 +537,7 @@ These are the function required to work with gradient.grad().
    Same conventions as for the grad method hold. If your op is not
    differentiable, you can return None. Note that in contrast to
    the method :func:`grad`, for :func:`R_op` you need to return the
-   same number of outputs as there are ouputs of the op. You can think
+   same number of outputs as there are outputs of the op. You can think
    of it in the following terms. You have all your inputs concatenated
    into a single vector :math:`x`. You do the same with the evaluation
    points (which are as many as inputs and of the shame shape) and obtain

doc/extending/optimization.rst

@@ -230,7 +230,7 @@ places. Note that ``add(x, y)`` and ``add(y, x)`` are still considered
 to be different because Aesara has no clue that ``add`` is
 commutative. You may write your own global optimizer to identify
 computations that are identical with full knowledge of the rules of
-arithmetics that your Ops implement. Aesara might provide facilities
+arithmetic that your Ops implement. Aesara might provide facilities
 for this somewhere in the future.
 
 .. note::
@@ -278,7 +278,7 @@ The definition of transform is the inner loop of the global optimizer,
 where the node is given as argument. If no changes are to be made,
 ``False`` must be returned. Else, a list of what to replace the node's
 outputs with must be returned. This list must have the same length as
-node.ouputs. If one of node.outputs don't have clients(it is not used
+node.outputs. If one of node.outputs don't have clients(it is not used
 in the graph), you can put None in the returned list to remove it.
 
 In order to apply the local optimizer we must use it in conjunction

doc/extending/scan.rst

@@ -185,7 +185,7 @@ PushOutSeqScan
 
 This optimization resembles PushOutNonSeqScan but it tries to push, out of
 the inner function, the computation that only relies on sequence and
-non-sequence inputs. The idea behing this optimization is that, when it is
+non-sequence inputs. The idea behind this optimization is that, when it is
 possible to do so, it is generally more computationally efficient to perform
 a single operation on a large tensor rather then perform that same operation
 many times on many smaller tensors. In many cases, this optimization can
@@ -266,7 +266,7 @@ Helper classes and functions
 ============================
 
 Because of the complexity involved in dealing with Scan, a large number of
-helper classes and functions have been developped over time to implement
+helper classes and functions have been developed over time to implement
 operations commonly needed when dealing with the scan op. The scan op
 itself defines a large number of them and others can be found in the file
 ``utils.py``. This sections aims to point out the most useful ones sorted
@@ -301,7 +301,7 @@ sequence input, going from an inner output associated with a recurrent state
 to the inner input(s) associated with that same recurrent state, etc.), then
 the ``var_mappings`` attribute of the scan op can be used.
 
-This attribute is a dictionnary with 12 {key/value} pairs. The keys are listed
+This attribute is a dictionary with 12 {key/value} pairs. The keys are listed
 below :
 
 *   "outer_inp_from_outer_out"

doc/extending/type.rst

@@ -180,7 +180,7 @@ but will allow people to use you type with familiar interfaces.
 To plug in additional options for the transfer target, define a
 function which takes an Aesara variable and a target argument and
 returns eitehr a new transferred variable (which can be the same as
-the input if no transfer is nessecary) or returns None if the transfer
+the input if no transfer is necessary) or returns None if the transfer
 can't be done.
 
 Then register that function by calling :func:`register_transfer()`

doc/extending/using_params.rst

@@ -53,7 +53,7 @@ following methods will be used for the type:
   - :meth:`__hash__ <Type.__hash__>`
   - :meth:`values_eq <Type.values_eq>`
 
-Additionaly if you want to use your params with C code, you need to extend `COp`
+Additionally if you want to use your params with C code, you need to extend `COp`
 and implement the following methods:
 
   - :meth:`c_declare <CLinkerType.c_declare>`
@@ -123,7 +123,7 @@ extra parameter at the end which corresponds to the params object.
 
 Also, for the C code, the `sub` dictionary will contain an extra entry
 `'params'` which will map to the variable name of the params object.
-This is true for all methods that recieve a `sub` parameter, so this
+This is true for all methods that receive a `sub` parameter, so this
 means that you can use your params in the :meth:`c_code <COp.c_code>`
 and :meth:`c_init_code_struct <COp.c_init_code_struct>` method.
 

doc/faq.rst

@@ -111,7 +111,7 @@ valid. What this means is that if the user provides invalid values (like
 incompatible shapes or indexing values that are out of bounds) and
 the optimizations are applied, the user error will get lost. Most of the
 time, the assumption is that the user inputs are valid. So it is good
-to have the optimization being applied, but loosing the error is bad.
+to have the optimization being applied, but losing the error is bad.
 The newest optimization in Aesara with such assumption will add an
 assertion in the graph to keep the user error message. Computing
 these assertions could take some time. If you are sure everything is valid

doc/library/d3viz/examples/d3viz/js/d3viz.js

@@ -609,7 +609,7 @@ function drawGraph() {
 		.on('tick', updateGraph)
 		.start();
 		
-	// Drag behavour
+	// Drag behaviour
 	var drag = forceLayout.drag()
 		.on('dragstart', function(d) {
 			d3.event.sourceEvent.stopPropagation();
@@ -757,7 +757,7 @@ function profileColor(per) {
 
 
 /*
- * Retuns node fill color.
+ * Returns node fill color.
  */
 function nodeFillColor(d) {
 	if (useProfileColors) {

doc/library/tensor/nnet/ctc.rst

@@ -14,7 +14,7 @@
 
 .. note::
 
-   This interface is the prefered interface. It will be moved
+   This interface is the preferred interface. It will be moved
    automatically to the GPU.
 
 .. note::

doc/pylintrc

 # lint Python modules using external checkers.
-# 
+#
 # This is the main checker controlling the other ones and the reports
 # generation. It is itself both a raw checker and an astng checker in order
 # to:
 # * handle message activation / deactivation at the module level
 # * handle some basic but necessary stats'data (number of classes, methods...)
-# 
+#
 [MASTER]
 
 # Specify a configuration file.
@@ -70,12 +70,12 @@ include-ids=no
 # written in a file name "pylint_global.[txt|html]".
 files-output=yes
 
-# Tells wether to display a full report or only the messages
+# Tells whether to display a full report or only the messages
 reports=yes
 
 # Python expression which should return a note less than 10 (10 is the highest
 # note). You have access to the variables errors warning, statement which
-# respectivly contain the number of errors / warnings messages and the total
+# respectively contain the number of errors / warnings messages and the total
 # number of statements analyzed. This is used by the global evaluation report
 # (R0004).
 evaluation=10.0 - ((float(5 * error + warning + refactor + convention) / statement) * 10)
@@ -92,15 +92,15 @@ comment=no
 
 
 # try to find bugs in the code using type inference
-# 
+#
 [TYPECHECK]
 
-# Tells wether missing members accessed in mixin class should be ignored. A
+# Tells whether missing members accessed in mixin class should be ignored. A
 # mixin class is detected if its name ends with "mixin" (case insensitive).
 ignore-mixin-members=yes
 
 # List of classes names for which member attributes should not be checked
-# (useful for classes with attributes dynamicaly set).
+# (useful for classes with attributes dynamically set).
 ignored-classes=SQLObject
 
 # When zope mode is activated, add a predefined set of Zope acquired attributes
@@ -116,11 +116,11 @@ generated-members=REQUEST,acl_users,aq_parent
 # * unused variables / imports
 # * undefined variables
 # * redefinition of variable from builtins or from an outer scope
-# * use of variable before assigment
-# 
+# * use of variable before assignment
+#
 [VARIABLES]
 
-# Tells wether we should check for unused import in __init__ files.
+# Tells whether we should check for unused import in __init__ files.
 init-import=no
 
 # A regular expression matching names used for dummy variables (i.e. not used).
@@ -134,13 +134,13 @@ additional-builtins=
 # checks for :
 # * doc strings
 # * modules / classes / functions / methods / arguments / variables name
-# * number of arguments, local variables, branchs, returns and statements in
+# * number of arguments, local variables, branches, returns and statements in
 # functions, methods
 # * required module attributes
 # * dangerous default values as arguments
 # * redefinition of function / method / class
 # * uses of the global statement
-# 
+#
 [BASIC]
 
 # Required attributes for module, separated by a comma
@@ -191,7 +191,7 @@ bad-functions=map,filter,apply,input
 # checks for sign of poor/misdesign:
 # * number of methods, attributes, local variables...
 # * size, complexity of functions, methods
-# 
+#
 [DESIGN]
 
 # Maximum number of arguments for function / method
@@ -225,11 +225,11 @@ max-public-methods=20
 # checks for :
 # * methods without self as first argument
 # * overridden methods signature
-# * access only to existant members via self
+# * access only to existent members via self
 # * attributes not defined in the __init__ method
 # * supported interfaces implementation
 # * unreachable code
-# 
+#
 [CLASSES]
 
 # List of interface methods to ignore, separated by a comma. This is used for
@@ -245,7 +245,7 @@ defining-attr-methods=__init__,__new__,setUp
 # * relative / wildcard imports
 # * cyclic imports
 # * uses of deprecated modules
-# 
+#
 [IMPORTS]
 
 # Deprecated modules which should not be used, separated by a comma
@@ -269,7 +269,7 @@ int-import-graph=
 # * strict indentation
 # * line length
 # * use of <> instead of !=
-# 
+#
 [FORMAT]
 
 # Maximum number of characters on a single line.
@@ -287,7 +287,7 @@ indent-string='    '
 # checks for similarities and duplicated code. This computation may be
 # memory / CPU intensive, so you should disable it if you experiments some
 # problems.
-# 
+#
 [SIMILARITIES]
 
 # Minimum lines number of a similarity.
@@ -303,7 +303,7 @@ ignore-docstrings=yes
 # checks for:
 # * warning notes in the code like FIXME, XXX
 # * PEP 263: source code with non ascii character but no encoding declaration
-# 
+#
 [MISCELLANEOUS]
 
 # List of note tags to take in consideration, separated by a comma.

doc/sandbox/how_to_make_ops.rst

@@ -243,7 +243,7 @@ Hidden outputs (as a form of op state)
 
 For performance purposes, an ``op`` might want to have a hidden internal state.
 
-Example: if we expect to call the op repeatedly on incrementally bigger inputs, we might want private output storage that's a lot bigger than needed and take incrementally bigger views on it, to save allocation overhead. In order to do this, we can have two outputs: one that we will return normally and will contain the answer and the other that will be the (larger) container. In this case, the advanced note in the 'reusing outputs' section applies. Furthermore, ``__call__`` should be overriden to only return the first output instead of both of them. Here is what the example's ``perform`` and ``__call__`` would look like:
+Example: if we expect to call the op repeatedly on incrementally bigger inputs, we might want private output storage that's a lot bigger than needed and take incrementally bigger views on it, to save allocation overhead. In order to do this, we can have two outputs: one that we will return normally and will contain the answer and the other that will be the (larger) container. In this case, the advanced note in the 'reusing outputs' section applies. Furthermore, ``__call__`` should be overridden to only return the first output instead of both of them. Here is what the example's ``perform`` and ``__call__`` would look like:
 
 .. code-block:: python
 

doc/tutorial/debug_faq.rst

@@ -43,7 +43,7 @@ Running the code above we see:
 
    Traceback (most recent call last):
      ...
-   ValueError: Input dimension mis-match. (input[0].shape[0] = 3, input[1].shape[0] = 2)
+   ValueError: Input dimension mismatch. (input[0].shape[0] = 3, input[1].shape[0] = 2)
    Apply node that caused the error: Elemwise{add,no_inplace}(<TensorType(float64, vector)>, <TensorType(float64, vector)>, <TensorType(float64, vector)>)
    Inputs types: [TensorType(float64, vector), TensorType(float64, vector), TensorType(float64, vector)]
    Inputs shapes: [(3,), (2,), (2,)]
@@ -55,7 +55,7 @@ Running the code above we see:
 
 Arguably the most useful information is approximately half-way through
 the error message, where the kind of error is displayed along with its
-cause (`ValueError: Input dimension mis-match. (input[0].shape[0] = 3,
+cause (`ValueError: Input dimension mismatch. (input[0].shape[0] = 3,
 input[1].shape[0] = 2`).
 Below it, some other information is given, such as the apply node that
 caused the error, as well as the input types, shapes, strides and
@@ -504,7 +504,7 @@ Consider this example script ("ex.py"):
 
    Traceback (most recent call last):
      ...
-   ValueError: Input dimension mis-match. (input[0].shape[0] = 3, input[1].shape[0] = 5)
+   ValueError: Input dimension mismatch. (input[0].shape[0] = 3, input[1].shape[0] = 5)
    Apply node that caused the error: Elemwise{mul,no_inplace}(a, b)
    Toposort index: 0
    Inputs types: [TensorType(float64, matrix), TensorType(float64, matrix)]
@@ -530,7 +530,7 @@ illustrative purposes. As the matrices can't be multiplied element-wise
     File "/u/username/Aesara/aesara/compile/function/types.py", line 451, in __call__
     File "/u/username/Aesara/aesara/graph/link.py", line 271, in streamline_default_f
     File "/u/username/Aesara/aesara/graph/link.py", line 267, in streamline_default_f
-    File "/u/username/Aesara/aesara/graph/cc.py", line 1049, in execute ValueError: ('Input dimension mis-match. (input[0].shape[0] = 3, input[1].shape[0] = 5)', Elemwise{mul,no_inplace}(a, b), Elemwise{mul,no_inplace}(a, b))
+    File "/u/username/Aesara/aesara/graph/cc.py", line 1049, in execute ValueError: ('Input dimension mismatch. (input[0].shape[0] = 3, input[1].shape[0] = 5)', Elemwise{mul,no_inplace}(a, b), Elemwise{mul,no_inplace}(a, b))
 
 The call stack contains some useful information to trace back the source
 of the error. There's the script where the compiled function was called --

doc/tutorial/nan_tutorial.rst

@@ -76,7 +76,7 @@ and find out if everything is derived correctly.
 CUDA Specific Option
 --------------------
 
-The Aesara flag ``nvcc.fastmath=True`` can genarate NaN. Don't set
+The Aesara flag ``nvcc.fastmath=True`` can generate NaN. Don't set
 this flag while debugging NaN.