Skip to content
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

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

Closed
Oceania2018 opened this issue Feb 28, 2019 · 13 comments
Closed

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

Oceania2018 opened this issue Feb 28, 2019 · 13 comments

Comments

@Oceania2018
Copy link

Oceania2018 commented Feb 28, 2019

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
Copy link
Contributor

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
Copy link
Author

Oceania2018 commented Mar 4, 2019

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

@interesaaat
Copy link
Contributor

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
Copy link
Author

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

@deepakkumar1984
Copy link

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

@Oceania2018
Copy link
Author

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

@deepakkumar1984
Copy link

deepakkumar1984 commented Mar 26, 2019 via email

@Oceania2018
Copy link
Author

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
Copy link

deepakkumar1984 commented Mar 26, 2019 via email

@Oceania2018
Copy link
Author

Sure, cross-platform, run in CUDA.

@JeroMiya
Copy link

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
Copy link
Contributor

dsyme commented May 14, 2020

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
Copy link
Contributor

dsyme commented May 15, 2020

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

@dsyme dsyme closed this as completed May 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants