Re: Lists: Row Vectors vs. Column Vectors. (feels like such a silly
- To: mathgroup at smc.vnet.net
- Subject: [mg110236] Re: Lists: Row Vectors vs. Column Vectors. (feels like such a silly
- From: "David Park" <djmpark at comcast.net>
- Date: Thu, 10 Jun 2010 08:06:15 -0400 (EDT)
- References: <hul8bp$ifh$1@smc.vnet.net> <17171576.1276084834857.JavaMail.root@n11>
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.
David Park
djmpark at comcast.net
http://home.comcast.net/~djmpark/
From: telefunkenvf14 [mailto:rgorka at gmail.com]
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