Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eager Execution: An imperative, define-by-run interface to TensorFlow

research.googleblog.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#13

Post by make3 »

chrisprobert wrote: post #5

Announcing TensorFlow's new development roadmap mandate: copy everything PyTorch is doing :-)

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 to TensorFlow

#16

Post by ychujo2 »

chrisprobert wrote: post #5

Announcing TensorFlow's new development roadmap mandate: copy everything PyTorch is doing :-)

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 to TensorFlow

#17

Post by bradleyjg »

ychujo2 wrote: post #16
chrisprobert wrote: post #5

Announcing TensorFlow's new development roadmap mandate: copy everything PyTorch is doing :-)

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.

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 to TensorFlow

#18

Post by chrisprobert »

bradleyjg wrote: post #17
ychujo2 wrote: post #16

Earlier quoted context omitted.

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.

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.

Totally agree!

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#19

Post by petewarden »

sandGorgon wrote: post #10
alextp wrote: post #9

Earlier quoted context omitted.

Ah, I didn't know SavedModel didn't work in android. I think freezing is still the way to go there? I'm sorry, I don't personally work on the mobile side of things.

I should apologize for hijacking this thread(and i'll stop here). But Tensorflow is getting to be unusable because of the serialization story. We don't have such issues on Caffe2 or anywhere else. It essentially means different parts of the tensorflow ecosystem are unable to talk to each other. I really pray the tensorflow teams give it due importance.

I'm the original author of the freeze_graph script, so I'm to blame for a lot of the on-going mess here. For what it's worth I'm actively working on cleaning this up, since I know what a painful experience it is. Apologies for everyone who's struggled with this, and I will take a look at the case number mentioned above and follow up internally to see if there's anything I can help with.

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#20

Post by congerous »

TensorFlow: everything to all people.

Eager is actually not as innocent as "open-source projects borrowing the best parts from each other", as some commenters here suggest.

Google is attempting to dominate the machine-learning API and the Python ecosystem for scientific computing.

The company that controls the API influences which apps are built on it and how. Think about how Google bundled Android services on top of Android, and how that posed an existential threat to other companies. That's what's coming for TensorFlow. Many developers are too naive to realize it, or too short-sighted to care.

Post reply on HN