Use TF Numpy instead of NumSharp

[Oceania2018]

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.

[dataangel]

Impressive

[henon]

牛逼

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

[pepure]

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

[Jiuyong]

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]

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

[Nucs]

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]

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]

@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.