the example above is AC unification (well, it's actually more than that: relational "matching" with AC properties)
the examples aren't that great, but I think they'll do the job for now
tell me if you think anything should be clarified/added
Where should I move softmax and related Ops to in the tensor module? Does a new file
softmax.py make sense? math seems a bit cluttered. There is also extra_ops.py?
2 replies
On another note, anyone has a good trick to manage default updates of random variables in a scan, when not using a
RandomStream?import aesara
import aesara.tensor as at
rv, updates = aesara.scan(
fn=lambda : at.random.normal(0, 1),
n_steps=5,
)
print(rv.eval())
# [-1.5294442 -1.5294442 -1.5294442 -1.5294442 -1.5294442]
print(rv.eval())
# [-1.5294442 -1.5294442 -1.5294442 -1.5294442 -1.5294442]
I'm not a big fan of stateful rngs anymore, too much magic going on
I was thinking about doing a correspondence table between
aesara and numpy and start working my way through the list. Could do that with scipy as well.
That would definitely be nice. My question is more of how do we arrange things internally (and possibly how do we show to users). We are trying to offer functions that can come from two different libraries (numpy and scipy). We have been putting everything in
math, but this can get unwieldy.
I would say in a way that has the least cognitive overhead for someone who is already familiar with numpy/scipy
Do you think that everything that is in scipy.special should go into tensor.special?
That’s a small deviation from what i’m used to (jax has
jax.numpy and jax.scipy) but it would make a lot of sense
The way i usually work on api and modules is by writing mock code
And to that respect the separation numpy/scipy is sometimes (often) confusing
from aesara.tensor.special import softmax ?
from aesara.tensor.math import softmax
Well math objects are usually offered at the tensor level, so it would be
from aesara.tensor import softmax or more typically import aesara.tensor as at; at.softmax
if it’s only going to be visible to developers I’d suggest
special.py. Makes comparisons with what’s available in scipy easier
So we should move the equivalent tensor/math.py methods that are implemented scipy.special to there, and then what I wanted to do in the first place which was to take the softmax out of nnet
Yeah that's coming out. I just didn't want to put it in the already large math.py
I’m reading the code for linkers and I have 2 questions:
1- Is there any reason why the file structure is different for numba and jax linkers?
2- Is there any way to print the generated code without compiling for debugging ? That was very useful with MCX.
Regarding the file structure I guess the one of the reason we split numba's dispatch was because the file was getting too long.
The jax file structure is pretty much same except for dispatch being in same file. We should probably split it like Numba.
Thanks! Oh and 3- why is the code generation approach used with numba and not (that I saw) with jax?
Probably because Jax offers much more flexibility than Numba.
For instance take the case of Scan. Jax has an inbuilt scan like functionality, but in case of Numba we have to create the loops manually.
We can use code generation approach in Jax too, but i think we're yet to run into logic that cannot be implemented in Jax.
1 reply
Regarding debugging I don't know what's the usual way to go about it. For me I just put a break point in the compile_function_src. Which gives me source string for required function.
That function is located in link/utils.py I think
The problem is some of the functions aren't generated with strings while some of them are. So it's pretty hard to get a uniform debug functionality on them.
1 reply
and both are technically taking the exact same approach
the difference is the interface
at least in the case of
Scan
that has more to do with JAX's limitations (or scope/purpose), though
it's a tensor library
Numba is much more general
attempting to cover nearly all of Python
but, yeah, I see what you're saying
it's a limitation in terms of mapping simplicity and the like