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

PyTorch 1.0 is out

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: PyTorch 1.0 is out

#41

Post by logicchains »

irishcoffee wrote: post #40
umvi wrote: post #21

Earlier quoted context omitted.

I'm not sure how I feel about operator overloading. It starts out simple enough, but can lead to extremely confusing code. Take this snippet of an API call[1] that parses ISO strings to chrono::time_point using date[2]: std::istringstream in(iso_string); in >> date::parse("%FT%TZ", tp); At first glace my brain cannot comprehend the second statement. Why is there an input stream going into a function ? Is that even va…

I recently encountered code (at work no less) that overloaded the == operator. a.) It was not a const overload. b.) Inside said overload, it modified FOUR member variables. c.) The 'new' keyword was used twice inside said == overload. d.) I learned when gdb fails, to grep the codebase for the 'operator' keyword. I am not a fan of operator overloading. If the SW enginner in question had instead written a equals( rhs)…

Sounds like operator overloading isn't the real problem here. An function equals(T rhs) -> bool that calls new and modifies member variables still sounds pretty terrible; changing "==" to "equals" doesn't fix the problem.

Re: PyTorch 1.0 is out

#42

Post by goldsborough »

modeless wrote: post #20
htfy96 wrote: post #12

What surprised me most is the elegance of C++ API. Compared to its equivalence in Python, the C++ version is almost the same if we discard the "auto" keyword [0]. As mentioned in the doc, they put user-friendliness over micro-optimizations, which also proves the expressiveness of modern C++ (at least when they want to prioritize user-friendliness!) [0]: https://pytorch.org/cppdocs/frontend.html#end-to-end-example

Wow, this is cool. How complete is the API? Could you use it for research? Last I checked, the TensorFlow C++ API was missing all sorts of important stuff for building models and was basically only useful for loading models saved from Python.

It's very complete. We have many kinds of builtin Modules (rnns, conv{1,2,3}d, batchnorm etc.), optimizers, a data loader, a serialization format for checkpointing and similar things you need for training. My hope is that any model you can train in Python you can now also train in C++.

Re: PyTorch 1.0 is out

#43

Post by ritoune »

I've been using PyTorch, and the PyTorch 1.0 pre-release for a while now. I adore it but don't really want to write C++ backends in production.

Anyone want to start working on Golang bindings for C++ PyTorch?

Re: PyTorch 1.0 is out

#44

Post by emmelaich »

umvi wrote: post #21
usgroup wrote: post #18

Earlier quoted context omitted.

i picked up c++ for some gpu stuff with the arrayfire api... felt the same. firstly, modern c++ takes no time to learn if you come from java / c/ c# / etc. secondly, things like operator overloading and type inference make for pretty seamless apis. E.g. want to add matrices? auto C = A + B. A lot of things suck (closures, generator functions, first order functions all suck in c++), but oh my does it all run fast when…

I'm not sure how I feel about operator overloading. It starts out simple enough, but can lead to extremely confusing code. Take this snippet of an API call[1] that parses ISO strings to chrono::time_point using date[2]: std::istringstream in(iso_string); in >> date::parse("%FT%TZ", tp); At first glace my brain cannot comprehend the second statement. Why is there an input stream going into a function ? Is that even va…

But you're familiar with cin/cout right?

Same thing. Weird at first every C++ programmer should be familiar with it now.

I pronounce > as 'goes to' and 'comes from' or something similar.

Re: PyTorch 1.0 is out

#45

Post by stochastic_monk »

thosakwe wrote: post #36
htfy96 wrote: post #12

What surprised me most is the elegance of C++ API. Compared to its equivalence in Python, the C++ version is almost the same if we discard the "auto" keyword [0]. As mentioned in the doc, they put user-friendliness over micro-optimizations, which also proves the expressiveness of modern C++ (at least when they want to prioritize user-friendliness!) [0]: https://pytorch.org/cppdocs/frontend.html#end-to-end-example

Wow, that’s actually really awesome. I really missed a good languages-other-than-Python story in Tensorflow. Now I feel a little inspired to try out ML again...

I’m really excited to use it in C++. When it’s in Python, it becomes much harder to embed into other programs and is susceptible to Python version issues when sharing code.

This reduces barriers to use in addition to improving performance and portability.

Re: PyTorch 1.0 is out

#46

Post by grandmczeb »

shaklee3 wrote: post #39
usgroup wrote: post #18

Earlier quoted context omitted.

i picked up c++ for some gpu stuff with the arrayfire api... felt the same. firstly, modern c++ takes no time to learn if you come from java / c/ c# / etc. secondly, things like operator overloading and type inference make for pretty seamless apis. E.g. want to add matrices? auto C = A + B. A lot of things suck (closures, generator functions, first order functions all suck in c++), but oh my does it all run fast when…

Why do closures suck? What are they missing?

I’m confused about that too - closures are one of the nicer parts of C++ imo.

Re: PyTorch 1.0 is out

#47

Post by umvi »

emmelaich wrote: post #44
umvi wrote: post #21

Earlier quoted context omitted.

I'm not sure how I feel about operator overloading. It starts out simple enough, but can lead to extremely confusing code. Take this snippet of an API call[1] that parses ISO strings to chrono::time_point using date[2]: std::istringstream in(iso_string); in >> date::parse("%FT%TZ", tp); At first glace my brain cannot comprehend the second statement. Why is there an input stream going into a function ? Is that even va…

But you're familiar with cin/cout right? Same thing. Weird at first every C++ programmer should be familiar with it now. I pronounce > as 'goes to' and 'comes from' or something similar.

Of course. But what I'm not used to is seeing something like this:

   cin >> foo(x);

Re: PyTorch 1.0 is out

#49

Post by Fede_V »

nwallin wrote: post #33
umvi wrote: post #21

Earlier quoted context omitted.

I'm not sure how I feel about operator overloading. It starts out simple enough, but can lead to extremely confusing code. Take this snippet of an API call[1] that parses ISO strings to chrono::time_point using date[2]: std::istringstream in(iso_string); in >> date::parse("%FT%TZ", tp); At first glace my brain cannot comprehend the second statement. Why is there an input stream going into a function ? Is that even va…

> Why is there an input stream going into a function ? The function is constructing a temporary object and reading into that object . The object includes a reference to a named tp object, and the temporary parser object is parsing from the input stream, which writes the data into the tp object. > but... I still don't understand all of the technical reasons behind that decision. Because he wants to support input from…

Thanks for explaining that design logic a lot more clearly. I figured out what the code did, but understanding the why was very helpful.

Re: PyTorch 1.0 is out

#50

Post by metahost »

ritoune wrote: post #43

I've been using PyTorch, and the PyTorch 1.0 pre-release for a while now. I adore it but don't really want to write C++ backends in production. Anyone want to start working on Golang bindings for C++ PyTorch?

Curious, can SWIG[1] help automate the process?

[1]: http://www.swig.org/

Post reply on HN