Vector vs Column vector

New to Julia
1

I can’t wrap my mind around the following:

a=[ 2 4]; b = [3; 6]; c = a*b

a is a row vector (matrix)
I expected b to be a column vector: it is a vector, though,
so the computation of c=a*b fails.

How should I think about this? I had expected to get a matrix c of size 1x1

2

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

1 Like
3

That much I get.
What I don’t understand is why

a = [1 2] is a matrix
while
a=[1,2],
a = [1
      2] and
a =[1;2] are vectors?
4

[x,y] constructs a vector of two elements, x and y. This is true even if you put an array inside:

julia> [[1,2], 3]
2-element Array{Any,1}:
  [1, 2]
 3

In contrast, ; concatenates:

julia> [[1,2]; 3]
3-element Array{Int64,1}:
 1
 2
 3

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 (Issues · JuliaLang/julia · GitHub).

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.

4 Likes
5

There are many discussions, eg

and there is

2 Likes
6

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.

1 Like
7

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.

3 Likes
8

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.

9

Here is why I am puzzled:

[ 1 2
  3 4 ]

yields 2×2 Array{Int64,2} a matrix.

[ 1
2 ]

yields 2-element Array{Int64,1} a vector

The only way I can imagine this to happen
is if the implementation goes out of its way to make the column vector (a matrix!) case
inconsistent.

Is it a failure of imagination on my part?

10

I’d quibble with sensible:

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

11

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.

If you wonder whether the Julia system is carefully thought out, I think you’ll really enjoy this video: https://www.youtube.com/watch?v=C2RO34b_oPM

3 Likes
12

Heading there now! :slight_smile:
And yes, I have become quite aware of the care taken with types and operations
(deprecations in Julia 0.7 to 1.0 make it obvious!)

1 Like
13

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…

And yes, too much pixie dust…

14

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.

2 Likes