Skip to content

reshape, broadcast_to, and permute_dims do not accept a single integer #608

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
asmeurer opened this issue Mar 7, 2023 · 3 comments
Closed
Labels
status: Rejected Proposed change was not accepted.

Comments

@asmeurer
Copy link
Member

asmeurer commented Mar 7, 2023

reshape, broadcast_to, and permute_dims (I think these are all but I could have missed one), all accept a Tuple[int, ...]. The shape parameter for reshape and broadcast_to for shape, and axis for permute_dims

Every other function that accepts this kind of parameter accepts Union[int, Tuple[int, ...]].

It was pointed out in data-apis/array-api-compat#28 that NumPy currently accepts ints for all of these (and indeed, numpy.array_api accidentally does), but PyTorch does not.

@kgryte
Copy link
Contributor

kgryte commented Mar 8, 2023

IIRC, the use of an integer is not the dominant use case and is more of shorthand in NumPy. In #42, we explicitly favored Torch (and somewhat TF) in restricting to a tuple for reshape.

For permute_dims, providing an integer does not make sense as a shorthand, except for the trivial case of a 1d array.

In general, I'd argue that a shape kwarg should be a tuple. If NumPy wants to support an integer shorthand, that's its prerogative, but I don't think this should be codified in the spec.

@rgommers
Copy link
Member

rgommers commented Mar 8, 2023

Every other function that accepts this kind of parameter accepts Union[int, Tuple[int, ...]].

The only instances of shape parameters are for creation functions (ones & co) and manipulation functions (the ones you mentioned. The former accept ints, because ones(3) is a super common shorthand. The latter all require a tuple. So I'm inclined to agree with @kgryte here and say that the current state is fine, and preferred over allowing reshape(3).

@rgommers
Copy link
Member

rgommers commented Mar 8, 2023

Since this was reviewed in gh-42, there are good reasons for this, and data-apis/array-api-compat#28 is already closed, let's close this one too.

Thanks @asmeurer and @kgryte

@rgommers rgommers closed this as completed Mar 8, 2023
@rgommers rgommers added the status: Rejected Proposed change was not accepted. label Mar 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: Rejected Proposed change was not accepted.
Projects
None yet
Development

No branches or pull requests

3 participants