Aesara is a Python library that allows one to define, optimize, and efficiently evaluate mathematical expressions involving multi-dimensional arrays.

Mentioned in #267

Here are a few important guidelines and requirements to check before your PR can be merged:

• [x] There is an informative high-level description of the changes.
• [x] The description and/or commit message(s) references the relevant GitHub issue(s).
• [x] pre-commit is installed and set up.
• [x] The commit messages follow these guidelines.
• [x] The commits correspond to relevant logical 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.
• [x] 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 of your feature/PR branches.

If your PR is an ongoing effort and you would like to involve us in the process, simply make it a draft PR.

Closes #224

I am not sure if it's as simple as this... Still researching a bit. I haven't found a single C example that explicitly returns NAN, so I might be doing something wrong. The code works on my machine though.

Here are a few important guidelines and requirements to check before your PR can be merged:

• [x] There is an informative high-level description of the changes.
• [x] The description and/or commit message(s) references the relevant GitHub issue(s).
• [x] pre-commit is installed and set up.
• [x] The commit messages follow these guidelines.
• [ ] The commits correspond to relevant logical 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.
• [x] There are tests covering the changes introduced in the PR.

Following our discussions in #1015 and #1011, this PR adds Ops to aesara.tensor.slinalg that wrap scipy.linalg.solve_discrete_lyapunov and scipy.linalg.solve_continuous_lyapunov, as well as compute the reverse-mode gradients for each.

One note, I had an error from mypy when running the pre-commit hooks: aesara\link\c\cmodule.py:2439: error: Unused "type: ignore" comment

But this is unrelated to any changes i made, so I didn't know what to do with it.

Here's an old example of a Numba-enabled Theano Op. We can most likely do something similar for Cython and JAX, as well.

As an extension to that example, it would be nice to have the compiled function be the Op.perform method itself; that way, we could attempt to compile existing Ops with little-to-no changes.

In this PR we begin phasing the nnet and signal modules outside of Aesara, following discussion in https://github.com/aesara-devs/aesara/issues/674.

• [x] Disable auto-importing from aesara.tensor
• [x] Remove aesara.tensor.nnet and aesara.tensor.signal tests
• [x] Add deprecation warnings in nnet module
• [x] Add deprecation warnings in signal module
• [x] Move Softmax out of aesara.tensor.nnet.basic -> aesara.tensor.math
• [x] Move LogSoftmax out of aesara.tensor.nnet.basic -> aesara.tensor.math
• [x] Move SoftmaxGrad out of aesara.tensor.nnet -> aesara.tensor.math
• [x] Move tests for Softmax, LogSoftmax, SoftmaxGrad
• [x] Move rewrites related to Softmax, LogSoftmax, SoftmaxGrad
• [x] Rename logsoftmax -> log_softmax
• [x] Remove nnet and signal from the documentation, and any mention of anything NN-related

Anything else we want to salvage ?

Closes https://github.com/conda-forge/aesara-feedstock/issues/54 by capturing stderr while reading blas_info from Numpy.

Specifically, the suppressed errors appear on Windows and look like

>>> import aesara
WARN: Could not locate executable g77
WARN: Could not locate executable f77
WARN: Could not locate executable ifort
WARN: Could not locate executable ifl
WARN: Could not locate executable f90
WARN: Could not locate executable DF
WARN: Could not locate executable efl

I am having trouble running the pytest suite locally. Additionally, I have no means of testing this locally since I don't have Windows.

I have not yet written any tests, but I'm open to advice.

I did this a bit rushed, so apologies in advance in case I missed some guideline.

Thank you for opening a PR!

Here are a few important guidelines and requirements to check before your PR can be merged:

• [X] There is an informative high-level description of the changes.
• [X] The description and/or commit message(s) references the relevant GitHub issue(s).
• [X] pre-commit is installed and set up.
• [X] The commit messages follow these guidelines.
• [X] The commits correspond to relevant logical changes, and there are no commits that fix changes introduced by other commits in the same branch/BR.
• [x] 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 of your feature/PR branches.

If your PR is an ongoing effort and you would like to involve us in the process, simply make it a draft PR.

Description

This simple model never diverges in NUTS:

import numpy as np
import pymc3 as pm

