Refactoring to include index_nplike and reducers

[findingmochi]

No description provided.

[codecov]

Codecov Report

Merging #1490 (3b1c7ff) into main (de7cae8) will decrease coverage by 0.05%.
The diff coverage is 74.16%.

Impacted Files	Coverage Δ
src/awkward/_v2/_connect/cuda/__init__.py	0.00% <0.00%> (ø)
src/awkward/_v2/_connect/numexpr.py	88.40% <ø> (ø)
...c/awkward/_v2/_connect/rdataframe/to_rdataframe.py	0.00% <0.00%> (ø)
src/awkward/_v2/operations/ak_from_arrow.py	100.00% <ø> (ø)
src/awkward/_v2/operations/ak_from_arrow_schema.py	50.00% <ø> (ø)
src/awkward/_v2/operations/ak_from_cupy.py	50.00% <ø> (ø)
src/awkward/_v2/operations/ak_from_jax.py	100.00% <ø> (ø)
src/awkward/_v2/operations/ak_from_json_new.py	0.00% <0.00%> (ø)
src/awkward/_v2/operations/ak_from_numpy.py	100.00% <ø> (ø)
src/awkward/_v2/operations/ak_is_tuple.py	100.00% <ø> (ø)
... and 132 more

[jpivarski]

I like this approach!

[agoose77]

I'm a 👍 on this as well, it will be good to formally distinguish between index and content nplikes. Minor thought - is it worth using a slightly shorter name like index instead of index_nplike? It would make the code slightly more readable, and I think it's safe enough given that there is no np.index.

[jpivarski]

I'm a +1 on this as well, it will be good to formally distinguish between index and content nplikes. Minor thought - is it worth using a slightly shorter name like index instead of index_nplike? It would make the code slightly more readable, and I think it's safe enough given that there is no np.index.

We could, although I think that would be easy to do at any time; nplikes are rather internal. Perhaps the nplike module ought to be made private (renamed to _nplike) so to formally say that we have this flexibility.

At this time, though, @swishdiff needs to finish his project (it's the last week!) and we can consider renaming later.

"index" might be a little understated, though. I would have trouble guessing what it means. Something like "for_index" would be more helpful, but that's getting back to the original length.

[agoose77]

"index" might be a little understated, though. I would have trouble guessing what it means. Something like "for_index" would be more helpful, but that's getting back to the original length.

Actually, it's not just a length issue (which, in reality, I don't tend to weight that heavily). I should not have said "shorter", as it implied that length is an important metric.

Rather, I find nplike.index_nplike less readable for repetition than nplike.index.zeros or nplike.for_index.zeros.

We could, although I think that would be easy to do at any time; nplikes are rather internal. Perhaps the nplike module ought to be made private (renamed to _nplike) so to formally say that we have this flexibility.

OK, no problem - it won't take long to do should we see fit at a later date. Good luck @swishdiff!

[jpivarski]

JAX segment_prod has some subtleties: jax-ml/jax#9296 We're using the log → sum → exp that they recommend there.

[findingmochi]

@jpivarski please merge this when the tests pass. There are two cases in _slicing.py, that probably need special treatment for Jax, for now they raise an error if the nplike is Jax

[jpivarski]

I approve! You can squash-and-merge.