# Horizontal spacing for function arguments in fractions

I'm writing with collegues on a document that heavily uses one kind of custom operator (here: a probability density function). We have not decided finally what symbols to use. Consequently, we use a custom operator definition

% probability density
\newcommand{\pdensity}[1]{p\!\del{#1}}%


where \del is the brace-wrapping command from package commath. The negative thinspace \! is needed in my opinion to distinguish argument braces from other ocurring braces, which have a bit more seperation.

In contrast to @morbusg here my opinion is to collect the braces in the command definition; This has proven handy to me when working with operators like expectation, where co-authors later decided to switch from brackets to braces.

Further I absolutely need automatic sizing for the argument braces, thus the use of \del (an other possible alternative wolud have been \left( and \right), which I am positive commath uses internally).

So far this works for me in displaymath environments as well as in inlinemath. But strange things occur when using fractions (as required in bayesian inference).

\documentclass{article}

% http://sunsite.informatik.rwth-aachen.de/ftp/pub/mirror/ctan/macros/latex/contrib/commath/commath.pdf
\usepackage{commath}
\usepackage{amsmath}

% probability density
\newcommand{\pdensity}[1]{p\!\del{#1}}%

\begin{document}
\begin{align*}
\int \left[ \frac{\pdensity{x^{(i)} }}{\pdensity{x^{(i)} }} \right] \dif x
&&
\frac{ \frac{\pdensity{a}}{\pdensity{b}}}{x + y}
\end{align*}
\end{document}


Suddenly the brace sizing varies (problem 1) (in denominator and numerator), and I have no clue as to why. Further, the negative thinspace is too much, effectively printing operatorname and brace through each other (problem 2). Please see the attached screenshot.

For problem 2, this might possibly be solved by seperating cases in the command definition for \pdensity, but I have no clue at what properties to look.

Problem 1 ie even more strange, I'd like to hear any speculations on how to fix this.

• Don't use commath. All macros it defines are wrong. Jan 10 '16 at 15:59
• You shouldn't ask why the parentheses in the first fraction are smaller, but why they're too big in the numerator. Besides, also the brackets are way too large. Jan 10 '16 at 16:11
• @egreg : Okay, I get that I should not use commath in the first place. But replacing \del with \left( and \right) still yields the same strange results. So to refine my question: why is the automatic sizing not working correctly? The inner term is exactly the same in numerator and denominator.
– marc
Jan 10 '16 at 16:16
• Okay, I got it working correctly. Based on a misunderstanding on my part, I just stopped using the \del command, but when actually not loading the package commath the 'amsmath' autosizing works correctly again.
– marc
Jan 10 '16 at 16:20

## 1 Answer

Never use commath. Its macros are full of bugs.

You get better result with \DeclarePairedDelimiter from mathtools, which allows full control over the size of the fences.

\documentclass{article}
\usepackage{mathtools}

\DeclarePairedDelimiter{\paren}{(}{)}
\newcommand{\pdensity}{p\paren}

\begin{document}

$\int\biggl[\frac{ \pdensity{x^{(i)}} }{ \pdensity{x^{(i)}} }\biggr]\,dx \qquad \int\biggl[\frac{ \pdensity[\big]{x^{(i)}} }{ \pdensity[\big]{x^{(i)}} }\biggr]\,dx \qquad \frac{ \frac{\pdensity{a}}{\pdensity{b}}}{x + y}$

\end{document}


Note that there's no need to have large fences; my preference would go to the first of the two formulas with the integral. It is as readable and less obtrusive than the second one.

You can do

\pdensity{x}
\pdensity[\big]{x}
\pdensity[\Big]{x}
\pdensity[\bigg]{x}
\pdensity[\Bigg]{x}
\pdensity*{x}


The last one uses automatic sizing (use it only when really needed).

• Your suggestion is indeed an acceptable workaround. Thank you for clarifying and elaborating this.
– marc
Jan 10 '16 at 18:38
• On an unrelated note, I'd suggest typesetting the differential operator with an upright font. Apr 11 '20 at 11:05
• @Peiffap That's your personal preference. In my view, this “d” is not an operator, but it's attached to the variable as a single unit. I'm not alone in this. Apr 11 '20 at 12:15