Added names= arg for some creation functions

[zou3519]

Stack from ghstack:

• Added names= arg for some creation functions #21919 Added names= arg for some creation functions
• Named inference rule for more pointwise ops. #22268 Named inference rule for more pointwise ops.
• Enable named inference for some unary pointwise ops #22267 Enable named inference for some unary pointwise ops
• Implement unify_from_right #22223 Implement unify_from_right
• Named inference rule for abs. #22151 Named inference rule for abs.
• Refactor named tensor helper code #22150 Refactor named tensor helper code
• Refactor function_wrapper.create_generic #22077 Refactor function_wrapper.create_generic
• Implement tensor.select(Dimname,int) #21795 Implement tensor.select(Dimname,int)

• empty, ones, zeros, rand, randn

Test Plan

• new tests [namedtensor ci]

gh-metadata: pytorch pytorch 21919 gh/zou3519/56/head

Differential Revision: D15940549

[nairbv]

I think everything after the * is optional and kwarg only, is there a reason we can't just provide a default None value and merge this with the existing interface below?

[zou3519]

Yes, there is a reason and it is complicated. The short answer is that this is the easiest way to implement it.

Long answer: We've got two rand declarations in native_functions.yaml (without the Generator arg):

- func: rand(int[] size, *, ScalarType? dtype=None, Layout? layout=None, Device? device=None, bool? pin_memory=None) -> Tensor
- func: rand(int[] size, *, Tensor(a!) out) -> Tensor(a!)

These get merged together to produce one scheme string for the python arg parser:

    "rand(IntArrayRef size, *, Tensor out=None, ScalarType dtype=None, Layout layout=torch.strided, Device device=None, bool pin_memory=False, bool requires_grad=False)",

Now, my claim is that it doesn't make sense to add a names= argument when an out tensor is provided. If there were such an arg, it could either

• (1) check that the out tensor has the correct names. In this case, the user would always have to specify the correct names which is bad because it's verbose and unnecessary.
• (2) override the names of the out tensor: this is weird, especially if names=None by default.

Because it doesn't make sense, rand(int[] size, *, Dimname[]? names, ScalarType? dtype=None, Layout? layout=None, Device? device=None, bool? pin_memory=None) -> Tensor
should be a separate schema that isn't combined with an out= argument.

[nairbv]

ah weird, OK

[zou3519]

It's weird and I don't like it because it means we need 2x the schemas and that it's easy for the schemas to go out of sync. But I don't know of how else we can do this.

[nairbv]

I know we don't plan to support an ordered-dict option because of python2, but is there any chance we'll want to support an option to construct named tensors in C++ using an ordered map? or would the syntax be just as unwieldy as python2?

[zou3519]

There are no plans for named tensor support in C++ in the near future.

[zou3519]

Closing because I want to do this another way.