Schrödinger's MatrixForm: feature or bug?

Question

Recently I noticed a peculiar behavior of MatrixForm that I failed to find a way to explain. Consider the following example:

a = {{1, 4}, {6, 9}} // MatrixForm;
a

My question is, after executing the code above, what is displayed in the notebook?

"That's simple! It's MatrixForm[{{1, 4}, {6, 9}}], notice you can't use this directly in evaluation!" Yeah, I thought so, until I tried:

"…OK, I know how to explain this. There's a number of functions whose output in the notebook is not the same as the one in the kernel, for example, Format:

Format[int[f_, x_]] := HoldForm@Integrate[f, x]
int[Sin[x], x]

"and MatrixForm is just another of them. " Good point, unless MatrixForm doesn't behave as follows:

So the output of MatrixForm in the notebook seems to exist as a combination of multiple states, it

1. becomes a List if you edit and execute it;
2. becomes a MatrixForm expression if you edit and press Ctrl+Shift+i;
3. remains in a superposition of List and MatrixForm if you don't edit and just press Ctrl+Shift+i and Ctrl+Shift+n alternately.

Another function that behaves like this is NumberForm:

NumberForm[Pi // N, 10]

There may be more.

Further check shows this behavior has been existing at least since v3.

How to understand this behavior? A feature, or a long standing bug?

If it's a feature, is it possible to reproduce this behavior with self-made function?

---

Mr. Wizard thinks this post is a duplicate of this post, but that post is really about another issue. Let's look at the example in that post:

  mat = {{1, 2}, {3,4}};
  mat // MatrixForm
  Head[%]

I've been aware of this behavior of MatrixForm long before I discovered the one mentioned in this question, but I don't find it unexpected at all, because as we can see, in this case the output displays as

Out[5] // MatrixForm

rather than a single

Out[5]

which suggests that, the expression stored in Out[5] is exactly a List, rather than a MatrixForm expression. So when we use % (which is short for Out[]), there's no doubt we'll obtain a List.

In a word, that question is about how expression wrapped by MatrixForm is stored in the Out variable, while mine is about how expression wrapped by MatrixForm exists in the front end, they're different, though the answer to my question turns out to be related to $OutputForms, too.

Answer 1

This is essentially a duplicate of this question:

1. When typesetting as output, MatrixForm[_?ArrayQ] will display matrix-like.
2. In an output cell, Convert To StandardForm will default to box formatting, so you go back and forth between a matrix-like state and an InputForm-like state.
3. Once you edit the cell becomes an Input cell, so now MatrixForm will use an input-form like state for Convert To StandardForm.

So what's going on with that TagBox, and how does ToExpression@ToBoxes@... produce a list? Well, normally the second argument of a TagBox, in the absence of more specific rules, is applied as the head of the expression generated from the first argument:

MakeExpression[TagBox["a", b], StandardForm] 
(* HoldComplete[b[a]] *)

However, an exception is made for heads that are members of $OutputForms, where it is ignored:

$OutputForms // Unprotect
AppendTo[$OutputForms, b]
MakeExpression[TagBox["a", b], StandardForm]
(* HoldComplete[a] *)

This is "wrapper stripping" (the behavior of functions that "affect formatting, but not evaluation") is implemented. But it would be bad if wrapper stripping occured when you did a Convert To *Form. Fortunately, that operation doesn't use MakeExpresion/MakeBoxes, but rather a dedicated function, which knows not ignore those TagBoxes. Here is the call to convert from StandardForm to InputForm:

BoxForm`ConvertForm[TagBox["a", b], StandardForm, InputForm]
(* "b[a]" *)

To be perfectly honest, the only reason I can explain this behavior is that I came across the source code for it while fixing a bug, and was able to reproduce the reason for it from the commit message. It is a bit of black magic, but given the relatively small number of questions about it for the last 24 years or so, it is good enough to get the job done.

Answer 2

Here are few notes:

Notice the second argument of underying TagBox[gridbox, Function[e, MatrixForm[e]]. It guides the interpretation from standard to input form (Ctrl+Shift+I). Since MatrixForm won't be forgotten, route back to boxes works too.

It is not documented but it seems to work like ToExpression[gridbox, StandardForm, Function[...]]. It won't work manually, ToExpression@ToBoxes@MatrixForm will return an array. Whether that is expected I don't know but I think this should be more consistent.

Here is another example (bug) showing the difference between Cell/ConvertTo items and composition of ToBoxes/Expression:

TagBox + InterpretationBox vs ConvertTo/StandardForm

Summing up:

• Ctrl+Shift+I behavior is governed by TagBox (fine but undocumented)

• ability to evaluate typeset MatrixForm comes from the fact that ToExpression strips it before parsing/evaluation. (arguable)