Actually @parrt knows everything. About everything.
Good morning @jeremy , it seems you havenāt wikified this topic.
Thatās a useful skill to have.
Iām situated in India but for anyone in NYC, @sgugger is presenting āAn infinitely customizable training loop using fastaiā at the PyTorch NYC meetup tomorrow.
Edit: It will be recorded too
Iāve asked the pytorch team this question - Iāll let you know what I find out.
I sure hope so - but Iām leaving tasks like this up to you all! Thatās why the top post is wikified, so that you can add your list of homework items to it, and others can fill in anything you missed. So maybe you could add you homework notes there now, and hopefully other folks can help tooā¦
This was discussed in detail in part 1, so it might be a good idea to revise that part of the course.
Python doesnāt actually implement @
at all. There is no builtin or stdlib implementation of it in pure Python. Itās an unusual operator, in that itās defined by Python, but not implemented by it.
I feel quite the opposite about Excel - thereās a small number of foundational ideas that can take you a really long way.
However, I first learned Excel over 25 years ago so I have no idea what the best resources are for learning those foundational ideas now. If anyone has suggestions, Iād love to hear them!
My guess is 3-4 years. But it depends on the momentum that gets generated early on. If lots of folks at Google and in the fast.ai community get behind it, then others follow, it could be faster.
Swift for Windows is just getting some traction over on the official Swift forums. Itās too early to be usable at this stage, but it looks like itās moving fast.
Oops! Fixed now
I read attentively both posts : https://www.fast.ai/2019/03/06/fastai-swift/ and https://www.fast.ai/2019/01/10/swift-numerics/
In my opinion, the main issue is related to the decades old compiled vs interpreted languages debates.
In the numerical and differentiable programming context, Swift apparently looks like a possible winner over Julia.
I am absolutely biased by my alma mater C++ which I taught and used during a MS internship, before my med studies at the end of the last century. At that time assembly was the ācomplexā language and C++ the simple compiled, general purpose, but high level language. The main argument mentionned by @jeremy to support Swift over let say C++ is relative simplicity. But should we also balance, as some people indirectly underlined in this thread for Swift, portability ? And, is C++ really more complex than Swift to use/learn ?
I don`t have any answers to my own questions and, after reading tens of thousand of medical images, I am way too outdated on this side to have an informed opinion. But the posts still revived the old school C++ engineer ā¦
Very interesting, please post the link!
I like this video by Joel Spolsky https://www.youtube.com/watch?v=0nbkaYsR94c
Thatās exactly right. Jeremy recommends similar things in his earlier lecture. When he meant overfitting, I would assume that the model should be able to predict correctly for most of the training data. If not then I would end up check my underlying data.
Many things you can do with swift you are able to do with C++ templates, but templates were hard maintain, debug and understand. Besides Swift is simple enough so you can add the automated back propagation to the compiler it self there were some issues with more complex languages. I guess @mkardas remembers the details. Besides it being simple to use and understand swift has jupyter notebook support and builtin reference counting no need clog your code with smart_ptr everywhere.
So it sounds like an easier choice this days. But I wasnāt using C++ for 10years as well so maybe I missed some things.
haha. Which latex? The matrix calculus Jeremy and I did? Boy that took a while to type in and get right. lots of typos fixed by viewers. The best part of that document is the mechanism to generate SVG embedded latex images into html. The standard javascript mechanisms failed with all that math and are hyper slow for 600 equations in a single doc.
Just a random bit of info:
In todays notebook matplotlib is imported as mpl, just to set the rcParams, I have seen that used before.
It is not neccessary to do so, you can set the rcParams on plt, too. Saves you one line of imports
Thanks - Iāll change that in the notebooks. I took mpl
from the example in the matplotlib docs, but when I did I vaguely thought that it shouldnāt be necessary, but never got around to checkingā¦