Short- to medium-term planning

[ev-br]

With the MVP stage being finalized in the "stack" of gh-70 -- gh-83, let's think of prioritizing future work. Small fixes aside, larger work items at the moment are

• NumPy API coverage. https://github.com/Quansight-Labs/numpy_pytorch_interop/blob/main/autogen/numpy_api_dump.py lists numpy apis which are not implemented at all. The list needs some prioritization, too. -- EDIT: see NumPy API surface : plan/prioritize the coverage #87
• fancy/advanced indexing and related functions
• ufunc dtype resolution and its interaction with the registered loops. Our current implementation does not have any of this: explicit dtype=... raises NotImplementedError, and internal loops are delegated to whatever pytorch is doing. -- dtype=... arguments of ufuncs #89

Status "after the MVP":

• dtype resultion/promotion/casting in general : consistenty follow NEP 50

Status "maybe later or not at all":

• where = ... arguments to ufuncs and related gather/scatter type functionality
• non-default array orders and fortran-ordered arrays (do we support this at all?)

[rgommers]

Thanks for writing this up Evgeni!

NumPy API coverage. https://github.com/Quansight-Labs/numpy_pytorch_interop/blob/main/autogen/numpy_api_dump.py lists numpy apis which are not implemented at all. The list needs some prioritization, too.

Do you want to do this in a second issue? I guess we need the diff between the names in numpy_api_dump.py and dir(numpy) plus the same for the key submodules - fft, linalg, random`.

For the rest of the items:

• dtype= sounds like the top prio to me.
• Advanced indexing should also be high on the list I'd think - PyTorch should already have implementations that mostly match NumPy, so hopefully this isn't a ton of work.
• dtype resultion/promotion/casting in general: we probably won't get every last detail right here, and it'll change for scalars with NEP 50. I'd prefer to match the new behavior after NEP 50 becomes the default - that should be easier to do, and future-proof. For the rest, I'm not sure what falls in this bucket exactly.
• where= seems low-prio, it isn't used much and it's nontrivial to implement probably
• array ordering: don't support it at all I'd say.

[ev-br]

Do you want to do this in a second issue? I guess we need the diff between the names in numpy_api_dump.py and dir(numpy) plus the same for the key submodules - fft, linalg, random`.

Let's take it to gh-87 indeed.

[ev-br]

dtype resultion/promotion/casting in general: we probably won't get every last detail right here, and it'll change for scalars with NEP 50. .... For the rest, I'm not sure what falls in this bucket exactly.

For one, there are several probably related type promotion related functions, e.g. result_type and find_common_type and common_type. While probably not very interesting by themselves, they seem to provide python-level analogs of internal type promotion routines (?). For now I'm using result_type everywhere I need to combine two types. Pretty sure it's mostly OK for now, and the rest of this bucket is figuring out how carefully we want to match numpy and what are the precise rules in varying situations.

[rgommers]

result_type is the nicest function indeed. can_cast is useful too. find_common_type IIRC is less ideal.

[lezcano]

+1 to Ralf's comment on what should be what prio.

[lezcano]

On the design perspective, I think that when we iron out a few things (discussed privately with @ev-br), we'll be on a very good state. With the massive refactor via the annotations trick, now we have been able to separate the preprocessing and the actual implementation of pretty much all the functions! With this at hand, we should be able to remove the split we had between implementation and interface. Here's the structure that I propose we have in the end:

• _casting.py (currently _detail/_casting_dicts.py ). This file just depends on torch.
• _dtypes.py (currently _dtypes.py and _detail/dtypes_impl.py). This will depend on _casting.py and
• _utils.py (currently _detail/utils.py) that just depends on _dtypes.py. This implements a number of commonly used helper functions at a torch level.
• _wrap.py (currently _helpers.py). This will have the utility functions to map ndarrays to tensors and back. This will be the only place where we will allow to have local imports (modulo a couple other exceptions that will be reviewed on a per-case basis).
• _decorators.py (currently _normalizations.py and _decorators.py). This one will depend on _dtypes.py and _utils.py.
• _{unary,binary}_ufuncs.py, _reductions.py, _funcs.py, random.py, linalg.py, etc. These will depend on the _dtypes.py and _decorators.py and perhaps _utils.py.
• _ndarray.py. This one will depend pretty much on all the above.

[ev-br]

This issue has run it's course, it seems.