Fix single backticks for code

Author: Armavica

docs/source/api.rst

@@ -41,10 +41,10 @@ Plots, stats and diagnostics are delegated to the
 library, a general purpose library for
 "exploratory analysis of Bayesian models".
 
-* Functions from the `arviz.plots` module are available through ``pymc.<function>`` or ``pymc.plots.<function>``,
+* Functions from the ``arviz.plots`` module are available through ``pymc.<function>`` or ``pymc.plots.<function>``,
   but for their API documentation please refer to the :ref:`ArviZ documentation <arviz:plot_api>`.
 
-* Functions from the `arviz.stats` module are available through ``pymc.<function>`` or ``pymc.stats.<function>``,
+* Functions from the ``arviz.stats`` module are available through ``pymc.<function>`` or ``pymc.stats.<function>``,
   but for their API documentation please refer to the :ref:`ArviZ documentation <arviz:stats_api>`.
 
 ArviZ is a dependency of PyMC and so, in addition to the locations described above,

docs/source/api/distributions/discrete.rst

@@ -23,4 +23,4 @@ Discrete
 .. note::
 
    **OrderedLogistic and OrderedProbit:**
-   The `OrderedLogistic` and `OrderedProbit` distributions expect the observed values to be 0-based, i.e., they should range from `0` to `K-1`. Using 1-based indexing (like `1, 2, 3,...K`) can result in errors.
+   The ``OrderedLogistic`` and ``OrderedProbit`` distributions expect the observed values to be 0-based, i.e., they should range from ``0`` to ``K-1``. Using 1-based indexing (like ``1, 2, 3,...K``) can result in errors.

docs/source/api/shape_utils.rst

@@ -4,9 +4,9 @@ shape_utils
 
 This submodule contains various functions that apply numpy's broadcasting rules to shape tuples, and also to samples drawn from probability distributions.
 
-The main challenge when broadcasting samples drawn from a generative model, is that each random variate has a core shape. When we draw many i.i.d samples from a given RV, for example if we ask for `size_tuple` i.i.d draws, the result usually is a `size_tuple + RV_core_shape`. In the generative model's hierarchy, the downstream RVs that are conditionally dependent on our above sampled values, will get an array with a shape that is inconsistent with the core shape they expect to see for their parameters. This is a problem sometimes because it prevents regular broadcasting in complex hierarchical models, and thus make prior and posterior predictive sampling difficult.
+The main challenge when broadcasting samples drawn from a generative model, is that each random variate has a core shape. When we draw many i.i.d samples from a given RV, for example if we ask for ``size_tuple`` i.i.d draws, the result usually is a ``size_tuple + RV_core_shape``. In the generative model's hierarchy, the downstream RVs that are conditionally dependent on our above sampled values, will get an array with a shape that is inconsistent with the core shape they expect to see for their parameters. This is a problem sometimes because it prevents regular broadcasting in complex hierarchical models, and thus make prior and posterior predictive sampling difficult.
 
-This module introduces functions that are made aware of the requested `size_tuple` of i.i.d samples, and does the broadcasting on the core shapes, transparently ignoring or moving the i.i.d `size_tuple` prepended axes around.
+This module introduces functions that are made aware of the requested ``size_tuple`` of i.i.d samples, and does the broadcasting on the core shapes, transparently ignoring or moving the i.i.d ``size_tuple`` prepended axes around.
 
 .. currentmodule:: pymc.distributions.shape_utils
 

docs/source/guides/Gaussian_Processes.rst

@@ -126,7 +126,7 @@ variable models and also some fast approximations.  Their usage all follows a
 similar pattern:  First, a GP is instantiated with a mean function and a
 covariance function.  Then, GP objects can be added together, allowing for
 function characteristics to be carefully modeled and separated.  Finally, one
-of `prior`, `marginal_likelihood` or `conditional` methods is called on the GP
+of ``prior``, ``marginal_likelihood`` or ``conditional`` methods is called on the GP
 object to actually construct the PyMC random variable that represents the
 function prior.
 
@@ -148,7 +148,7 @@ conditioned on.
   or other, depending on the implementation.  See the notebooks for examples.
   The :code:`conditional` method works similarly.
 
-Calling the `prior` method will create a PyMC random variable that represents
+Calling the ``prior`` method will create a PyMC random variable that represents
 the latent function :math:`f(x) = \mathbf{f}`::
 
     f = gp.prior("f", X)
@@ -218,7 +218,7 @@ thesis <https://www.cs.toronto.edu/~duvenaud/thesis.pdf>`_.
 
 The GP objects in PyMC keeps track of these marginals automatically.  The
 following code sketch shows how to define the conditional distribution of
-:math:`f_2^*`.  We use `gp.Marginal` in the example, but the same works for
+:math:`f_2^*`.  We use ``gp.Marginal`` in the example, but the same works for
 other implementations.  The first block fits the GP prior.  We denote
 :math:`f_1 + f_2` as just :math:`f` for brevity::
 
@@ -255,7 +255,7 @@ arguments are required for conditionals of :math:`f1` and :math:`f2`, but not
 
 .. note::
   When constructing conditionals, the additional arguments :code:`X`, :code:`y`,
-  :code:`noise` and :code:`gp` must be provided as a dict called `given`!
+  :code:`noise` and :code:`gp` must be provided as a dict called ``given``!
 
 Since the marginal likelihoood method of :code:`gp1` or :code:`gp2` weren't called,
 their conditionals need to be provided with the required inputs.  In the same

docs/source/learn/core_notebooks/Gaussian_Processes.rst

@@ -123,8 +123,8 @@ variable models and also some fast approximations.  Their usage all follows a
 similar pattern:  First, a GP is instantiated with a mean function and a
 covariance function.  Then, GP objects can be added together, allowing for
 function characteristics to be carefully modeled and separated.  Finally, one
-of `prior`, `marginal_likelihood` or `conditional` methods is called on the GP
-object to actually construct the PyMC random variable that represents the
+of ``prior``, ``marginal_likelihood`` or ``conditional`` methods is called on
+the GP object to actually construct the PyMC random variable that represents the
 function prior.
 
 Using :code:`gp.Latent` for the example, the syntax to first specify the GP
@@ -145,7 +145,7 @@ conditioned on.
   or other, depending on the implementation.  See the notebooks for examples.
   The :code:`conditional` method works similarly.
 
-Calling the `prior` method will create a PyMC random variable that represents
+Calling the ``prior`` method will create a PyMC random variable that represents
 the latent function :math:`f(x) = \mathbf{f}`::
 
     f = gp.prior("f", X)
@@ -217,7 +217,7 @@ thesis <https://www.cs.toronto.edu/~duvenaud/thesis.pdf>`_.
 
 The GP objects in PyMC keeps track of these marginals automatically.  The
 following code sketch shows how to define the conditional distribution of
-:math:`f_2^*`.  We use `gp.Marginal` in the example, but the same works for
+:math:`f_2^*`.  We use ``gp.Marginal`` in the example, but the same works for
 other implementations.  The first block fits the GP prior.  We denote
 :math:`f_1 + f_2` as just :math:`f` for brevity::
 
@@ -254,7 +254,7 @@ arguments are required for conditionals of :math:`f1` and :math:`f2`, but not
 
 .. note::
   When constructing conditionals, the additional arguments :code:`X`, :code:`y`,
-  :code:`sigma` and :code:`gp` must be provided as a dict called `given`!
+  :code:`sigma` and :code:`gp` must be provided as a dict called ``given``!
 
 Since the marginal likelihoood method of :code:`gp1` or :code:`gp2` weren't called,
 their conditionals need to be provided with the required inputs.  In the same