# Forcing Explicit Parentheses in Traditional Form

I have an expression in input form for the Cosine of a dihedral angle:

     (( Cross[Subscript[b, 0], Subscript[b, 1]] )\[CenterDot](
Cross[Subscript[b, 0], Subscript[b, 2]])) /(Abs[
Cross[Subscript[b, 0], Subscript[b, 1]]] Abs[
Cross[Subscript[b, 0], Subscript[b, 2]]])


that I would like to express in Traditional Form.

However, when using postfix notation //TraditionalForm, the inner sets of parentheses surrounding the cross products are deleted from the numerator. There is no ambiguity if they are excluded, but the use of these "additional" parentheses make it clear that one is taking the dot product of two cross products in the numerator.

How can I force them to be explicitly included so that they appear in traditional form surrounding the two parts of the dot product? Use of a backslash before the parentheses does not work nor does adding extra spaces;

nor does:

TraditionalForm@
HoldForm[(( Cross[Subscript[b, 0], Subscript[b, 1] )\[CenterDot](
Cross[Subscript[b, 0], Subscript[b, 2]]))]/(Abs[
Cross[Subscript[b, 0], Subscript[b, 1]]] Abs[
Cross[Subscript[b, 0], Subscript[b, 2]]])]


nor does

TraditionalForm@
HoldForm[(( Cross[Subscript[b, 0], Subscript[b, 1]))]\[CenterDot](
Cross[Subscript[b, 0], Subscript[b, 2]]))]/(Abs[
Cross[Subscript[b, 0], Subscript[b, 1]]] Abs[
Cross[Subscript[b, 0], Subscript[b, 2]]])

• Mathematica automatically removes ( ) even in Standard Form. !Mathematica graphics I think you will fighting a losing battle here try to keep them. Commented Jan 19 at 23:32

Precedence /@ {Cross, CenterDot}


{500., 410.}

You can wrap Cross[..] with PrecedenceForm using the second argument less than 410:

((PrecedenceForm[Cross[Subscript[b, 0], Subscript[b, 1]], 10])\[CenterDot]
PrecedenceForm[Cross[Subscript[b, 0], Subscript[b, 2]], 10])/
(Abs[Cross[Subscript[b, 0], Subscript[b, 1]]]
Abs[Cross[Subscript[b, 0], Subscript[b, 2]]]) // TraditionalForm
`

• Impressive. I'd have guessed this would be a fool's errand, but I've learned something! (+1) Commented Jan 20 at 1:25
• Since it works, I've given this an answer to the question, although it's a bit disconcerting to learn [see 135805] that Precedence is an undocumented system function and that precedence is a somewhat more mysterious than indicated in the documentation regarding operator precedence. Fortunately, at least for my needs, much of the mystery apparently can be safely ignored. Thanks for alerting me to how to resolve issues of operator preference in the front end. Commented Jan 21 at 21:14