Lemma 110.9.1. Completion is not an exact functor in general; it is not even right exact in general. This holds even when $I$ is finitely generated on the category of finitely presented modules.

## 110.9 Completion is not exact

A quick example is the following. Suppose that $R = k[t]$. Denote $M^\wedge $ the completion of an $R$-module with respect to $I = (t)$. Let $P = K = \bigoplus _{n \in \mathbf{N}} R$ and $M = \bigoplus _{n \in \mathbf{N}} R/(t^ n)$. Then there is a short exact sequence $0 \to K \to P \to M \to 0$ where the first map is given by multiplication by $t^ n$ on the $n$th summand. We claim that $0 \to K^\wedge \to P^\wedge \to M^\wedge \to 0$ is not exact in the middle. Namely, $\xi = (t^2, t^3, t^4, \ldots ) \in P^\wedge $ maps to zero in $M^\wedge $ but is not in the image of $K^\wedge \to P^\wedge $, because it would be the image of $(t, t, t, \ldots )$ which is not an element of $K^\wedge $.

A “smaller” example is the following. In the situation of Lemma 110.8.1 the short exact sequence $0 \to J \to R \to R/J \to 0$ does not remain exact after completion with respect to $I$. Namely, if $f \in J$ is a generator, then $f : R \to J$ is surjective, hence $R \to J^\wedge $ is surjective, hence the image of $J^\wedge \to R$ is $(f) = J$ but the fact that $R/J$ is noncomplete means that the kernel of the surjection $R \to (R/J)^\wedge $ is strictly bigger than $J$, see Algebra, Lemmas 10.96.1 and 10.96.10. By the same token the sequence $R \to R \to R/(f) \to 0$ does not remain exact on completion.

**Proof.**
See discussion above.
$\square$

## Post a comment

Your email address will not be published. Required fields are marked.

In your comment you can use Markdown and LaTeX style mathematics (enclose it like `$\pi$`

). A preview option is available if you wish to see how it works out (just click on the eye in the toolbar).

Unfortunately JavaScript is disabled in your browser, so the comment preview function will not work.

All contributions are licensed under the GNU Free Documentation License.

## Comments (2)

Comment #8739 by Paolo Lammens on

Comment #9338 by Stacks Project on