Hacker News Reader

Just to illustrate:

Octave:

    m = [0 1 0; 0 0 1; 1 0 0]
    v = [2 3 1]'
    m\v
    
    ans =
    
       1
       2
       3

Python:

    import numpy as np
    m = np.array([[0,1,0],[0,0,1],[1,0,0]])
    v = np.transpose(np.array([2,3,1]))
    # wtf? oh, I guess then
    v = np.transpose(np.array([[2,3,1]]))
    np.linalg.solve(m,v)
    
    array([[ 1.],
           [ 2.],
           [ 3.]])

If you just want to play around, Python has more clutter and gotchas.

Of course, when you start to write real software, then the tools that Python provides for organizing your code start to weight more and the clumsiness of np.linalg.solve(m,v) over m\v starts to weight less.

But I can see how a 50-line testing script in Octave organically grows to a 2000-line application, and then it's already a lot of work to rewrite in Python.

Edit: a reply below makes a good point simplifying the Python code a little bit.

Why not just: v = np.array([2,3,1]).T

is there something wrong with numpys convenience method for transpose but not matlabs postfix unary convenience operator?

You are right, T would be nicer than np.tranpose. But the first google hit on 'numpy transpose' [1] doesn't give that as as example.

Also you too made the same mistake: np.array([2,3,1]).T doesn't do anything, you need np.array([[2,3,1]]).T

[1] https://docs.scipy.org/doc/numpy/reference/generated/numpy.t...

I think that's kindasorta of reason for Ng's preference: students will focus on the subject of machine learning and not spend time on the ins and outs of Python and Numpy (or these days TensorFlow). It's the same sort of pedagogical approach that keeps SML as an active teaching language.

When someone googles Matlab/Octave there won't be the same mixture of contexts as there is for Python. With Python there's "2 or 3?" before even starting. Than Cython or Jython or PyPy? That's nothing against Python except that in one particular time limited context, the questions are a distraction {without even considering the complaints of students when the choice of Python implementation is contrary to their opinion}.

How about Julia and R?

R:

    m = matrix( c(0,0,1,1,0,0,0,1,0), nrow=3 )
    v = c(2,3,1)
    solve(m,v)

    [1] 1 2 3

Julia: for this code snippet the syntax is identical to Matlab:

    m = [0 1 0; 0 0 1; 1 0 0]
    v = [2 3 1]'
    m\v

    3×1 Array{Float64,2}:
    1.0
    2.0
    3.0

What's wrong with:

    >>> import numpy as np
    >>> m = np.array([[0,1,0],[0,0,1],[1,0,0]])
    >>> v = np.array([2,3,1])
    >>> np.linalg.solve(m,v)

    array([ 1.,  2.,  3.])

No need to transpose, as numpy handles row and column vectors identically. Using the above variables `m` and `v`:

    >>> v @ m   # treated as row vector
    array([1, 2, 3])

    >>> m @ v   # treated as column vector
    array([3, 1, 2])

Where `@`, for those who don't know, is the matrix multiplication operator (`np.dot`) introduced in recent versions of python 3.

Sounds like a case of familiarity being confused for ease of use.

What's wrong with .... introduced in recent versions of python 3.

Exactly.

Python3 is ancient, can we stop pretending otherwise?

PEP 465 introduced the infix operator @: https://www.python.org/dev/peps/pep-0465/

Python 3.5 was the first version of python3 to implement the PEP: https://docs.python.org/3.5/whatsnew/3.5.html

If I am reading the release notes correctly, Python 3.5.0 was released last year (2015-09-13): https://www.python.org/downloads/release/python-350/

It's fair to say that this is a relatively new development.

It's true that infix multiply is new, but infix multiply if I'm not mistaken is not a breaking change.

True.

I mean in the context as @sampo described it above ...

In the Stanford/Coursera machine learning class, Andrew Ng said that his teaching experience is that students pick up octave/matlab quicker and the course can cover more actual machine learning, compared to python where more time is spent learning the language.

Then "which version of Python, and how is that different..." etc.

Code targeting Python 3.2 which was released five years code is still compatible with the latest versions of Python 3. What is the issue exactly?

There are still hundreds of projects that need to get ported to 3.x. http://portingdb.xyz

That link above seems to have broken. Here's an alternative link: https://portingdb-encukou.rhcloud.com/

here is sagemath

    m = matrix([[0, 1, 0],
                [0, 0, 1],
                [1, 0, 0]])
    v = vector([2, 3, 1])
    m \ v

(1, 2, 3)

and then

    sol = m \ v
    m * sol

(2, 3, 1)

I'll throw my experience onto the pile of anecdotes in support of Ng's opinion.

I've done both his Coursera class and another ML class that used Python. I started the one class with zero Matlab/Octave experience, and the other with some Python but no real Numpy experience.

Getting comfortable with Octave for doing basic vector/matrix operations took very little time, and within an hour I was able to just focus on learning the math. By contrast, I've been using Numpy on-and-off for a year now, and I still feel wedded to the reference manual.

