From: Kevin J. McCann on
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
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
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.