Fixed legit gripe from c.l.py that math.fmod docs aren't confusing enough.

FRED, please check my monkey-see-monkey-do Tex fiddling!

Doc/lib/libmath.tex

@@ -60,7 +60,9 @@ Return the floor of \var{x} as a real.
 \end{funcdesc}
 
 \begin{funcdesc}{fmod}{x, y}
-Return \code{\var{x} \%\ \var{y}}.
+Return \code{fmod(\var{x}, \var{y})}, as defined by the platform C library.
+Note that the Python expression \code{\var{x} \%\ \var{y}} may not return
+the same result.
 \end{funcdesc}
 
 \begin{funcdesc}{frexp}{x}

Modules/mathmodule.c

@@ -106,7 +106,8 @@ FUNC1(fabs, fabs,
 FUNC1(floor, floor,
       "floor(x)\n\nReturn the floor of x as a real.")
      FUNC2(fmod, fmod,
-      "fmod(x,y)\n\nReturn x % y.")
+      "fmod(x,y)\n\nReturn fmod(x, y), according to platform C."
+      "  x % y may differ.")
 FUNC2(hypot, hypot,
       "hypot(x,y)\n\nReturn the Euclidean distance, sqrt(x*x + y*y).")
 FUNC1(log, log,

Objects/floatobject.c

@@ -399,7 +399,7 @@ float_divmod(PyFloatObject *v, PyFloatObject *w)
 	PyFPE_START_PROTECT("divmod", return 0)
 	vx = v->ob_fval;
 	mod = fmod(vx, wx);
-	/* fmod is typically exact, so vx-mod is *mathemtically* an
+	/* fmod is typically exact, so vx-mod is *mathematically* an
 	   exact multiple of wx.  But this is fp arithmetic, and fp
 	   vx - mod is an approximation; the result is that div may
 	   not be an exact integral value after the division, although