Make API more easy to use by following python's syntax.

[Oceania2018]

Is it possible change the high level API like what SciSharp's done? Check the README: https://github.com/SciSharp/TensorFlow.NET.

For example:

using TorchSharp;

var x = new FloatTensor (100);   // 1D-tensor with 100 elements

Will be

using torch = TorchSharp.Torch;

var x = torch.tensor(100)   // 1D-tensor with 100 elements

Mirror API first would make progress be faster that move ML model to .NET world. Project will be done faster than ML.NET. @migueldeicaza When most of the thing runs well, we can refactor code that be more .NET conventions.

[interesaaat]

I personally believe that we should stay closer to C# conventions instead of exactly mirroring the python API. The goal of the project is in fact to provide a way for C# users to run and build deep learning models through PyTorch, and not the other way around (i.e., PyTorch users that want to use C# instead of python). For instance I have several problems with this:

• C# is typed, are we sure we still want to hide types to TorchSharp users?
• C# users may find the Python-ish API weird to use
• Since we are mapping to C++ object we will have to surface some C# stuff anyway (e.g., object disposal)

[Oceania2018]

We could reactive the KerasSharp, wrap the TorchSharp and TensorFlow.NET or TensorFlowSharp, ML.NET and CNTK.

[interesaaat]

This could be a good option! I also like the idea of using Keras API on top of ML.NET (how does that work?)

[Oceania2018]

@interesaaat The author of KerasSharp doesn't response cesarsouza/keras-sharp#29 .

[deepakkumar1984]

A similar project like keras sharp with multiple backends. I can try to include torchsharp soon.
https://github.com/deepakkumar1984/SiaNet/

[Oceania2018]

@deepakkumar1984 Could you add TensorFlow.NET as a backend?

[deepakkumar1984]

I can add it as a variation to Tensorflow implementation. Already using Tensorflowsharp but I can this library as well and rest upto the user to use specific backend.

…

On Tue, Mar 26, 2019 at 2:56 PM Haiping ***@***.***> wrote: @deepakkumar1984 <https://github.com/deepakkumar1984> Could you add TensorFlow.NET <https://github.com/SciSharp/TensorFlow.NET> as a backend? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGCQKWd2wicdH69-UfaI1F6_U5x5jXDnks5vaaGAgaJpZM4bXXcp> .

-- Regards, Deepak

[Oceania2018]

Refer this thread, you will know how valuable it is. The most important is TensorFlow.NET can Build Graph -> Train -> Inference model in one library. @deepakkumar1984

[deepakkumar1984]

Does it support CUDA?

…

On Tue, Mar 26, 2019 at 3:15 PM Haiping ***@***.***> wrote: Refer this thread <SciSharp/TensorFlow.NET#180>, you will know how valuable it is. The most important is TensorFlow.NET can Build Graph -> Train -> Inference model in one library. @deepakkumar1984 <https://github.com/deepakkumar1984> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGCQKdAIepDjgSm7xPYCzufD2jZ-8EmJks5vaaXRgaJpZM4bXXcp> .

-- Regards, Deepak

[Oceania2018]

Sure, cross-platform, run in CUDA.

[JeroMiya]

This seems to be a recurring issue with libraries ported from other languages to .NET - what naming convention to use for the API?

There are two schools of thought:

1. Keep close to the original library's naming conventions, even if they conflict with the .NET naming conventions, to make it easier to port code from samples and documentation into the new .NET library.
2. Use the .NET naming conventions, making the library easier to use for .NET developers. These naming conventions convey information (e.g. property vs function vs field etc...) and when they are not followed code can become more difficult to read.

Both of these schools of thought are equally valid, but of course they conflict with each other. I think school of thought 1 is best for the early stages of the library, getting started, etc... but I think long term 2 is the best. Supporting both in parallel would be ideal though. It would be nice if there were some automated way to generate a .NET convention version of the API surface in parallel to the Python-style API.

As an aside, it's interesting to me that F# uses a naming convention more like Python (for historical reasons, given F# is based on the ML family of languages), but only for private methods within an implementation and for the F# standard library. Even for F# facing libraries written in F#, the recommended conventions for public facing APIs is to use the .NET convention, though that seems to be inconsistently followed in the wild.

[dsyme]

Just to note that if I was starting this repo from scratch, I would make it part of SciSharp, and follow SciSharp's naming conventions (i.e. use PyTorch Python naming conventions)

But for now we will stick to the naming conventions we have here

[dsyme]

I'm closing this as it's covered by #95