From: telefunkenvf14 on
On Jun 8, 6:08 am, Bill Rowe <readn...(a)sbcglobal.net> wrote:
> On 6/7/10 at 8:08 AM, rgo...(a)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

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

From: David Park on
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(a)comcast.net
http://home.comcast.net/~djmpark/



From: telefunkenvf14 [mailto:rgorka(a)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



From: Bill Rowe on
On 6/9/10 at 7:20 AM, rgorka(a)gmail.com (telefunkenvf14) wrote:

>On Jun 8, 6:08 am, Bill Rowe <readn...(a)sbcglobal.net> wrote:
>>On 6/7/10 at 8:08 AM, rgo...(a)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.


From: telefunkenvf14 on
> 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

From: Bill Rowe on
On 6/11/10 at 2:10 AM, rgorka(a)gmail.com (telefunkenvf14) wrote:

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

I probably should have noted while I have my default output set
to TraditionalForm, I have the input set to StandardForm. Since
the most frequent copy/past operations I do are from one input
cell to another, this arrangement avoids copy/paste issues for
the most part. Occasionally, I find I want to copy/paste a
numeric value from an output cell to an input cell. At those
times, I see an additional step asking whether the pasted value
should be interpreted literally or not. The end result is one
extra step in the copy/paste operation. I do this so seldom,
I've never considered it an issue.

The only other issue I see with my arrangement is some outputs
have specialized functions I am not familiar with. Consequently,
the TraditionalForm isn't very useful to me. But this is easily
fixed by either using FullForm on the result or selecting the
output cell and changing it to either InputForm or StandardForm.
This gives me something I can easily lookup in the
DocumentationCenter or elsewhere to get more information on a
particular specialized function. Again, this doesn't happen all
that often. So, the additional steps haven't seemed onerous to me.

Keeping the inputs formatted as StandardForm solves one other
problem. That is it eliminates the need to figure out what key
strokes are needed to enter the particular symbol used in
TraditionalForm or needing to find an appropriate palette.