you want dot(a,b) (which needs a using LinearAlgebra to be run first. The reason this fails is that there are multiple possible products which you could mean (inner or outer).

It might be occasionally useful to have a convenient way of constructing a literal n×1 matrix, and your syntax with the multi-line input is a potential way to signal that. I’m not sure this has been discussed, so if no one else chimes in you could try submitting an issue (https://github.com/JuliaLang/julia/issues).

so the computation of c=a*b fails.

Not for me:

julia> a=[ 2 4]; b = [3; 6]; c = a*b
1-element Array{Int64,1}:
30

That’s the sensible result: in the same way that a m×n array times a n×p array should give a m×p array, a m×n array times a n array should give a m array.

My recollection on the reason there’s no convenient syntax, despite many discussions and perfectly reasonable proposals, is that there just wasn’t consensus on which to use before Julia v1.0 was finalised. So unfortunately OP is correct that this is confusing, but won’t likely be changed any time soon.

That, and maybe the fact that while occasionally one does need nx1 matrices, this is not one of the frequent use cases, in contrast to other languages (eg Matlab, AFAIK). I recall needing this maybe twice in 5 years.

I am learning (for a course that require it) numpy, and actually find it more confusing… as there you may have column vectors, row vectors and… adimensional vectors!

In Julia they all are Array{T,N}. Then “vectors” are just aliases for column arrays (Array{T,1}), Matrix is an alias for an Array{T,2} (and a row vector is a matrix with only one row) and then you can have multidimensional arrays if you with.

As it is expected, they are initiated with a different syntax.

The definition of A x = b either considers x and b to be matrices (column vectors),
or requires a special definition of matrix times vector.

Silently adding or dropping a constant index might be convenient, but tends to lead to problems. Personally, I prefer explicit conversions in my codes.

One problematic statement are formulae such as \frac{u^t v}{v^t v} v (dropping two indices) instead of \frac{ u \cdot v }{ v \cdot v } v

There’s a completely well-defined notion of a vector (a one-dimensional object), and in the modern approach to linear algebra you basically define matrices as transformations operators for vectors in some suitable basis.

Silently adding or dropping a constant index might be convenient, but tends to lead to problems.

Back when I wrote everything in Matlab, those years were characterized by a series of mild annoyances of always having to worry about whether a was a row vector or a column vector, and sprinkling a(:) and a(:)' like pixie dust to fix problems. It’s a huge relief to have real one-dimensional objects.

Don’t know: RowVector to allow multiple dispatch to automatically apply an isomorphism to do a type conversion seems yet another kludge. Not as bad as MATLAB, perhaps…

A little late, but I think the discussion here is also relevant:

The best course of action seemed to give a better error message. I will probably work on such enhancement next week. I think it is reasonable that exist a convention that a vector is always assumed to be a column (in the case we need to decide to treat it as a row or as a column) but at the same time there is an specific type to represent a column of an N-dimensional array that is different from the just-a-single-dimension-aware-vector. I just think that, in the context of some matrix operations (eachrow in the link above), some methods would make more sense to return a matrix with some unitary dimensions instead following the pattern of always dropping unitary dimensions from methods returns.