Allow broadcasting in Elemwise.c_code

[ricardoV94]

I think this removes any necessity for unbroadcast uses mentioned in #915 and #916.

Closes #335

[codecov]

Codecov Report

Merging #928 (aaa9c3b) into main (b60cf72) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #928      +/-   ##
==========================================
- Coverage   78.92%   78.92%   -0.01%     
==========================================
  Files         152      152              
  Lines       47701    47713      +12     
  Branches    10862    10862              
==========================================
+ Hits        37649    37658       +9     
- Misses       7550     7551       +1     
- Partials     2502     2504       +2     

Impacted Files	Coverage Δ
aesara/scalar/basic.py	79.05% <ø> (ø)
aesara/tensor/elemwise.py	88.17% <100.00%> (-0.27%)	⬇️
aesara/tensor/elemwise_cgen.py	95.74% <100.00%> (+0.29%)	⬆️
aesara/compile/function/types.py	79.91% <0.00%> (-0.14%)	⬇️

[brandonwillard]

Just some minor updates; otherwise, I don't see anything obviously amiss, so we might be able to merge this and simply be ready to fix and/or revert if anything comes up.

[brandonwillard]

After looking at this and working on the c_code implementations for #657, I was brought back to this thread, because I can't help thinking about how simple this would all be if we could just use Cython-generated C code for these c_code implementations.

If you're feeling adventurous, give that thread a read and see if you can construct a _CThunk that uses a Cython-generated extension module. Last I recall, it seemed very doable, so, if it's something that could be hacked together in a few hours, it might be extremely helpful for the (hopefully short) time we'll be spending maintaining this annoying string-based C code.

[ricardoV94]

After looking at this and working on the c_code implementations for #657, I was brought back to this thread, because I can't help thinking about how simple this would all be if we could just use Cython-generated C code for these c_code implementations.

If you're feeling adventurous, give that thread a read and see if you can construct a _CThunk that uses a Cython-generated extension module. Last I recall, it seemed very doable, so, if it's something that could be hacked together in a few hours, it might be extremely helpful for the (hopefully short) time we'll be spending maintaining this annoying string-based C code.

How would Cython make our lives easier? Mainly to avoid having to write code as Python strings?

[brandonwillard]

How would Cython make our lives easier? Mainly to avoid having to write code as Python strings?

It helps with correctness as well, since Cython will take care of all the reference counting.

Also, some (or potentially a lot) of the C code we have implemented as Python strings is already implemented via Cython. For instance, x + y and/or np.add(x, y) in Cython will transpile to the NumPy C API calls that we're currently trying to emulate.

[brandonwillard]

All right, let's do this.