Rémi Louf

> Regardless, we really shouldn't be "special casing" `RandomVariable`s in this way. ~~I'm not sure about this one. Remember that this PR was created to address an issue with etuplization...

Evaluating `Op`s now returns an `Apply` node, as opposed to a `TensorVariable` (or an error in the case of `RandomVariable`s) on the `main` branch. Is that what we want? Asking...

It is trickier than I thought because there is an assumption throughout the code that inputs to `Apply` nodes are passed as arguments individually. This causes issues when evaluating nested...

_Following up on a discussion with @brandonwillard_ This indeed touches on a much deeper issue, that is the fact that Aesara's IR lacks the ability to represent selections of specific...

## Adding `nth` I added a `nth` function that takes an index `n`, and apply node `node` and returns `node.outputs[n]`. I also updated the tests related to etuplization/evaluation because they...

This is not immediately relevant to this PR, but let’s consider the single output case and how etuplization, unification and reification currently behave in this case: ```python import aesara.tensor as...

Well, what I was discussing above has direct consequences today because of `default_output`. The following fails to unify: ```python class MyDefaultOutputOp(Op): default_output = 1 def make_node(self, *inputs): outputs = [MyType()(),...

I have fixed the unification with the default outputs of a multiple-output `Apply` nodes. I am now trying to define the behavior of `etuplize` when passed a list of outputs...

This PR got a little out of hand, and I will leave etuplizing a list of multiple outputs for another PR as it seems more complicated than I originally thought,...

Back in the days when I was in the process of re-inventing theano (!) I spent a lot of time thinking about how to represent control flow. I came to...