TensorFlow.NET
TensorFlow.NET copied to clipboard
Use TF Numpy instead of NumSharp
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
- More complete NDArray API.
- Reduce memory copy, especially in distributed training scenarios.
-
Significantly speed up your NumPy operations using Tensorflow and its new NumPy API
@dsyme @henon @Nucs Please advise.
Impressive
牛逼
For the rest of the world: Niú bī
(vulgar) means awesome
.
It's good to be in one framework, and it should be more comfortable to develop deep learning code.
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.
NumSharp has issues to be solved. Leveraging TF Numpy could reduce unexpected behaviors.
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.
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
@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.
@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
forTensorflowNDArray
. - 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
@Nucs Appreciate for your continuous contribution. Several things come out:
- Rename the project as
TensorFlow.Numpy
to be consistent with other projects -
TNDArray
works. - What about if they can converted implicity between
TNDArray
andTensor
?
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.
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
@simonbuehler Check out update: https://twitter.com/ScisharpStack/status/1415652428830154752