PyTorch tensor factory methods should use torch namespace instead of at

[sbrunk]

Many tensor factory methods defined in torch.java get mapped to functions in the at namespace (from the aTen tensor library underlying PyTorch) instead of the torch namespace.

See rand for instance but this is the case for most factory functions and possibly others as well.

@Namespace("at") public static native @ByVal Tensor rand(@ByVal @Cast({"int64_t*", "c10::ArrayRef<int64_t>", "std::vector<int64_t>&"}) @StdVector long[] size, @ByVal(nullValue = "at::TensorOptions{}") TensorOptions options);

Usually though, we want to call factory functions in the torch namespace because only they give us things like variables and autodiff. I.e. requires_grad does not work on factory methods from aTen.

This is also stated in the docs:

https://pytorch.org/cppdocs/#c-frontend

Unless you have a particular reason to constrain yourself exclusively to ATen or the Autograd API, the C++ frontend is the recommended entry point to the PyTorch C++ ecosystem. While it is still in beta as we collect user feedback (from you!), it provides both more functionality and better stability guarantees than the ATen and Autograd APIs.

https://pytorch.org/cppdocs/notes/faq.html#i-created-a-tensor-using-a-function-from-at-and-get-errors

Replace at:: with torch:: for factory function calls. You should never use factory functions from the at:: namespace, as they will create tensors. The corresponding torch:: functions will create variables, and you should only ever deal with variables in your code.

One thing we might have to consider is backward-compatibility, i.e. by using different names for colliding functions in the torch namespace.

[saudet]

I see, thanks for the information! Are all those factory functions the ones found in "torch/csrc/autograd/generated/variable_factories.h"? from_blob() already gets mapped, so we don't need to worry about that one, but I count about 50 others, including rand(), that are not currently getting mapped because they have the same signatures as other functions in the at:: namespace. Do you feel it would make sense to map all those by prefixing them with torch_?

[sbrunk]

Are all those factory functions the ones found in "torch/csrc/autograd/generated/variable_factories.h"?

I'm not too familiar with the PyTorch codebase yet but yes that looks right to me.

Do you feel it would make sense to map all those by prefixing them with torch_?

I can only speak for my use-case where it would be totally fine. Since I'm building an idiomatic Scala API on top of the JavaCPP PyTorch bindings, I'm wrapping these method calls anyway.

[saudet]

Done in commit f093384! Please give it a try with the snapshots: http://bytedeco.org/builds/

[sbrunk]

I just did a quick test after switching to the torch_... methods from the latest snapshot release:

Looking good! Thanks! And also thanks for updating to PyTorch 1.12.

I haven't tested all factory methods yet but I think we can close this issue and reopen or open a new one if something is still missing.

[saudet]

This fix has been released as part of version 1.5.8. Thanks for reporting and for testing!