From: Kevin J. McCann on 13 Jun 2010 04:12 Try this: $Post := (If[MatrixQ[#] || VectorQ[#], MatrixForm[#], #] &) This only affects the way the output looks when displayed. Kevin telefunkenvf14 wrote: > 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 >
From: telefunkenvf14 on 22 Jun 2010 06:59 On Jun 13, 3:12 am, "Kevin J. McCann" <k...(a)KevinMcCann.com> wrote: > Try this: > > $Post := (If[MatrixQ[#] || VectorQ[#], MatrixForm[#], #] &) > > This only affects the way the output looks when displayed. > > Kevin > > telefunkenvf14 wrote: > > 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 (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
From: Bill Rowe on 23 Jun 2010 01:53 On 6/22/10 at 6:59 AM, rgorka(a)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.
First
|
Prev
|
Pages: 1 2 3 Prev: Using Nearest function Next: General question regarding solving equations |