Keeping track of all the @$@#% types is definitely a chore. There may be technical advantages to doing things that way, but that doesn't make it any more learner-friendly. Nor does the Python community's habit of not bothering to specify types in the documentation help things in that department.

I'm with you. When you are doing things as your day-to-day learning the syntax and gotchas associated with whatever language are pretty easy, but when you come at it every once in a while working with Octave or Matlab are so much easier.

I can see the benefit that tooling provides, but from a getting-started standpoint, reducing the complexity makes you significantly more productive. You can concentrate on learning the concepts and not the language nuances.

For someone who already knows and works with numpy or r, Octave might not be necessary. Then again, it's not like its particularly hard to pick up Octave and be able to work with it.

I took the EdX/MIT course[1] on optimization methods and constraint solvers using Julia and JuMP and it was really fun.

Julia wasn't around, or it was very early, when he designed the Machine Learning course or was teaching Stanford students, and he's moved on since then. I wonder if he would likely choose Julia now.

I like R, but understand that %*% for matrix multiplication, solve() instead of \, and the relatively cumbersome syntax for defining matrices indicate that it not designed primarily for users to interact with matrices at a lower, mechanical level. The xapply() functions can also be more confusing than picturing how you iterate through loops. Python too can be verbose for doing the simple/toy problems that are helpful when learning.

Julia however comes with the easy Matlab/Octave syntax for handling matrices. But then there is a lot of of syntactic sugar too after you get past the early stages. Even things like the built-in support for intermixing Greek letters were surprisingly helpful.

I think the advantage of Matlab is the toolboxes in engineering contexts, but that Julia has a similar learning curve for beginners working with matrices. Perhaps the Matlab IDE is an advantage, but that doesn't come with Octave, and Jupyter or Atom+Julia are relatively user-friendly.

[1] https://www.edx.org/course/optimization-methods-business-ana...!

I think he would choose julia. The loop unrolling in octave is unbearably slow.

Matlab and Octave have multidimensional arrays built in. Few modern languages do. C, C++, Python, Go, Rust - no built-in multidimensional arrays. (Arrays of arrays are not the same thing.) There are lots of array packages, but they often don't talk to each other. Classic Python gotcha: "+" for Python arrays is concatenation, but for NumPy arrays, it's elementwise add. Mixed-mode semantics are complicated.

Simply not having to worry about how to represent a multidimensional array is a win. This keeps FORTRAN alive.

"Matlab and Octave have multidimensional arrays built in. Few modern languages do. C, C++, Python, Go, Rust - no built-in multidimensional arrays. (Arrays of arrays are not the same thing.)"

What is the difference? I was thinking about this just recently (in connection with Python and C). But not clear on the diff (for either language), though I know that internally all arrays have to be represented as 1D sequences of bytes in memory, and the translation betwen 1D and say 2D (for 2D arrays) is done by adding and multiplying indices, offsets, etc. Is there any more to it than that? Interested to know.

There are performance, and in some languages, safety issues with arrays of arrays. Arrays of arrays can be ragged - not all the rows need be the same length. Languages which do subscript checking have to deal with this, and usually can't hoist subscript checks out of inner loops.

Allocating an array of arrays can require a lot of allocations, as does copying such an array. This gets expensive if you have some language where arrays are first-class result types. You can't just do one allocate, then copy the entire array.

The C idiom "a[i][j]" has become pervasive, replacing actual multidimensional array subscripts such as "a[i,j]" (Pascal, Modula) or "a(i,j)" (Octave, MATLAB and FORTRAN). Amusingly, you can't overload "operator[]" in C++ with more than one argument. It's a syntax problem. The comma operator (the "evaluate but ignore first operand, return second operand" operator) has higher precedence inside "a[]" than inside "a()". This is a legacy from C's use of the comma operator inside macros.

In the Stanford/Coursera machine learning class, Andrew Ng said that his teaching experience is that students pick up octave/matlab quicker and the course can cover more actual machine learning, compared to python where more time is spent learning the language.

This seems to be a special case of teaching a course where the students come from diverse backgrounds, having learned different programming languages or none at all. And in any course that involves some computer based activities, it's always good to avoid the situation where fussing with the tools overshadows the content that's being taught.

In this case, a language whose notation mimics the notation being used to describe the math on the chalkboard, is certainly handy. And I appreciate that he's offering a way to do the work without requiring a commercial or platform-specific tool.

I'm not sure it means that Octave is nicer in general, but I can certainly see the appeal if it's well integrated into a well designed course.

You are exactly right about the pros and cons of Python. It is a general-purpose language that introduces frictions that paying for by around 1000 loc.

But MATLAB not perfect, it has spiky bits and traps for newbies. (And the feature that '' == matrix multiply != the multiplication you almost always want is one of those traps). Also students will* write complicated (perhaps overcomplicated) programs that expose MATLAB's limits.

So what about other languages designed for numerics? Would R be a better choice (I haven't used it). Or maybe a new language should be invented. After all Matlab might be easier overall, but it still has plenty of stupid spiky stuff. And I would count your multiplication example as one of the (milder) stupidities.