Resolve some naming questions

1. I’m not particularly tied to open TorchSharp.Tensor namespace. I’d be happy with open TorchSharp or anything that gives the ergonomics you want

2. When updating DiffSharp to latest I noticed TorchSharp.Device rather than TorchSharp.TorchDevice. Previously I was putting Torch on the front to help disambiguate w.r.t. DiffSharp “Tensor”. But I understand you’ll likely need to switch to plain Tensor. But either do one or the other

    TorchSharp.DeviceType
    TorchSharp.Device
    TorchSharp.Tensor
    TorchSharp.Scalar
   

or

    TorchSharp.TorchDeviceType
    TorchSharp.TorchDevice
    TorchSharp.TorchTensor
    TorchSharp.TorchScalar

Right now we’re a mix of these.

[NiklasGustafsson]

I had a conversation with @dyme offline, and here’s a proposal:

We will strive to make the TorchSharp experience as close to Python as possible. Among other things, this means not always following the standard .NET naming conventions.

Specifically, namespaces and classes corresponding to Python modules, will have lower-case names. Function and parameter names may have C-style casing, using underscores as word separators, instead of camel or Pascal casing.

Since namespaces cannot directly contain methods, we will continue to rely on extensive use of static classes to parallel Python modules.

We will deprecate, and eventually eliminate, the element-type-specific tensor factories, i.e. Int32Tensor, Float32Tensor, BoolTensor, etc. Instead, we will use the same mechanisms as Python does, but take advantage of static typing as appropriate.

For example, to create a 32-bit float tensor with random numbers, you will use torch.rand(...) and either pass in the element type, or rely on the default dtype set in the runtime.

Properties will, as necessary, be renamed to correspond to the PyTorch names. For example, ndims instead of dims or Dimensions

Increased reliance on overloading. Pytorch has a lot of APIs where an argument can be an integer, float, a tuple or list, or a string. TorchSharp already relies on overloading in some cases, but there are more opportunities to do so, and we will attempt to systematically do the work to give users the same flexibility as in Python, while still taking full advantage of .NET’s type system.

[NiklasGustafsson]

Note; the proposed changes will be a massive breaking change.