Octave:

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

    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.]])

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.

    >>> 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.])

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

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

Exactly.

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.

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.

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

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...

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}.

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

and then

    sol = m \ v
    m * sol

    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

    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

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 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.

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...!

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

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.

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.

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.

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.