feat: to/from PyTorch JaggedTensor

[maxymnaumchyk]

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 23.25581% with 66 lines in your changes missing coverage. Please review.

Project coverage is 81.85%. Comparing base (b749e49) to head (c68321c). Report is 182 commits behind head on main.

Files with missing lines	Patch %	Lines
src/awkward/operations/ak_to_jaggedtensor.py	20.00%	40 Missing :warning:
src/awkward/operations/ak_from_jaggedtensor.py	23.52%	26 Missing :warning:

Additional details and impacted files

Files with missing lines	Coverage Δ
src/awkward/operations/__init__.py	100.00% <100.00%> (ø)
src/awkward/operations/ak_from_jaggedtensor.py	23.52% <23.52%> (ø)
src/awkward/operations/ak_to_jaggedtensor.py	20.00% <20.00%> (ø)

... and 105 files with indirect coverage changes

[maxymnaumchyk]

@jpivarski should I also leave out a "keep_regular" parameter since it does the same as ak.from_regular()? It's kind of the same situation we talked about today (about "padded" parameter).

[jpivarski]

You're right: it is. The situation is that we should be providing an interface to the user that's like Lego bricks that they can put together however they like. If there's an alternative way of doing something, it shouldn't be a feature of the new functions, because then we'd have to explain why someone would use one or the other.

I agree that the padded and keep_regular arguments are more convenient if that's exactly what someone wants; passing padded=True or keep_regular=True is easier than the multi-step process it would be with the other method. However, these shortcuts would only work in the cases that these functions apply to, which are limited by the capabilities of TensorFlow and PyTorch's ragged array implementations.

[maxymnaumchyk]

thanks for such a detailed answer!

[jpivarski]

I think this one was closed in favor of another. This was the implementation that converted to and from a data type that users of PyTorch are not familiar with.