HNHacker News
TopNewBestAskShowJobs

me2too

231 karma · joined July 14, 2018

https://pgaleone.eu/
submissionscomments
me2too··on Tensorflow 2.0: models migration and new design
But the API is strictly statically typed in reality. The core is written in C++ and every operation requires a well-known type in input. As you can see from the error raised in this example: https://pgaleone.eu/tensorflow/go/2017/05/29/understanding-t...
me2too··on Tensorflow 2.0: models migration and new design
But why? I do use Tensorflow form the 0.x release and I'm still using it right now, migrating all the codebase to the 2.x version.

I can do everything in both pytorch and tensorflow and when I have to define really efficient input pipelines (tf.data is a great thing), parallelize and distribute the training and export a trained model to production... With tensorflow everything is easier.

Moreover, pytorch in 1.x will have static-graph too, exactly like Tensorflow.

Both frameworks are converging to something really similar. I don't see a reason to switch (right now)

me2too··on Tensorflow 2.0: models migration and new design
The fact that I have all the computation described in a coherent manner, in something that's agnostic to the language I'm using.

The same description (the graph) can be taken and used in every other language. I can move a trained model to production just picking a single file (a `tf.train.SavedModel` IIRC), give it a tag and I'm ready to go, with different models with a native support for the "tagging" (hence the model versioning).

me2too··on Tensorflow 2.0: models migration and new design
At your contrary, I love the graph.

However, migrating to a keras-like approach, you can work thinking about "objects with variables inside" and then the graph will be built for you by the abstraction introduced by `tf.keras.Model`.

However, for automatic differentiation, graph is always required (as you can see from the example that uses eager)

← PreviousPage 2 of 2