The programming assignments were one or two lines in Octave. They'll turn into 10 lines of Python with indentation errors. Python is a worse pedagogical language for any course in applied linear algebra.
OTOH, the time I spent learning Octave/Matlab for Andrew Ng's course was 100% wasted time, because I've never used it again in the 10+ years since I took the class, whereas time spent learning Python would've been useful to me in myriad other ways.
So sad to hear Mariah disparaged. I’m an Gen X engineer and Matlab is one of our first languages. Use it today still in aerospace but I would imagine Python suits software shops much better. Does Python handle matrix math as well?
If you're playing around interactively, it's a bit easier to write (in Matlab)
m = [1 0 0 ; 0 0 -1 ; 0 1 0]
than (in Python)
m = np.array([[1, 0, 0], [0, 0, -1], [0, 1, 0]])
Also a bit longer example:
m = rand(3,4)
a = [0.1 0.2 0.3]
m \ a'
versus
m = np.random.rand(3,4)
a = np.array([0.1, 0.2, 0.3])
np.linalg.lstsq(m, a.T)
wtf?
google...
fine!
a = np.array([[0.1, 0.2, 0.3]])
np.linalg.lstsq(m, a.T)
But if you're developing software, you can't really easily and reliably deploy Matlab or Octave to run in the cloud in your production systems, whereas Python you can.
Matrix math in python is a bit clunkier, because matrices are not native to the language. That said, numpy, the standard for matrix math in python, is quite nice. Its documentation is, imo, miles ahead of matlab's and the APIs are a bit more sane.
This brings up a good point. If the goal is to understand the underlying concepts, it's quite possible Octave is a better tool. Matrix math is fairly clunky in any mainstream programming language.
It's fairly common I have a little dataset I need to do some fft's on and draw a graph or some other similar one-off task. MATLAB still wins for getting the job done.
I wish someone would make "MATLAB with all its toolboxes, but with python syntax, in a colab-like IDE".
Is that not what numpy/scipy with Jupyter (as well as the various distributions that package them) essentially provide? If you just want an all-in-one that has a supported Matlab FFI interface, there's Julia.
The programming assignments in the original course were mostly useless. They provided you with a template with 90% of the problem solved, and you just had to enter an equation to solve the problem.
> But you also had to understand the rest of the code in the template.
Not really. They had lots of comments that explained what the code did. You didn't need to read most of the code.
My point is that compared to real university courses, the HW in this course would be labeled as "trivial". Writing those few lines of code was no more instructive than an in class paper test. It's more comparable to answering simple questions than building anything.
I don't think I had to debug even once in that course. It was that easy.
I mean python has issues (indentation errors isn't one I would list) but that's besides the point isn't it. The Lingua Franca for ML is currently python. Teaching octave, when most things they search for will be python just seems unnecessarily stubborn. Some day it might be Julia but we aren't there yet.
Indentation errors are a big problem for pedagogy. Imports are a big problem for pedagogy. When you are teaching how algorithms work, you want to implement in a language as close as possible to the language of the domain as possible. Hence, Python is a terrible pedagogical language for linear algebra, and Octave is a reasonable language.
1) Python is the lingua franca for ML. You WILL need to learn python. All other resources are in python. Matlab you'll likely never use again, so it's kind of a waste.
2) Probably more people have existing python knowledge than Matlab knowledge. And if you already know python, and you know python is the lingua franca, it's annoying having to learn Matlab knowing that in the real world you'd be better off with python.
1. You'll use Matlab in any other linear algebra or numerical methods course as well as in any digital signals course.
2. Optimization algorithms, of which gradient descent is a subset, are deployed in production in many languages, very often not Python.
3. There is almost nothing to learn. For the programming assignments in the course, Octave is used as a succinct DSL for matrix math. The assignments were to simply write the math in a computer and watch what happens when you run the computations.
4. You wouldn't learn Python by completing the programming assignments because you're just calling numerical routines, not dealing with anything else. Writing the code in Python simply adds more opportunity for error with no pedagogical benefit.
Octave is an easy language for beginners and has excellent (less ceremony than numpy) support for linear algebra out of the box without having to learn any libraries. The point of the class isn't to teach you how to use libraries but to teach you at a high level how to use gradient descent to optimize parameterized models. Once you understand how it works, it is easy to translate what you know to run well on different systems or to use existing frameworks already implemented on different systems.
Numpy is kind of a funky library with some weird (but good!) syntactic sugar that doesn't translate to the rest of Python. Scipy is a different beast. And pandas. I could go on. Making, and using matrices, feels weird in python and interoperability/efficiency doesn't come for free.
Compare to matlab, where matrices are first-class, syntactic sugar is consistent and rather lovely. But then the rest of the language is detestable.