Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Lists: Row Vectors vs. Column Vectors. (feels like such a silly

14 views
Skip to first unread message

telefunkenvf14

unread,
Jun 7, 2010, 8:08:01 AM6/7/10
to
Group:

I'm trying to understand the *reasoning* behind Mathematica's treatment of
lists, rows and columns. Basically, I feel like I'm in a weird place---
I get what's going on well enough to translate various econometric
examples, but I wouldn't be able to clearly explain Mathematica's behavior to
someone previously exposed to matrix programming in Gauss, SAS IML,
etc.

Can someone explain why a list does not display in MatrixForm as a
row?---It's ok if the answer is computer sciency. I'll take some advil
before I attempt to digest any answers. :)

-RG

Jagra

unread,
Jun 8, 2010, 7:06:39 AM6/8/10
to
{a,b,c,d} // MatrixForm
{{a,b,c,d}} // MatrixForm

The following doesn't work, because one can't transpose a one
directional object.

Transpose[{a,b,c,d}] // MatrixForm

The following as a matrix will transpose:

Transpose[{{a,b,c,d}}] // MatrixForm

Just some clues that help it all begin to make sense.

David Park

unread,
Jun 8, 2010, 7:08:30 AM6/8/10
to
What about:

vector = Range[5];
MatrixForm[vector, TableDirections -> Row]

(1 2 3 4 5 )


David Park
djm...@comcast.net
http://home.comcast.net/~djmpark/

Bill Rowe

unread,
Jun 8, 2010, 7:08:41 AM6/8/10
to
On 6/7/10 at 8:08 AM, rgo...@gmail.com (telefunkenvf14) wrote:

>Can someone explain why a list does not display in MatrixForm as a
>row?---It's ok if the answer is computer sciency. I'll take some
>advil before I attempt to digest any answers. :)

Because a 1D list is not defined as either a row nor a column.
An example of something that displays as a row in MatrixForm
would be

{Range[4]}

Alternatively, something that displays as a column in MatrixForm is:

List/@Range[4]

But note:

In[4]:= MatrixQ /@ {{Range[4]}, List /@ Range[4]}

Out[4]= {True,True}

That is, both of these constructs are seen as matrices by
Mathematica and displayed appropriately by MatrixForm.

Also, notice

In[5]:= a = Range[4];
b = RandomInteger[1, {4, 4}];

In[8]:= b.a

Out[8]= {3,1,8,7}

In[9]:= a.b

Out[9]= {10,5,3,7}

showing it is up to you to determine whether a 1D list should be
interpreted as a column vector or row vector.


Kevin J. McCann

unread,
Jun 9, 2010, 7:19:46 AM6/9/10
to
However,

a = Range[5]
a.a gives the dot product, but Transpose[a].a doesn't work. Since I do
this a lot, I agree with the sense of the original post that some of the
matrix/vector operations are not very user friendly.

Kevin

telefunkenvf14

unread,
Jun 9, 2010, 7:20:18 AM6/9/10
to

Thanks for the answers. To start with, I'll modify David Park's
reply:

In[1]:= vector=Range[5];
MatrixForm[vector,TableDirections->Row]
%//Dimensions

Out[2]//MatrixForm= (1 2 3 4 5)
Out[3]= {5}

Now the same thing with TableDirections->Column:

In[4]:= vector=Range[5];
xPrime=MatrixForm[vector,TableDirections->Column]
%//Dimensions

Out[5]//MatrixForm=
(
1


2
3
4
5
)

Out[6]= {5}

What's confusing is that the displayed (standard form) output in the
first case *looks like* a 1x5 matrix and the second case *looks like*
a 5x1. However, one cannot simply perform matrix operations on these
forms and get the expected output, as Mathematica simply maintains the
dimensions {5} assumption corresponding to the underlying list.

