News for hackers. Stuff that matters.
Re:Eager Execution: An imperative, define-by-run interface t... by chrisprobert on Tuesday October 31, 2017 @03:06PM (#15595710)
Announcing TensorFlow's new development roadmap mandate: copy everything PyTorch is doing :-)
Re:Eager Execution: An imperative, define-by-run interface t... by ychujo2 on Tuesday October 31, 2017 @04:09PM (#15596132)
I think you mean Google is following the leadership of Chainer, like Facebook already does? PyTorch started as a Chainer fork. Its dynamic graph internals are all from Chainer.
Re:Eager Execution: An imperative, define-by-run interface t... by bradleyjg on Tuesday October 31, 2017 @04:30PM (#15596279)
This isn't art. There are no points for originality. If open source projects borrow the best parts from each other, that's a good thing.
Re:Eager Execution: An imperative, define-by-run interface t... by ychujo2 on Tuesday October 31, 2017 @07:08PM (#15597454)
It's not a bad thing. It's good for users. But give credit to the leaders in the field. If you make an iPod clone, you call it an iPod clone, not a clone of the Zume HD.

Chainer started it, was around years earlier, and it still has more users. So Google is not copying PyTorch, it's copying Chainer.

Re:Eager Execution: An imperative, define-by-run interface t... by arbie on Wednesday November 01, 2017 @06:34AM (#15600018)
Do you have a source for Chainer currently having more users than TensorFlow?
Re:Eager Execution: An imperative, define-by-run interface t... by Narew on Friday November 03, 2017 @04:55AM (#15617647)
Not more users than Tensorflow. But maybe more user than other dynamic deeplearning framework (PyTorch, Gluon, DyNet...)
Re:Eager Execution: An imperative, define-by-run interface t... by chrisprobert on Tuesday October 31, 2017 @04:53PM (#15596455)
Totally agree!
Re:Eager Execution: An imperative, define-by-run interface t... by ma2rten on Wednesday November 01, 2017 @12:11AM (#15598749)
This is the first time I am hearing this. I though pytorch was based on torch (like the name implies). Do you have a reference or more information?
Re:Eager Execution: An imperative, define-by-run interface t... by Narew on Friday November 03, 2017 @05:00AM (#15617665)
PyTorch use the same backend as torch (cutorch for GPU ...) But PyTorch use almost the same Python API than Chainer. On this point we can say PyTorch "copy" Chainer.
Re:Eager Execution: An imperative, define-by-run interface t... by tempw on Tuesday October 31, 2017 @06:42PM (#15597282)
Based on your reasoning PyTorch is copying TensorFlow static optimizations and production capability with JIT and ONNX then? I've seen many folks requesting an imperative API.

You can't please everybody, as if they listen or not to users people still complain. If both are making effort to improve themselves though, the community has only to benefit from this competitiveness.

Re:Eager Execution: An imperative, define-by-run interface t... by make3 on Tuesday October 31, 2017 @04:00PM (#15596064)
I'm usually against this type of framework baiting, but being a tensorflow guy myself & having just spent the week coding with pytorch full time.... this is basically identical to pytorch
Re:Eager Execution: An imperative, define-by-run interface t... by brittohalloran on Tuesday October 31, 2017 @09:00PM (#15598147)
What are the strengths and weaknesses of each? I've been using keras but planning on diving into a real deal framework next. Tensorflow is appealing for the momentum it has in the community, but pytorch looks easier to learn.

Doing image classification, object localization, and homography (given an input image, which of my known template images is matches it and in what orientation).

Re:Eager Execution: An imperative, define-by-run interface t... by alextp on Tuesday October 31, 2017 @10:22PM (#15598439)
I think Keras is a real deal framework. It provides a higher-level API than most other frameworks, but it has pretty sweet portability of models across frameworks and platforms and most research papers are implementable in Keras without too much trouble.
Re:Eager Execution: An imperative, define-by-run interface t... by Narew on Friday November 03, 2017 @05:05AM (#15617684)
In my opinion, the real deal with Pytorch or Chainer, there are similar than numpy API. So the learning curve is flat. The NN construction part and gradiant part are specific but all the glue is regular python unlike Keras, tensorflow ...
Re:Eager Execution: An imperative, define-by-run interface t... by solomatov on Tuesday October 31, 2017 @03:59PM (#15596052)
That's actually very good that they are copying good things from other frameworks.
Re:Eager Execution: An imperative, define-by-run interface t... by make3 on Tuesday October 31, 2017 @04:02PM (#15596074)
the question now is, are tensorflow eager's RNN as slow as pytorch's are?
Re:Eager Execution: An imperative, define-by-run interface t... by yablak on Tuesday October 31, 2017 @07:49PM (#15597762)
(I'm author of the TF rnn api & tf.contrib.seq2seq)

There's a lot of work being done on this specific part. If you have a standard RNN architecture you want to run, you can probably use the cudnn code in tf.contrib.cudnn to get a super fast implementation.

There is some performance work that needs to be done on properly caching weights between time steps of an RNN if you use a tf.nn.RNNCell. Currently if you want to implement a custom architecture, or a seq2seq decoder, or an RL agent, this is the API you would want to use. Several of the eager benchmarks are based on this API; so that performance will only improve.

I'm hopeful that for the next major release, we'll also have support for eager in tf.contrib.seq2seq.