FrameLabel and OverTilde

What is the problem with this expression inside ListPrint? OverTilde generates here a mess:

FrameLabel->{{"f"<>"("<>ToString[OverTilde["x"]]<>")",None},{"x",None}}

• I think you are making this much more complicated than necessary. I would simply use FrameLabel -> {"x", "f(\!$$\*OverscriptBox[\(x$$, $$~$$]\))"}. I entered this as f(x Ctrl-7 ~ ). It's readable and easy to format in the notebook, but it becomes a bit ugly when pasting here. – Szabolcs Sep 27 '13 at 14:02
• @Szabolcs and et al., I find it bizarre that, with two answers up as I write this comment, one leapt straight to linear syntax/boxes and the other to fixing up ToString. Both answers are correct and sufficient, but surely a solution involving Row is easier to understand and apply to other similar problems. – John Fultz Sep 27 '13 at 22:53
• @JohnFultz My suggestion wasn't to type the text representation of boxes, as it was pasted here. I meant typing the equivalent 2D math expression using keyboard shortcuts. If starting with Ctrl-9 to create an inline cell, then single-character variables will be properly capitalized too. I find this wysiwyg way of entering the formula quite convenient, and it's what I use myself for plot labels. – Szabolcs Sep 28 '13 at 1:46
• @JohnFultz I guess it depends on whether in responding you answer the specific problem or suggest alternatives that maybe be better. IMO the specific problem is that ToString is not by default writing StandardForm. I agree though that Row ought to be the preferred way of doing this. – Mike Honeychurch Sep 28 '13 at 1:55

OverTilde["x"] is a short way of writing Overscript["x","~"] so it is not OverTilde per se causing the issue here. The problem is that by default ToString writes OutputForm. So what you need to do is to write the string as StandardForm:

FrameLabel->{{"f"<>"("<>ToString[OverTilde["x"],StandardForm]<>")",None},{"x",None}}

For example this doesn't work:

Plot[Sin[x], {x, 0, 10},
Frame -> True,
FrameLabel -> {{"f" <> "(" <> ToString[OverTilde["x"]] <> ")",
None}, {"x", None}},
BaseStyle -> {FontSize -> 20, FontFamily -> "TimesNewRoman"}]


But this works fine:

Plot[Sin[x], {x, 0, 10},
Frame -> True,
FrameLabel -> {{"f" <> "(" <>
ToString[OverTilde["x"], StandardForm] <> ")", None}, {"x",
None}},
BaseStyle -> {FontSize -> 20, FontFamily -> "TimesNewRoman"}]


Frame labels are automatically converted to TraditionalForm

Plot[Sin[x], {x, 0, 10},
Frame -> True, FrameLabel -> {x, f[\!$$\*OverscriptBox[\(x$$, $$~$$]\)]},
BaseStyle -> {FontSize -> 20, FontFamily -> "TimesNewRoman"}]


In the notebook it looks much better:

I specify BaseStyle to enlarge the labels. You can enter x̃ as x Ctrl+7~ as Szabolcs write in the comment. More correct to use HoldForm[x] and HoldForm[f[x̃]] to localize f and x.

My solution differs from Szabolcs's comment:

Plot[Sin[x], {x, 0, 10}, Frame -> True,
FrameLabel -> {"x", "f(\!$$\*OverscriptBox[\(x$$, $$~$$]\))"},
BaseStyle -> {FontSize -> 20, FontFamily -> "TimesNewRoman"}]


It is because TraditionalForm automatically italicizes variables and makes other necessary transformations, e.g. Sin[x] → $\sin(x)$, Hypergeometric2F1[z, b, c, z] → ${}_2F_1(a,b,c;z)$.

Why "f("<>ToString[OverTilde["x"]]<>")" works strange?

ToString[OverTilde["x"]]

~
x


It is two-line string with ~ over x. Therefore

"f(" <> ToString[OverTilde["x"]] <> ")"

f(~
x)


"f(" is prepended to first line and ")" is appended to the second line. More correct usage:

ToString[f[OverTilde["x"]]]

  ~
f[x]


This is get what JohnFultz suggested in a comment on record.

A simple and easy-to-understand approach using Row is demonstrated by

Plot[Sin[x], {x, 0, 2 Pi},
Frame -> True,
FrameLabel -> {x, Row[{"f(", OverTilde["x"], ")"}]},
BaseStyle -> {FontSize -> 16}]


• I guess the point I was making in my comment to john fultz was that the question asked "What is the problem with this expression..." not "what is the best way to ...". Do we answer the actual questions here or do we re-frame questions to ones which we would prefer to answer? – Mike Honeychurch Sep 28 '13 at 12:18
• @MikeHoneychurch. Your point is well-taken. I think we should answer the actual question and also reframe and answer them to show better practice. – m_goldberg Sep 28 '13 at 12:23
• I haven't searched but I would guess there must be many answers here that show that Row is an optimal approach to this problem. I interpret the question as one which requires an explanation of unexpected ToString behaviour ("What is the problem with this expression..."). – Mike Honeychurch Sep 28 '13 at 12:28