with pm.Model() as good_model:
    good_beta = pm.Beta('good_beta', alpha=0.25, beta=3.0, shape=40)

with good_model:
    good_trace = pm.sample(draws=600, chains=2, tune=500) 

But this very similar model---with alpha and beta swapped---diverges on about half the samples:

import numpy as np
import pymc3 as pm

with pm.Model() as bad_model:
    bad_beta = pm.Beta('bad_beta', alpha=3.0, beta=0.25, shape=40)

with bad_model:
    bad_trace = pm.sample(draws=600, chains=2, tune=500)

Sampling 2 chains for 500 tune and 600 draw iterations (1_000 + 1_200 draws total) took 17 seconds.
There were 328 divergences after tuning. Increase `target_accept` or reparameterize.
There were 282 divergences after tuning. Increase `target_accept` or reparameterize.
The acceptance probability does not match the target. It is 0.8848443240050202, but should be close to 0.8. Try to increase the number of tuning steps.
The estimated number of effective samples is smaller than 200 for some parameters.

The problem appears to be that in the diverging samples, one element of bad_beta jumps to a logodds that is close to (but less than) the value 19.0

def max_bad_beta(warning):
    return np.amax(warning.extra['bad_beta_logodds__'])

def logodds_and_beta(value):
    return value, pm.transforms.logodds.backward(value).eval()[()]

def maxs_from_warnings(trace, limit=50):
    warnings = trace.report._warnings[:limit]
    return [logodds_and_beta(max_bad_beta(warning)) for warning in warnings]

maxs_from_warnings(bad_trace)
[(18.522285926243683, 0.9999999909661387),
 (18.026951801202443, 0.9999999851750137),
 (18.273787751452954, 0.9999999884176999),
 (15.811521213093858, 0.9999998641237577),
 (18.788894703456123, 0.999999993080309),
 (17.840933189508505, 0.9999999821441242),
 (18.99068873589819, 0.9999999943447908),
 (18.650396555754487, 0.9999999920524058),
 (18.886465782831156, 0.9999999937235782),
 (18.614120566380194, 0.9999999917588059),
 (18.748619470023584, 0.9999999927959284),
 (18.96328594127111, 0.9999999941876794),
 (18.43516905323891, 0.9999999901438387),
 (18.7824011307429, 0.9999999930352292),
 (18.61426914065103, 0.9999999917600301),
 (18.61426914065103, 0.9999999917600301),
 (18.959200871340606, 0.9999999941638871),
 (18.310579256420056, 0.9999999888360865),
 (18.875771090438388, 0.9999999936560935),
 (18.419609630862556, 0.9999999899892832),
 (18.743196196992155, 0.9999999927567527), 
...
]

What is special about 19? Note that good_beta generates logodds close to -19.0 as often as bad_beta generates logodds close to 19.0, but good_beta never diverges.

Versions and main components

• PyMC3 Version: 3.9.1
• Theano Version: 1.0.4
• Python Version: 3.8.3
• Operating system: macOS 10.15.16
• How did you install PyMC3: conda

Closes #159. WIP.

Two questions:

1. Changing broadcast_like to broadcast_to in aesara/tensor/math_opt.py gives me a lot of BadOptimization and AssertionErrors, which I'm not knowledgeable enough to debug - can someone help me understand what's happening?
2. ~I've also changed broadcast_like to broadcast_to in aesara/tensor/basic_opt.py - is this something we want to do?~

I'm trying to translate Statistical Rethinking from R and RStan to Python and PyMC3.

On page 304, there's a simple logistic regression example. Data being used (publicly available):

	dept	applicant.gender	admit	reject	applications	is_male
1	A	male	512	313	825	1
2	A	female	89	19	108	0
3	B	male	353	207	560	1
4	B	female	17	8	25	0
5	C	male	120	205	325	1
6	C	female	202	391	593	0
7	D	male	138	279	417	1
8	D	female	131	244	375	0
9	E	male	53	138	191	1
10	E	female	94	299	393	0
11	F	male	22	351	373	1
12	F	female	24	317	341	0

Data is stored in a pandas DataFrame object. When I try and fit the model using:

