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

Use TF Numpy instead of NumSharp #658

Open
Oceania2018 opened this issue Dec 6, 2020 · 13 comments
Open

Use TF Numpy instead of NumSharp #658

Oceania2018 opened this issue Dec 6, 2020 · 13 comments
Assignees
Labels
discussion A topic needed to discuss enhancement New feature or request

Comments

@Oceania2018
Copy link
Member

Oceania2018 commented Dec 6, 2020

TensorFlow implements a subset of the NumPy API, available as tf.experimental.numpy. This allows running NumPy code, accelerated by TensorFlow, while also allowing access to all of TensorFlow's APIs. It will be available in the stable branch starting from TensorFlow 2.4.

Several benefits of using TF Numpy

@dsyme @henon @Nucs Please advise.

@Oceania2018 Oceania2018 added the discussion A topic needed to discuss label Dec 6, 2020
@Oceania2018 Oceania2018 self-assigned this Dec 6, 2020
@dataangel
Copy link
Member

dataangel commented Dec 6, 2020

Impressive

@henon
Copy link
Contributor

henon commented Dec 6, 2020

牛逼

For the rest of the world: Niú bī (vulgar) means awesome.

@Oceania2018 Oceania2018 assigned fdncred and unassigned fdncred Dec 6, 2020
@pepure
Copy link
Member

pepure commented Dec 7, 2020

It's good to be in one framework, and it should be more comfortable to develop deep learning code.

@Jiuyong
Copy link
Contributor

Jiuyong commented Dec 7, 2020

This approach is supported. Constantly between modules in order to glue is enough annoying. Another implementation of numpy is not out of the way. It is recommended to act as a module alone.

@Banyc
Copy link
Member

Banyc commented Dec 8, 2020

NumSharp has issues to be solved. Leveraging TF Numpy could reduce unexpected behaviors.

@Nucs
Copy link
Member

Nucs commented Dec 8, 2020

I agree with @Jiuyong, perhaps @Oceania2018, @henon we do need to discuss further about creating an abstract layer to numpy that'll be shared between NumSharp, Numpy.NET and potentially as a standalone module/nuget-package/project for Tensorflow.NET's numpy that will also use this interface.
I have an architecture in mind that can work by moving static class np to a common project. np then will direct calls to a statically appointed numpy engine property - which then tunnel any numpy calls to the assigned engine or throw exception if none specified.
This will allow the binding of ANY numpy engine and the developers get to choose their preference.
The challenge is making the INDArray interface to have enough/all api exposed to enough to replace all tensorflow.net use cases of NumSharp. Perhaps even abstract class and not interface.
We should talk of a small proof of concept.

@henon
Copy link
Contributor

henon commented Dec 8, 2020

an interface in an independen package would work in theory. in practice, we are looking at ~500 api functions. that would be a huge effort of standardization between the three libs. that would be a year's work for an intern

@Oceania2018
Copy link
Member Author

Oceania2018 commented Dec 8, 2020

@Nucs A seperate abstraction is helpful. @henon It's time to make a standard interface for so many NDArray/ Tensor/ Vector implementation. @dsyme I think it could also benefit F# world. The only thing I would insist is it should keep similar syntactic sugar as python world.

@Oceania2018 Oceania2018 assigned Nucs and unassigned Oceania2018 Dec 13, 2020
@Oceania2018 Oceania2018 added the enhancement New feature or request label Dec 13, 2020
@Nucs
Copy link
Member

Nucs commented Dec 13, 2020

@henon @Oceania2018 After chatting with both of you privately, I decided to take lead on this project (Tensorflow Numpy aka tnp) and maintain it in the future.
Here are the design choices we'll go with:

  • We'll create a separate package Tensorflow.Numpy for maintainability and because it is still experimental.
  • The package will provide numpy's functionalities usable within a graph.
  • The functionalities will be available on tnp identically to Tensorflow's way of using it.
  • There will be a new NDArray class, probably will name it TNDArray for TensorflowNDArray.
  • Tensorflow Numpy's implementations will accept and return tensors.

In a nutshell, tnp will be a mini-NumSharp powered by Tensorflow.
Share your thoughts and prayers.

Edit: changes based on change requests below

@Oceania2018
Copy link
Member Author

@Nucs Appreciate for your continuous contribution. Several things come out:

  • Rename the project as TensorFlow.Numpy to be consistent with other projects
    image
  • TNDArray works.
  • What about if they can converted implicity between TNDArray and Tensor?

@Nucs
Copy link
Member

Nucs commented Dec 13, 2020

I think that TNDArray (equivalent of tf.experimental.numpy.ndarray) is just a 'shell' to pipe calls onto Tensor methods.
I might even make TNDArray to inherit Tensor if it'll make sense.
Once I have the smaller design details tuned after diving onto Google's implementation and docs then I'll be able to tell better.

@simonbuehler
Copy link

hi,
is there any progress with this, i'd really like to dump numsharp and numpy.net and the conversions between the datatypes back&forth

@Oceania2018
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion A topic needed to discuss enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants