From: telefunkenvf14 on 9 Jun 2010 07:20 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 10 Jun 2010 08:06 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 10 Jun 2010 08:08 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 11 Jun 2010 02:10 > 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 12 Jun 2010 05:32 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.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Using Nearest function Next: General question regarding solving equations |