with pm.Model() as m106:
    
    alpha = pm.Normal('alpha', 0, 10)
    beta_m = pm.Normal('beta_m', 0, 10)
    
    lin = alpha + beta_m * data['is_male']
    p = np.exp(lin) / (1 + np.exp(lin))
    
    admit = pm.Binomial('admit', n=data['applications'], p=p, observed=data['admit'])
    
    m106_map = pm.find_MAP()
    m106_traces = pm.sample(1000, start=m106_map)

I get the following error (which seems similar to pymc-devs/pymc3#918):

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/type.py in dtype_specs(self)
    266                 'complex64': (complex, 'theano_complex64', 'NPY_COMPLEX64')
--> 267             }[self.dtype]
    268         except KeyError:

KeyError: 'object'

During handling of the above exception, another exception occurred:

TypeError                                 Traceback (most recent call last)
/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/basic.py in constant_or_value(x, rtype, name, ndim, dtype)
    407             rval = rtype(
--> 408                 TensorType(dtype=x_.dtype, broadcastable=bcastable),
    409                 x_.copy(),

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/type.py in __init__(self, dtype, broadcastable, name, sparse_grad)
     49         self.broadcastable = tuple(bool(b) for b in broadcastable)
---> 50         self.dtype_specs()  # error checking is done there
     51         self.name = name

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/type.py in dtype_specs(self)
    269             raise TypeError("Unsupported dtype for %s: %s"
--> 270                             % (self.__class__.__name__, self.dtype))
    271 

TypeError: Unsupported dtype for TensorType: object

During handling of the above exception, another exception occurred:

TypeError                                 Traceback (most recent call last)
/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/basic.py in as_tensor_variable(x, name, ndim)
    201     try:
--> 202         return constant(x, name=name, ndim=ndim)
    203     except TypeError:

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/basic.py in constant(x, name, ndim, dtype)
    421     ret = constant_or_value(x, rtype=TensorConstant, name=name, ndim=ndim,
--> 422                             dtype=dtype)
    423 

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/basic.py in constant_or_value(x, rtype, name, ndim, dtype)
    416     except Exception:
--> 417         raise TypeError("Could not convert %s to TensorType" % x, type(x))
    418 

TypeError: ('Could not convert 1     Elemwise{mul,no_inplace}.0\n2     Elemwise{mul,no_inplace}.0\n3     Elemwise{mul,no_inplace}.0\n4     Elemwise{mul,no_inplace}.0\n5     Elemwise{mul,no_inplace}.0\n6     Elemwise{mul,no_inplace}.0\n7     Elemwise{mul,no_inplace}.0\n8     Elemwise{mul,no_inplace}.0\n9     Elemwise{mul,no_inplace}.0\n10    Elemwise{mul,no_inplace}.0\n11    Elemwise{mul,no_inplace}.0\n12    Elemwise{mul,no_inplace}.0\nName: applications, dtype: object to TensorType', <class 'pandas.core.series.Series'>)

During handling of the above exception, another exception occurred:

AsTensorError                             Traceback (most recent call last)
<ipython-input-144-fb615dfa2e93> in <module>()
      7     p = np.exp(lin) / (1 + np.exp(lin))
      8 
----> 9     admit = pm.Binomial('admit', n=data['applications'], p=p, observed=data['admit'])
     10 
     11     m106_map = pm.find_MAP()

/Users/horatiu/anaconda/lib/python3.5/site-packages/pymc3/distributions/distribution.py in __new__(cls, name, *args, **kwargs)
     24         if isinstance(name, string_types):
     25             data = kwargs.pop('observed', None)
---> 26             dist = cls.dist(*args, **kwargs)
     27             return model.Var(name, dist, data)
     28         elif name is None:

/Users/horatiu/anaconda/lib/python3.5/site-packages/pymc3/distributions/distribution.py in dist(cls, *args, **kwargs)
     37     def dist(cls, *args, **kwargs):
     38         dist = object.__new__(cls)
---> 39         dist.__init__(*args, **kwargs)
     40         return dist
     41 

/Users/horatiu/anaconda/lib/python3.5/site-packages/pymc3/distributions/discrete.py in __init__(self, n, p, *args, **kwargs)
     43         self.n = n
     44         self.p = p
---> 45         self.mode = tt.cast(tt.round(n * p), self.dtype)
     46 
     47     def random(self, point=None, size=None, repeat=None):

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/basic.py in round(a, mode)
   2052     """round_mode(a) with mode in [half_away_from_zero, half_to_even]"""
   2053     if mode == "half_away_from_zero":
-> 2054         return round_half_away_from_zero(a)
   2055     elif mode == "half_to_even":
   2056         return round_half_to_even(a)

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/gof/op.py in __call__(self, *inputs, **kwargs)
    609         """
    610         return_list = kwargs.pop('return_list', False)
--> 611         node = self.make_node(*inputs, **kwargs)
    612 
    613         if config.compute_test_value != 'off':

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/elemwise.py in make_node(self, *inputs)
    541         using DimShuffle.
    542         """
--> 543         inputs = list(map(as_tensor_variable, inputs))
    544         shadow = self.scalar_op.make_node(
    545             *[get_scalar_type(dtype=i.type.dtype).make_variable()

/Users/horatiu/anaconda/lib/python3.5/site-packages/theano/tensor/basic.py in as_tensor_variable(x, name, ndim)
    206         except Exception:
    207             str_x = repr(x)
--> 208         raise AsTensorError("Cannot convert %s to TensorType" % str_x, type(x))
    209 
    210 # this has a different name, because _as_tensor_variable is the

AsTensorError: ('Cannot convert 1     Elemwise{mul,no_inplace}.0\n2     Elemwise{mul,no_inplace}.0\n3     Elemwise{mul,no_inplace}.0\n4     Elemwise{mul,no_inplace}.0\n5     Elemwise{mul,no_inplace}.0\n6     Elemwise{mul,no_inplace}.0\n7     Elemwise{mul,no_inplace}.0\n8     Elemwise{mul,no_inplace}.0\n9     Elemwise{mul,no_inplace}.0\n10    Elemwise{mul,no_inplace}.0\n11    Elemwise{mul,no_inplace}.0\n12    Elemwise{mul,no_inplace}.0\nName: applications, dtype: object to TensorType', <class 'pandas.core.series.Series'>)

The error is not very informative, and doesn't seem to point to my code. But when using:

with pm.Model() as m106:
    
    alpha = pm.Normal('alpha', 0, 10)
    beta_m = pm.Normal('beta_m', 0, 10)
    
    lin = alpha + beta_m * data['is_male']
    p = np.exp(lin) / (1 + np.exp(lin))
    
    admit = pm.Binomial('admit', n=data['applications'].values, p=p, observed=data['admit'])
    
    m106_map = pm.find_MAP()
    m106_traces = pm.sample(1000, start=m106_map)

So explicitly passing in the numpy array rather than the pandas Series:

admit = pm.Binomial('admit', n=data['applications'].values, p=p, observed=data['admit'])

Everything works as expected. I'm just trying to figure out why that is? Is there a reference in the documentation for this behavior? What is the lesson I should take away from this? :)

Using pandas 0.19, numpy 1.11, pymc3.0rc2

Thank you for opening a PR!

This PR addresses this enhancement issue and adds an optional name argument when cloning a Variable

Here are a few important guidelines and requirements to check before your PR can be merged:

• [ ] There is an informative high-level description of the changes.
• [ ] The description and/or commit message(s) references the relevant GitHub issue(s).
• [ ] pre-commit is installed and set up.
• [ ] The commit messages follow these guidelines.
• [ ] The commits correspond to relevant logical 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 of your feature/PR branches.

If your PR is an ongoing effort and you would like to involve us in the process, simply make it a draft PR.

Here are a few important guidelines and requirements to check before your PR can be merged:

• [x] There is an informative high-level description of the changes.
• [x] The description and/or commit message(s) references the relevant GitHub issue(s).
• [ ] pre-commit is installed and set up.
• [x] The commit messages follow these guidelines.
• [x] The commits correspond to relevant logical changes, and there are no commits that fix changes introduced by other commits in the same branch/BR.
• [x] There are tests covering the changes introduced in the PR.

First, this PR removes the incorrect numba implementation of AdvancedIncSubtensor, so this will now just fall back to objectmode, and be slow and correct. (We should also provide a numba impl for this, but that will be a separate PR).

But we do add a new implementation for AdvancedIncSubtensor1 (the much more common case). Here, we also take advantage of the fact that sometimes we know the indices beforehand, so we can simplify bounds checks, and generate cleaner and faster assembly code.

Also a one line fix for cumop accidentally made its way into the PR, but this is simple enough that maybe we can just keep it here? (it has its own commit). The problem was that the numba.prange loop had data races.

fixes https://github.com/aesara-devs/aesara/issues/603

Consider the following probabilistic model:

import aesara.tensor as at

X_at = at.matrix('X')

srng = at.random.RandomStream(0)

tau_rv = srng.halfcauchy(0, 1)
lambda_rv = srng.halfcauchy(0, 1, size=X_at.shape[-1])
beta_rv = srng.normal(0, tau_rv * lambda_rv, size=X_at.shape[-1])

eta = X_at @ beta_rv
p = at.sigmoid(-eta)
Y_rv = srng.bernoulli(p)

In a typical bayesian modeling workflow, we want to be able to generate and use three functions:

1. A function that samples from the prior joint distribution (initialize the values)
2. A function that computes the model's logdensity
3. A function that computes posterior predictive sampling

In a workflow that uses JAX we typically want to be able to use jax.vmap with (1) and (3), and jax.grad with (2). While it is possible to do this with Aesara-compiled function, we need to go through unnecessary levels of indirections.

Current behavior

First, to use jax.grad we must use the vm.jit_fn attribute of the Aesara-compiled function and wrap the function so it returns a single value instead of a 1-element tuple:

import aesara
import aeppl
import jax
import numpy as np

logprob, vvs = aeppl.joint_logprob(tau_rv, lambda_rv, beta_rv, Y_rv)

logdensity_fn = aesara.function([X_at] + list(vvs), logprob, mode="JAX")
try:
    jax.grad(logdensity_fn)(np.ones((3,2)), 1., np.ones(2), np.ones(2), np.ones(2))
except Exception as e:
    print(e)
# Bad input argument to aesara function with name "<stdin>:22" at index 0 (0-based).
# Backtrace when that variable is created:

#   File "<stdin>", line 3, in <module>
# The numpy.ndarray conversion method __array__() was called on the JAX Tracer object Traced<ConcreteArray([[1. 1.]
#  [1. 1.]
#  [1. 1.]], dtype=float64)>with<JVPTrace(level=2/0)> with
#   primal = array([[1., 1.],
#        [1., 1.],
#        [1., 1.]])
#   tangent = Traced<ShapedArray(float64[3,2])>with<JaxprTrace(level=1/0)> with
#     pval = (ShapedArray(float64[3,2]), None)
#     recipe = LambdaBinding()
# See https://jax.readthedocs.io/en/latest/errors.html#jax.errors.TracerArrayConversionError

logdensity_jit_fn = aesara.function([X_at] + list(vvs), logprob, mode="JAX").vm.jit_fn
try:
    jax.grad(logdensity_jit_fn)(np.ones((3,2)), np.array(1.), np.ones(2), np.ones(2), np.ones(3))
except Exception as e:
    print(e)
# Gradient only defined for scalar-output functions. Output was (Array(-12.65285075, dtype=float64),).

def logdensity_squeezed_jit_fn(*x):
    return logdensity_jit_fn(*x)[0]
print(jax.grad(logdensity_squeezed_jit_fn)(np.ones((3,2)), np.array(1.), np.ones(2), np.ones(2), np.ones(3)))
# [[-0.88079708 -0.88079708]
#  [-0.88079708 -0.88079708]
#  [-0.88079708 -0.88079708]]

To be able to use jax.vmap to sample multiple values from the prior distribution / do posterior predictive sampling we must also use the jit-compiled function directly. In addition, we must pass one PRNGKey per random variable in the graph which does not reflect the RandomStream mechanism, wrap them in a dictionary with the same structure as the internal random state, and pass them as the last arguments (first argument is idiomatic in JAX):

prior_sample_fn = aesara.function([X_at], [tau_rv, lambda_rv, beta_rv], mode="JAX").vm.jit_fn
rng_key = jax.random.PRNGKey(0)
key1, key2, key3 = jax.random.split(rng_key, 3)
print(prior_sample_fn(np.ones((2,3)), {"jax_state": key1}, {"jax_state": key2}, {"jax_state": key3}))

Expected behavior

I would expect to be able to use the compiled function just like any JAX function:

logdensity_fn = aesara.function([X_at] + list(vvs), logprob, mode="JAX")
jax.grad(logdensity_fn)(np.ones((3,2)), 1., np.ones(2), np.ones(2), np.ones(2))

With the assumption that for random functions the first argument must be a JAX PRNGKey:

prior_sample_fn = aesara.function([X_at], [tau_rv, lambda_rv, beta_rv], mode="JAX").vm.jit_fn

rng_key = jax.random.PRNGKey(0)
keys = jax.random.split(rng_key, 100)
samples = jax.vmap(prior_sample_fn, in_axes=(0, None))(keys, np.ones((2,3)))

Proposals

To make the compiled functions truly compatible with JAX and the rest of its ecosystem I suggest the following changes:

1. Function.__call__ should be immediately compatible with JAX; we shouldn't have to fetch the vm.jit_fn attribute. An Aesara function is supposed to manage other things like updates of SharedVariables, but I am not sure this is necessary for JAX-compiled functions. Furthermore, if it is supposed to do something that normally cannot be done with JAX then it would be preferable to fail during transpilation rather than output a function that cannot be composed with the rest of the JAX ecosystem;
2. Function.__call__ should not return a tuple when there is a single output;
3. The internal random state should be represented by the rng_key directly, and not a dictionary that contains the key;
4. When there are several random variables in the graph, we should only require one PRNG key;
5. The PRNG key should be passed as the first input
6. Do not return the updated PRNG keys with the functions that take PRNG keys as inputs;

Related to https://github.com/aesara-devs/aesara/issues/1194

Base: #1371

Change the build-backend from setuptools to hatchling.

Question: Is there any reason for docs/ to be included in the sdist? It's not in the wheel.

For some reason I'm having trouble including the file aesara/d3viz/html/template.html. I'm not sure yet why it's being excluded.

Thank you for opening a PR!

Here are a few important guidelines and requirements to check before your PR can be merged:

• [X] There is an informative high-level description of the changes.
• [x] The description and/or commit message(s) references the relevant GitHub issue(s).
• [x] pre-commit is installed and set up.
• [x] The commit messages follow these guidelines.
• [x] The commits correspond to relevant logical 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 of your feature/PR branches.

If your PR is an ongoing effort and you would like to involve us in the process, simply make it a draft PR.

The base of this PR is #1371. The first original commit on this branch is "Remove versioneer".

In the first commit I remove versioneer and set the version to "TODO". In the second commit, I add setuptools_scm.

I also attempt to correctly configure the nightly builds. I do this by running aesara.misc.prepare_nightly_build to modify pyproject.toml in the nightly build, updating the following entries:

[project]
name = "aesara-nightly"
dynamic = []
version = "[generated from aesara.misc.prepare_nightly_build:nightly_version_number]"

[tool.setuptools_scm]
(deleted)

This should be tested, but I'm reasonably confident that it will work properly, and I raise an error if the version number has an incorrect form.

One strange quirk which I don't quite understand is that in order to type-check aesara.misc.prepare_nightly_build I added the types-toml package to the mypy pre-commit config, and afterwards it raised an error about an unused type: ignore in aesara/scan/op.py L3430. Removing the type: ignore resolved the error. :man_shrugging:

Thank you for opening a PR!

Here are a few important guidelines and requirements to check before your PR can be merged:

• [X] There is an informative high-level description of the changes.
• [X] The description and/or commit message(s) references the relevant GitHub issue(s).
• [X] pre-commit is installed and set up.
• [X] The commit messages follow these guidelines.
• [X] The commits correspond to relevant logical 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 of your feature/PR branches.

If your PR is an ongoing effort and you would like to involve us in the process, simply make it a draft PR.

Closes #1322

Given the shape/rate parametrization of GammaRV in Aesara, this addition uses the fact that $$\chi^2_{\text{df}} \equiv \Gamma\left(\frac{\text{df}}{2}, \frac{1}{2} \right).$$

Wiki reference here