Fastai: A Layered API for Deep Learning • Hacker News Board

Re: Fastai: A Layered API for Deep Learning

#41

Post by jszymborski » Fri, Feb 14, 2020, 7:56 PM UTC

dillonmckay wrote: post #23

jszymborski wrote: post #22

Earlier quoted context omitted.

For most cases, objects in the fastai framework inherit pytorch objects and are often rather thin. This means that you can usually roll your objects if the fastai ones aren't sufficient. This really help alleviate the feeling that you're "on rails" of the library. That being said, a current project I'm working on didn't really fit the fastai pipeline and I needed to drop into pytorch. It's a total shame since there a…

Can you go into more details on why pytorch was a better fit for your particular use-case? My coworker recently completed a bootcamp using pytorch, and I am working through the fastai course, so it has been interesting to compare experiences.

I'm training a semi-supervised task which consumes three text samples while training. In retrospect, I might have been able to concatenate them, and treat them as one, but as it was I wasn't able to implement some of the functions fastai's Databunch required.

Might give it another go if I decide to give it another refactor.

Re: Fastai: A Layered API for Deep Learning

#42

Post by dr_zoidberg » Sat, Feb 15, 2020, 1:52 PM UTC

jph00 wrote: post #39

dr_zoidberg wrote: post #35

Earlier quoted context omitted.

Ufff that's rough to read. Totally. The only one I agree with is the one that says: Aim to align statement parts that are conceptually similar. It allows the reader to quickly see how they’re different. E.g. in this code it’s immediately clear that the two parts call the same code with different parameter orders. That'd turn something like this: class OneClass: def __init__(self, a, b1, b2, c_long): self.a = a self.b…

It's certainly unpythonic - as the link explains, it's based on research that goes back many more decades than Python has existed, and that PEP 8 entirely ignored. But it only makes the code unreadable if you don't make a tiny effort to adjust. If you do make the effort, there's some great payoff, like this code: try: self._split(b); self('begin_batch') self.pred = self.model(*self.xb); self('after_pred') if len(self…

By looking at that code without knowing much of the context in which it works, I assume self('begin_batch') and the like are "signals" that set some state or are used for logging. That behaviour could be achieved using other mechanisms (perhaps some metaprogramming magic or an observer pattern).

And while I can appreciate it can be quick to see where the signals are sent, the use of ; and having two things in a line still aren't convincing me.

Even more, if I were to run the line_profiler here, I know it'd report weird numbers precisely for having more than one thing per line.

The other thing that I dislike is opening blocks and closing them in the same line. It may be force of habit for me, but that screams unreadability at my face.

Rounding up, all I see is behaviour that can be achieved through other mechanisms, and dev/tools unfriendliness. And notice I'm not sayin anything about PEP-8, because:

a) There are parts of it with which I don't agree either.

b) Many people use PEP-8 as a sort of "silver bullet" and argument-ending-remark. That's not what it should be, it should be a _guide_ to be used when it helps, and ignored sparingly (with reason and consideration of _why_ you decide to ignore it, in the sake of readability).

Re: Fastai: A Layered API for Deep Learning

#43

Post by dr_zoidberg » Tue, Feb 18, 2020, 6:14 PM UTC

claytonjy wrote: post #38

dr_zoidberg wrote: post #35

Earlier quoted context omitted.

Ufff that's rough to read. Totally. The only one I agree with is the one that says: Aim to align statement parts that are conceptually similar. It allows the reader to quickly see how they’re different. E.g. in this code it’s immediately clear that the two parts call the same code with different parameter orders. That'd turn something like this: class OneClass: def __init__(self, a, b1, b2, c_long): self.a = a self.b…

I've long wished black would do this!

While I appreciate what black can do (no more discussions about code style!) I am lucky enough that I manage a small team (2-5 programmers) that understand and follow the style convention we set.