7
$\begingroup$

Suppose I have MMA's global preferences set to always give me a TraditionalForm output. If I copy-and-paste one of these TraditionalForm outputs into a subsequent input and try to evaluate it (not my standard practice, but I do it occasionally), I get either of two warnings about TraditionalForm's ambiguity as an input (see screenshots below; the first warning comes after I paste, the second after I hit shift-enter; IIRC I always get either one or the other, never both). Questions:

1) Can I get some examples of TraditionalForm outputs that MMA subsequently misinterprets? I don't know of any myself [except see EDIT added below]. More interestingly, are there general classes of expressions that MMA will misinterpret and, if so, why?

2) If MMA does such a misinterpretation, will it always give an error? And if so, is it always clear that the error is due to the use of TraditionalForm? If the answers to both of these are "yes", then it's not a problem for me to do this since, in the rare cases when I get an error, I can easily correct it. My concern, however, is the possibility that MMA could misinterpret a TraditionalForm expression, yet not give an error.

3) What causes MMA to give me the first warning (which follows pasting) vs. the second (which follows shift-enter), and why do I never get both? And with the first warning, does selecting the "Paste Literal" option convert what I'm pasting to StandardForm (that seems to be what it's doing)? Regardless, if I'm offered, and select, the "Paste Literal" option, is the input always interpreted identically to a StandardForm input?

4) [Added after EDIT, below]. Suppose I don't copy-and-paste outputs into inputs, and don't use @TraditionalForm in my inputs. If I set MMA to output TraditionalForm globally in Preferences -> Evaluation, is the evaluation of previous outputs always the same as it would be if my output were globally set to StandardForm?

enter image description here

Wolfram's warning against evaluating TraditionalForm ouputs

EDIT, DEC. 25, 2016:

I'd originally written that if one doesn't do the copy and paste, and simply feeds a prior result into a subsequent input, the potential ambiguity of TraditionalForm is not an issue, since MMA's internal representation of results is independent of how it prints them.

I'd thought this was the case for two reasons. First, as Wolfram explains in the MMA help documentation, under "tutorial/HowInputAndOutputWork":

"It is important to understand that in a typical Wolfram Language session In[n] and Out[n] record only the underlying expressions that are processed, not the textual representations that happen to be used for their input or output. If you explicitly request a particular kind of output, say by using TraditionalForm[expr], then what you get will be labeled with Out[n]//TraditionalForm. This indicates that what you are seeing is expr//TraditionalForm, even though the value of Out[n] itself is just expr."

And second, when I globally set Preferences->Evaluation to always output in TraditionalForm, I never noticed a difference in behavior. However, as @xzczd pointed out in the comments, my understanding was not correct. Thus:

If I set MMA to output TraditionalForm globally in Preferences->Evaluation, and execute the following code, I get the result shown on the LEFT of the screenshot below.

int = Integrate[x^2, x]
%/x
Head[%%]
int/x
Head[int]
SameQ[int == x^3/3]

However, if I set MMA to output StandardForm globally, and manually direct MMA to output the evaluation of int in TraditionalForm (using the following code), I instead get the result shown on the RIGHT of the screenshot below.

int = TraditionalForm@Integrate[x^2, x]
%/x
Head[%%]
int/x
Head[int]
SameQ[int == x^3/3]

enter image description here

Note that, in the latter code block, when int is used in the subsequent input, MMA doesn't interpret it correctly (see Out[4] on RHS of screenshot). [Or, if you prefer, it interprets it differently from a StandardForm input and, according to Wolfram, StandardForm is, well, the standard for inputs.] By contrast, MMA is able to correctly interpret the output of int when it's instead referenced using % (see Out[2], RHS). Consistent with this, on the RHS of the screenshot, while the head of %% (which references line in which int was assigned) is Times (see Out[3]), the head of int itself is TraditionalForm (see Out[5]. By contrast, with the former code, where TraditionalForm is instead output globally, the heads of both %% and int are Times, and the use of TraditionalForm does not affect how the output is interpreted.

Returning to the above-referenced help tutorial, note that it also says:

"The Wolfram Language also allows you to specify globally that you want output to be displayed in a particular form. And if you do this, then the form will no longer be indicated explicitly in the label for each line. But it is still the case that In[n] and Out[n] will record only underlying expressions, not the textual representations used for their input and output."

This seems misleading, because while Out[int = TraditionalForm@Integrate[x^2,x]] may be recording just the underlying expression, it is packaged with the TraditionalForm head, and this head changes the evaluation behavior.

$\endgroup$
4
  • 1
    $\begingroup$ So, you're not interested in the possible misinterpretation happened when one copies and pastes a TraditionalForm output and uses it as part of a subsequent input? $\endgroup$
    – xzczd
    Commented Dec 23, 2016 at 8:31
  • $\begingroup$ @xzczd: Come to think of it, that would be of interest. I edited the question, explaining that the one case in which TraditionalForm may create an ambiguity is when you copy and paste the output into a subsequent input, and asked if there are examples of when this leads to an error. $\endgroup$
    – theorist
    Commented Dec 23, 2016 at 18:49
  • 1
    $\begingroup$ I'd like to point out the new added example is improper. The correct example should be TraditionalForm@Integrate[x^2, x](* line break here *)%/x, for more information, read this post: mathematica.stackexchange.com/q/132740/1871 $\endgroup$
    – xzczd
    Commented Dec 25, 2016 at 11:43
  • $\begingroup$ @xzczd: Thanks, I've corrected and improved my example. $\endgroup$
    – theorist
    Commented Dec 25, 2016 at 23:01

1 Answer 1

4
$\begingroup$

Consider Subscript[K, a][b] (i.e., $K_a[b]$). If we use TraditionalForm, copy&paste, and execute, we get BesselK[a, b], at least in Mathematica 9.0 Linux edition. And you get no error message.

You can do the same with $J_a[b]$ (which becomes BesselJ[a, b]), $H_a[b]$ (which becomes HermiteH[a, b]), etc.

$\endgroup$
1
  • $\begingroup$ I repeated it in MMA 10.1 for OSX, and got the same results. Building on your answer, I would say there are three potential ways in which TraditionalForm expressions can be misinterpreted: (1) expressions that have symbolic mathematical meaning in TraditionalForm but not in StandardForm; (2) expressions that have symbolic mathematical meaning in Std. but not in Trad.; and (3) expressions that have mathematical meaning in both, but where the meanings are different. You've nicely identified examples of (1), and my edit above gives an example of (2). I wonder if there are examples of (3). $\endgroup$
    – theorist
    Commented Dec 25, 2016 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.