Further confusing is the fact that, if I click in the output cell and
hit space, Mathematica 'interprets the output to input'. If I follow
this by //Dimensions, I again get {5}. For comparison, if I now go to Insert-
>Table/Matrix->New->Matrix, I can create a StandardForm matrix that
*looks* identical, but clearly is not. (as following this new input
with //Dimensions gives the expected {5,1} or {1,5} result.

I guess what I wish Mathematica did (or was expecting Mathematica to
do) by default was have the TableDirections option, TableDirections->Row or
TableDirections->Column, automatically generate the same 5x1 or 1x5
structure. If I had to explain this behavior to new/prospective users,
I'd have difficulties--and that's the main reason I'm asking the
question, BTW. ("...things that look the same, may not, in fact, be
the same...")

Humbly: Perhaps this behavior could be improved upon--or would
altering the behavior break other functionality?

-RG

David Park

unread,
Jun 10, 2010, 8:06:10 AM6/10/10
to
There are two questions here. One is how does Mathematica display arrays and
the other is how do we do calculations with them? There are things that can
be done with the display of these objects, but I am going to skip over that
for the more interesting calculations.

Most users deal only with vectors and matrices and the Mathematica
conventions are a little confusing. But this is because they are designed to
handle arrays of any depth and there I think they are reasonable consistent.
Vectors, matrices and arrays of higher depth are all arrays and there is a
consistent method to calculate with them.

The Tensorial tensor calculus package has provision for going from tensor
index notation to Mathematica arrays and in the package we have an essay on
the relation between the two modes of calculation. Here are some notes from
the essay:

1) The Prime Rule for Products of "Tensor" Arrays in Mathematica:
S.T dots the lowest level of S with the highest level of T,
or equivalently
S.T dots the last level of S with the first level of T.

2) The Mathematica Transpose[T,{n1,n2,n3,...}] moves levels {1,2,3,...} to
levels {n1,n2,n3,...}. We will always want to move the contracted level to
the first or last level when doing Dot products and to the first two levels
when doing single array contractions.

3) If R, S, T,... are Mathematica tensor arrays, then their direct product
is given by Outer[Times,R,S,T,...]. This will produce a single Mathematica
array. The levels are in the same order as the levels in the successive
arrays.

4) The basic Mathematica command for contraction of the top two levels in a
single array T is Tr[T,Plus,2]. We will have to use Transpose on T to put
the contraction slots in the first two levels. We will have to repeat the
operation if we want to do multiple contractions.

So, for higher order arrays the calculations can be intrinsically
complicated. You have to remain level-headed, i.e., you have to keep track
of the levels in your arrays, manipulate them to the right positions for dot
products or contractions, and then get them back in the desired order for
your final result. Suppose you want to dot a vector with a 4th order array.
There are many different ways you could carry out the dot product (i.e.
contraction). You would have to rearrange (i.e. Transpose) the levels of the
array to get the one you wanted to contract into the first or last position,
and then pre or post multiply by the vector. The slight confusion over lists
and matrices and pre or post multiplication is only a small residue of this.

You see very few examples of this in standard textbooks because they always
stop before the intrinsic difficulty sets in.

The advantage of array calculations in Mathematica is that they are pretty
darn efficient. But the difficulty with matrices and arrays is that they
drop context information. Was that defined by rows or columns? When we
multiply by a vector are we supposed to use the matrix or its transpose? Or
maybe the inverse? It's easy to get mixed up. One of the great advantages of
tensor calculus and its notation is that context information is carried
along, both in the tensor label and the symbols and positions used for the
indices. Usually you just have to get things lined up properly and it will
be right.

Another approach to handling this "linear algebra" aspect of problems is
Grassmann algebra, or geometric algebra or Clifford algebra. Here, instead
of indices for notation, the context information is carried along with
explicit basis elements. A nice implementation of this (still in development
but substantially useful in its present state) is John Browne's
GrassmannAlgebra Mathematica package.

