Support for Tensorflow 2.0

[SestoAle]

Hi,

does the latest master support Tensorflow 2.0?

If not, when do you think it will be supported?

Thanks!

[SestoAle]

I tried to use a TF2.0 freezed graph, building and importing the right library, with the latest version of TensorflowSharp but it raises this error:

" Op type not registered 'agent.independent_act_assert_equal_Assert_AssertGuard_true_4481' in binary running on Glados. Make sure the Op and Kernel are registered in the binary running in this process. Note that if you are loading a saved graph which used ops from tf.contrib, accessing (e.g.) tf.contrib.resampler should be done before importing the graph, as contrib ops are lazily registered when the module is first accessed."

This is because TensorflowSharp doesn't support TF2.0?

[chriss2401]

Check this post :

#464

Currently there is only support up until v1.15

[WoWPerro]

I am having the same problem, I learnead Tf 2.0 but I think tf 1.15 is quite different, so is it going to get support for tf 2? or should I start learning older versions of tensorflow?

[chriss2401]

I would suggest using TensorFlow.NET , which is still being maintained. Seems like TensorFlowSharp is a bit dead.

[WoWPerro]

Ok, I´ll start using Tensorflow.NET, thanks for the advice

[glopesdev]

Anyone knows what it would take to upgrade the ops to TF 2.x? TensorFlow.NET has several unnecessary dependencies (Serilog, etc) which are annoying for lightweight applications.

[chriss2401]

TF 2 has plenty of breaking changes so I'm not sure it would be that trivial to do.

[dsyme]

@glopesdev Might be best to engage with Tensorflow.NET to fix the problems? I suspect their aim is more for training than inference, so overall size less of a priority, but perhaps you can help then factor a version suitable for your needs?

[glopesdev]

Thanks @dsyme, I will try to do this and open an issue in their repository. After a first audit of TensorFlow.NET source code, however, I suspect the maintainers might not be very happy with my proposal. I am including my main points here as a reference for my investigations.

Essentially, the root of my problems seem to stem from the fact that TensorFlow.NET defines and makes use of its own implementation of NumPy in the namespace Tensorflow.NumPy.

This is strange because SciSharp itself already seems to have their own wrapper around NumPy called Numpy.NET in a different repository, so why implement another one?

It is also unnecessary because the native tensorflow libraries work perfectly well without any connection to NumPy (as this repository demonstrates), and Tensors can be implemented to work with opaque addresses specified as IntPtr. This is very desirable as it allows easily specifying tensors using memory buffers handled by other image processing / dsp libraries (e.g. OpenCV, etc).

Furthermore, on top of these custom types, TensorFlow.NET provides custom attributes and integration with platforms for dependency injection and aspect-oriented programming (MethodBoundaryAspect.Fody) which I have never used nor need, and which themselves bring a whole host of other dependencies which we would have to audit and understand.

It was also slightly unnerving to find several naming inconsistencies:

• TensorFlow.NET is the solution name, but namespace and all other project names are spelled Tensorflow
• Numpy.NET uses capitalization Numpy but TensorFlow.NET defines the namespace Tensorflow.NumPy
• NuGet package is called TensorFlow.NET which seems to refer to the whole project, including Keras, etc, but the only library inside the package is Tensorflow.Binding

Finally, I really don't feel comfortable with the choice of breaking all .NET naming conventions to make syntax artificially similar to Python. These are two very different languages, with different style guides, and I don't think it's very helpful to make C# code more "pythonic", although I admit this last point I would be happy to live with if the major points above were addressed.

All of these design decisions seem pretty core to their implementation, so I find it very likely my issues will come across as unreasonable at this point, but I will try anyway. In the meantime I'm also studying this repository and other options for automatically generating lightweight bindings directly from the native tensorflow C API. I have made a note to update this thread after we come up with a satisfying solution.

[glopesdev]

As a further reference, the reason for the first issue outlined above seems to originate from an actual change in TensorFlow. Starting from version 2.4 it seems the TensorFlow team decided to implement and provide their own optimized version of NumPy as a separate package for performance reasons. Discussion on the implications of this change for TensorFlow.NET can be found in this issue: SciSharp/TensorFlow.NET#658

In short, it was discussed separating this functionality into a new package but ended up together with the bindings, which still seems unnecessary unless one is interested in low-level tensor manipulation.

This still does not not explain, however, why tensors should be tied in to aspect-oriented programming or dependency injection frameworks.

[glopesdev]

Progress report: after diving a bit into the internals of tensorflow.dll it looked like the overall structure of the low-level API is pretty similar, so I just went ahead and ran the generator on the updated base_api definition and it seemed to work fine overall apart from a couple of new types which affect less than 1% of operations.

Ran a test afterwards of the wrapper output with the updated tensorflow 2.8.0 DLL and everything seemed to go fine, including configuring GPU, etc, so @chriss2401 despite your fears, I'm not sure anymore that this would be such a huge endeavour.

I might actually just start trying this out on my fork and see what happens. My use case for this is pretty minimal, basically import a graph definition from a file and run inference, so reading and writing some tensors, which looks mostly unaffected by any breaking changes. Will update with future steps.

[chriss2401]

Great progress @glopesdev and definitely valid points regarding TensorFlow.NET. Personally I moved more to an ONNX approach for inference when TensorFlowSharp "died", as it seemed as the most sustainable solution.

Another interesting point is now recently Microsoft has started to maintain TorchSharp (https://github.com/dotnet/TorchSharp) , so if PyTorch is an option for you I'd keep an eye on it.

[glopesdev]

I've submitted a PR to fix this, but I understand it will never be merged here, so it will probably be my last PR to this repository. For now, I will continue development here: https://github.com/glopesdev/TensorFlowSharp/tree/develop