RFC: add inspection support for querying the maximum number of supported dimensions

[kgryte]

In #640, we proposed adding a unified inspection API namespace, and, in that proposal, we included support for querying array library capabilities.

That RFC includes two capabilities:

• data_dependent_shapes
• boolean_indexing

In this RFC, I'd like to propose a third; namely, the ability to query the maximum number of supported dimensions. This RFC is related to #479, where it was requested that the specification provide better guidance regarding the minimum upper bound array rank. During Consortium working group meetings, a minimum upper bound of 4 has been discussed.

As such, different array libraries are likely to support different upper bounds, and downstream libraries should have an ergonomic means for determine what that upper bound is in order to ensure portable code. This RFC proposes that we add another field to the dictionary returned by info.capabilities(): max_rank.

As currently written, #640 requires dictionary values be booleans. This RFC would require that requirement to be relaxed, such that dictionary values may, in general, be any value, but specific dictionary keys must be assigned values of a particular type. In this case, max_rank should have an integer value.

[rgommers]

Thanks @kgryte. Seems reasonable to me to add this.

In this case, max_rank should have an integer value.

It is not unlikely that there is no such value for some libraries, it may be infinite. If you can instantiate an empty array with a fixed memory cost rather than it increasing with the number of dimensions, there's no reason that there must be a max rank. So allow None?

[leofang]

IIRC PyTorch allows it to be infinite (through broadcast). But why not just use library-specific inf if it exists, or use the builtin float('inf')?

[seberg]

Allowing float('inf') sounds reasonable, although I doubt there is any lib at this time with truly no limit, it might just be somthing very large like 2**31 or even up to 2**64 (which is bigger than anything plausible anyway).

[rgommers]

It doesn't matter too much, but Optional[int] communicates the intent better and seems a little nicer static typing-wise than Union[int, float] for something that inherently is an integer if it exists.

[leofang]

Sounds good to me. I support this RFC.