http://sites.google.com/site/grassmannalgebra/


So, the upshot of all this is that doing algebra with arrays and the
underlying applications are intrinsically difficult (but I think there is
also a certain beauty to it all) and the textbook examples of matrices and
vectors trick us into thinking it is much less than it is.

From: telefunkenvf14 [mailto:rgo...@gmail.com]


Bill Rowe

unread,
Jun 10, 2010, 8:08:51 AM6/10/10
to
On 6/9/10 at 7:20 AM, rgo...@gmail.com (telefunkenvf14) wrote:

>On Jun 8, 6:08 am, Bill Rowe <readn...@sbcglobal.net> wrote:
>>On 6/7/10 at 8:08 AM, rgo...@gmail.com (telefunkenvf14) wrote:

>>>Can someone explain why a list does not display in MatrixForm as a
>>>row?---It's ok if the answer is computer sciency. I'll take some
>>>advil before I attempt to digest any answers. :)

>>Because a 1D list is not defined as either a row nor a column. An
>>example of something that displays as a row in MatrixForm would be

>>{Range[4]}

>>Alternatively, something that displays as a column in MatrixForm is:

>>List/@Range[4]

>>But note:

>>In[4]:= MatrixQ /@ {{Range[4]}, List /@ Range[4]}

>>Out[4]= {True,True}

>>That is, both of these constructs are seen as matrices by
>>Mathematica and displayed appropriately by MatrixForm.

>>Also, notice

>>In[5]:= a = Range[4]; b = RandomInteger[1, {4, 4}];

>>In[8]:= b.a

>>Out[8]= {3,1,8,7}

>>In[9]:= a.b

>>Out[9]= {10,5,3,7}

>>showing it is up to you to determine whether a 1D list should be
>>interpreted as a column vector or row vector.

>Thanks for the answers. To start with, I'll modify David Park's
>reply:

>In[1]:= vector=Range[5]; MatrixForm[vector,TableDirections->Row]
>%//Dimensions

>Out[2]//MatrixForm= (1 2 3 4 5)
>Out[3]= {5}

>Now the same thing with TableDirections->Column:

>In[4]:= vector=Range[5];
>xPrime=MatrixForm[vector,TableDirections->Column] %//Dimensions

>In[4]:= vector=Range[5];
>xPrime=MatrixForm[vector,TableDirections->Column]
>%//Dimensions
>
>Out[5]//MatrixForm=
>(
>1
>2
>3
>4
>5
>)
>Out[6]= {5}

>What's confusing is that the displayed (standard form) output in the
>first case *looks like* a 1x5 matrix and the second case *looks
>like* a 5x1.

Right. That is the point of MatrixForm. It puts a wrapper around
the list and causes it to *display* (look like) what you want.
But MatrixForm in no way makes the list a column or row vector.

While I also prefer the appearance of matrices displayed by
MatrixForm, I never use MatrixForm. Instead, I have my
preferences set to display output cells in TraditionalForm. That
way, something that displays as a 5 x 1 array is a 5 x 1 array.


telefunkenvf14

unread,
Jun 11, 2010, 2:10:00 AM6/11/10
to
> Right. That is the point of MatrixForm. It puts a wrapper around
> the list and causes it to *display* (look like) what you want.
> But MatrixForm in no way makes the list a column or row vector.
>
> While I also prefer the appearance of matrices displayed by
> MatrixForm, I never use MatrixForm. Instead, I have my
> preferences set to display output cells in TraditionalForm. That
> way, something that displays as a 5 x 1 array is a 5 x 1 array.

Bill:

I seem to recall reading (a few months ago) that you always displayed
your output in traditional form---and I actually took your advice and
tried it for a while. (Can't remember exactly why I switched back to
StandardForm i/o only... probably something to do with copy/paste
ambiguities.)

Anyways, I suppose I would have stuck with it if there were a way to
make *just* the matrix-related output display TraditionalForm. Man,
I'm picky! :) (and I can't imagine that such a tweak would be easy.)

