6 ms·

> because TensorFlow’s API is verbose and confusing, and because Keras has the most thoughtfully designed, expressive API I’ve ever experienced This doesn't fe

> because TensorFlow’s API is verbose and confusing, and because Keras has the most thoughtfully designed, expressive API I’ve ever experienced This doesn't feel fair to say, just like it wouldn't if you replaced "Tensorflow" with "C" and "Keras" with "Python". They operate on fundamentally different levels and provide a similar trade off in control/ease of use. We started using Keras for a project a few months ago, and it was great while it supported what we were doing. Once we needed to go outside of the box a little bit we essentially had to rewrite it in just Tensorflow. This is great news though! Hopefully it will make the barrier to entry much lower for getting started with Tensorflow.

taion 10y ago
I strongly recommend checking out TensorFlow-Slim if you're looking for a lightweight abstraction for using TensorFlow – at least the layers, anyway. The API looks similar to something like Keras or Lasagne, but the layers are just simple operations on tensors, so it integrates seamlessly with vanilla TensorFlow in a way that something like TF-Keras won't. At the same time, though, the layers are the same foundation that TF-Keras look like they'll use, so you get much of the same expressive power, but without sacrificing flexibility.
- AlexCoventry 10y ago
  > it integrates seamlessly with vanilla TensorFlow in a way that something like TF-Keras won't. Google also released prettytensor, which is designed to address the same problem. https://github.com/google/prettytensor https://github.com/google/prettytensor
- jph00 10y ago
  The Keras functional API are just simple operations on tensors too.
wodenokoto 10y ago
They are also comparing tf unfavourably to theano. Personally I've found a somewhat obscure low-level and (comparatively) little documented DyNet [[1] much easier to understand than tensorflow, so the critique rings true to me. [1] http://dynet.readthedocs.io http://dynet.readthedocs.io
- williamtrask 10y ago
  +1 for DyNet. Chris Dyer is a boss (and just moved from Carnegie Mellon to DeepMind)
jph00 10y ago
> This doesn't feel fair to say, just like it wouldn't if you replaced "Tensorflow" with "C" and "Keras" with "Python". They operate on fundamentally different levels and provide a similar trade off in control/ease of use. That's a valid point. But I'd still like to see Tensorflow improve on a few areas. In particular, the documentation and overall marketing/positioning. For instance, the Udacity course and the Tensorflow tutorials do not make it at all clear that Tensorflow is the low level plumbing that you only need if you really have to customize the algorithms or build new ones. Furthermore, the API really is over-complex, and the docs and tutorials tend to show the full complexity when much simpler approaches exist. I'd like to see context managers, scope, sessions, and explicit graphs disappear from all but the most advanced documentation - show us how to build in Tensorflow without all that cognitive overhead (and indeed, it can be done!) Tensorflow's defaults are unfriendly too. For instance, grabbing all available memory on all of your GPUs is unexpected and unhelpful. Open up another Jupypter Notebook tab and you've got a nasty error message coming up... > We started using Keras for a project a few months ago, and it was great while it supported what we were doing. Once we needed to go outside of the box a little bit we essentially had to rewrite it in just Tensorflow. I'm surprised to hear that - I've found it so much easier to implement parts in Tensorflow or Theano and then call them from Keras. Trying to reimplement all the DL best practices from scratch in Tensorflow is a huge amount of work and hard to get right first time (e.g. handling dropout in RNNs correctly), and you still end up with an API that's less elegant than what Keras already provides. Why did you find you needed to rewrite in TF rather than integrate with Keras?
- vrv 10y ago
  wrt GPU memory: If we made InteractiveSession by default grow memory, would that work for you? Seems sensible to change the default for InteractiveSession (e.g., for use in notebooks), but not the default for Session (production training / inference) due to the potential memory fragmentation.
  - vrv 10y ago
    (I made this change anyway).
- 10y ago

taion 10y ago

I strongly recommend checking out TensorFlow-Slim if you're looking for a lightweight abstraction for using TensorFlow – at least the layers, anyway. The API looks similar to something like Keras or Lasagne, but the layers are just simple operations on tensors, so it integrates seamlessly with vanilla TensorFlow in a way that something like TF-Keras won't. At the same time, though, the layers are the same foundation that TF-Keras look like they'll use, so you get much of the same expressive power, but without sacrificing flexibility.

AlexCoventry 10y ago
> it integrates seamlessly with vanilla TensorFlow in a way that something like TF-Keras won't. Google also released prettytensor, which is designed to address the same problem. https://github.com/google/prettytensor https://github.com/google/prettytensor
jph00 10y ago
The Keras functional API are just simple operations on tensors too.

wodenokoto 10y ago

They are also comparing tf unfavourably to theano. Personally I've found a somewhat obscure low-level and (comparatively) little documented DyNet [[1] much easier to understand than tensorflow, so the critique rings true to me. [1] http://dynet.readthedocs.io http://dynet.readthedocs.io

williamtrask 10y ago
+1 for DyNet. Chris Dyer is a boss (and just moved from Carnegie Mellon to DeepMind)

jph00 10y ago

> This doesn't feel fair to say, just like it wouldn't if you replaced "Tensorflow" with "C" and "Keras" with "Python". They operate on fundamentally different levels and provide a similar trade off in control/ease of use. That's a valid point. But I'd still like to see Tensorflow improve on a few areas. In particular, the documentation and overall marketing/positioning. For instance, the Udacity course and the Tensorflow tutorials do not make it at all clear that Tensorflow is the low level plumbing that you only need if you really have to customize the algorithms or build new ones. Furthermore, the API really is over-complex, and the docs and tutorials tend to show the full complexity when much simpler approaches exist. I'd like to see context managers, scope, sessions, and explicit graphs disappear from all but the most advanced documentation - show us how to build in Tensorflow without all that cognitive overhead (and indeed, it can be done!) Tensorflow's defaults are unfriendly too. For instance, grabbing all available memory on all of your GPUs is unexpected and unhelpful. Open up another Jupypter Notebook tab and you've got a nasty error message coming up... > We started using Keras for a project a few months ago, and it was great while it supported what we were doing. Once we needed to go outside of the box a little bit we essentially had to rewrite it in just Tensorflow. I'm surprised to hear that - I've found it so much easier to implement parts in Tensorflow or Theano and then call them from Keras. Trying to reimplement all the DL best practices from scratch in Tensorflow is a huge amount of work and hard to get right first time (e.g. handling dropout in RNNs correctly), and you still end up with an API that's less elegant than what Keras already provides. Why did you find you needed to rewrite in TF rather than integrate with Keras?

vrv 10y ago
wrt GPU memory: If we made InteractiveSession by default grow memory, would that work for you? Seems sensible to change the default for InteractiveSession (e.g., for use in notebooks), but not the default for Session (production training / inference) due to the potential memory fragmentation.
- vrv 10y ago
  (I made this change anyway).
10y ago