Related (and NOT an attack on TraditionalForm i/o; just an observation
I thought I'd share): This last semester I taught with Mathematica for the
first time, and I'm a little mixed on the way that students are
encouraged to use the input palettes and change their input/output to
TraditionalForm (encouraged by WRI screencasts). I think this route
caused more confusion/frustration than it was worth and slowed
students' progress in learning to program and debug.

-RG

Kevin J. McCann

unread,
Jun 13, 2010, 4:12:36 AM6/13/10
to
Try this:

$Post := (If[MatrixQ[#] || VectorQ[#], MatrixForm[#], #] &)

This only affects the way the output looks when displayed.

Kevin

telefunkenvf14

unread,
Jun 22, 2010, 6:59:52 AM6/22/10
to

(Below my response is an email Fred Simons sent me. I figured I'd
include it for the benefit of others; you may want to read it before
reading my reply.) If short on time, *at least read point 2 at the end
of my post.*

Fred and the rest of the Group:

This discussion has been extremely helpful. Your replies prompted me
to review materials on Euclidean spaces=85 here is a simple explanation
to my formerly-confused self:

-----------
'Vector' is a term used widely throughout mathematics and does not
always have the same *intended* meaning. Ideally, to avoid confusion
later on, we should teach matrix algebra by always referring to
dimensions; a 1xn matrix, rather than calling it a row vector, and
an mx1 matrix, rather than saying it's a 'column vector'.

In general, a vector is just an ordered list of objects in some n
space, such as R3, for example. *There's no reason to force such a
concept into row or column form!*
-----------

Two remaining things I'd like to say:

1. I now feel a sense of frustration at the above lazy language in
matrix algebra. It seems like a classic example where trying to make
the material easier for a student to understand/visualize, actually
ends up paving an intellectual cul-de-sac.

2. I'm still absolutely right about one thing: Mathematica needs to have a
consistent way to programmatically create a matrix----that both
*looks* like a matrix in StandardForm and *behaves* like one. What I
mean is: On screen formatting and behavior just like Insert->Table=
/
Matrix=92->=92 New=92->=92Matrix=92. It seems logical that such a function =
would
have the head Matrix, given that it's conveniently available for use
in Mathematica. Now, does anyone want to whip up a frontend token to do this,
and pass it along to their favorite contact at WRI? :)

I suppose a variant of Kevin's code would also work---BTW Kevin,
thanks for teaching me the $Post trick.

-RG

PS - I also think Column[] should be ColumnForm (looks like there's
some back and forth on this) and Row[] should be RowForm[]. Or, at the
very least, let these definitions shadow one another, along with a
hard-to-miss warning in the documentation about the Mathematica convention
that xxxxForm[] is for formatting only. Not including 'Form' in Row[]
and Column[] makes it too easy to gloss over their intended use.

----------- Message from Fred Simons to RG----------------------------------

Hello,

Some time ago you asked the above question in mathgroup. It happens to
be a topic which I always treat in my introductory courses on
Mathematica, so I followed the discussion with some interest. Now that
the discussion seems to be at an end, I have the feeling that you did
not get a very clear reply to your question about why Mathematica
behaves like it does.

The answer to that is just mathematics. In mathematics we have the
concept of a vector, often, but by no means always, a list of numbers,
and the concept of a linear mapping of a vector space. Linear mappings
of finite dimensional vector spaces can be described with matrices. So
in mathematics, and therefore in Mathematica, vectors and matrices are
different objects. (Kevin McCann to whom I sent a similar message,
replied to me that he completely disagrees, for him a vector is a one
row matrix. i.e. a row vector. When his definition holds, then the
transposed of a row vector, i.e. a column vector, is not a vector,
because usually it has more than one row. His identification of a
vector with a one row matrix is definitely not standard in
mathematics.)

Also the concept of inner product has nothing to do with matrices. For
two vectors in Euclideam space it can be defined as the product of the
two lengths and the cosine of the angle, etc.

So, completely in accordance with mathematics, Mathematica uses single
lists for vectors and double lists (the list of rows) for matrices.
There is a very general function Dot, that has a.o. the following
properties:

vector . vector gives a scalar, the inner product.
matrix . vector gives a vector
vector . matrix gives a vector
matrix . matrix gives a matrix, the matrix product
and we can go on to tensors in general.

What has this to do with row and column vectors? Actually, the
question is: what is a row vector and what is a column vector? Again,
mathematically it is simple. When you have a vector in a finite
dimensional space, you might think of this vector as a list of
coordinates. Now you can write down these coordinates in a lot of
ways: horizontally, vertically, diagonally, in a circle, and so on.
These are NOTATIONS for the vector, NOT THE VECTOR ITSELF. When we
write the coordinates horizontally, then we may see this as a matrix
of one row, incorrectly called a row vector. When we write the
coordinates vertically, we may see that notation of a matrix of one
column, incorrectly called a column vector. Obviously, transposing a
vector is impossible (consider the vector (2,5) in the plane, where in
the plane is the transposed vector?), but you can transpose the matrix
notation: the transposed of the row notation for a vector is the
column notation for the vector and conversely. This property enables
us to do a lot of vector computations as matrix computations. For
example, matrix . vector in Mathematica would be the matrix
multplication matrix . columnmatrix; the result is a column notation
for a vector and Mathematica returns the vector itself.

So this is behind it in Mathematica. For me as a professional
mathematician this is very natural. Computing an inner product as
vector . Transposed[vector] is for me absolute nonsense, since I
cannot transpose a vector. But using a row NOTATION for a vector, it
is one of the ways by which we can COMPUTE the inner product.

Therefore, Mathematica does not display a vector as a matrix, but as
long as you realize that a matrix is not a vector, you could define
your own matrix display for a vector.

I hope this is of some interest for you.

Kind regards,

Fred Simons
Eindhoven University of Technology

Bill Rowe

unread,
Jun 23, 2010, 1:53:32 AM6/23/10
to
On 6/22/10 at 6:59 AM, rgo...@gmail.com (telefunkenvf14) wrote:

>2. I'm still absolutely right about one thing: Mathematica needs to
>have a consistent way to programmatically create a matrix----that
>both *looks* like a matrix in StandardForm and *behaves* like one.
>What I mean is: On screen formatting and behavior just like

>Insert->Table/Matrix

If you allow for output to be displayed in TraditionalForm
rather than StandardForm, then Mathematica currently has the
ability to do exactly what you have described above. Note, it is
TraditionalForm not StandardForm that is designed display in the
way you would see it in text books. StandardForm is a
Mathematica standard designed to ensure unambiguous display.

The problem with TraditionalForm is an expression such as
f(x+y). Depending on context, this could be interpreted as the
variable f times the sum of x and y or a function f of the sum
of x and y. StandardForm avoids this ambiguity.

Both the menu item and input palette work fine with the display
of input cells set to StandardForm and generate a template that
looks like a matrix. However, I direct input of matrices quicker
by entering the appropriate braces from the keyboard rather than
selecting a menu item or a palette item with a mouse then
entering a matrix.

By setting the default input display style to StandardForm and
the default output display style to TraditionalForm, I am able
to easily enter stuff from the keyboard with a minimum of mouse
usage and have a result that matches what you see in a text
book. The only issue I've seen with this arrangement is
occasional issues when doing a copy/paste operation from an
output cell to a new input cell. But since these issues are
reasonably infrequent and I seldom need to perform such a
copy/paste operation, the additional effort needed to work
around these issues are not significant to me.

And if you set your default output display to TraditionalForm,
you will find you no longer have any need for MatrixForm.


0 new messages