What does "suitable for symbolic manipulation" in the documentation mean?

Question

This question is related to this other one I posted on Stack Overflow some time ago. There, in a beautiful answer, acl (with some unhumble editing done by me) showed that the derivative of IntegerPart is calculated numerically by a centered difference method of eighth order.

If you read the help for IntegerPart[] you'll find:

Mathematical function, suitable for both symbolic and numerical manipulation.

At that time I assumed it was just a documentation (or program) bug.

I revisited the problem today because I needed to solve an equation that can be tracked down to something like:

Reduce[IntegerPart@x == x, x, Reals]
(*
-> Reduce::nsmet: This system cannot be solved with the methods available to Reduce. >>
*)

So again, Mma's failure to "symbolically manipulate" the IntegerPart[] function is bothering me. And this time, the derivative calculation is not the issue.

All these functions {IntegerPart, FractionalPart, Ceiling, Floor, Round, PrimePi} share the

Mathematical function, suitable for both symbolic and numerical manipulation.

legend in their help reference.

Look at their derivatives:

f = {IntegerPart, FractionalPart, Ceiling, Floor, Round, PrimePi};
GraphicsGrid[
 Partition[
   Plot[{#[u], D[#[x], x] /. x -> u}, {u, -1, 3}, 
       PlotLabel -> Style[Framed[Hyperlink[#, "paclet:ref/" <> #] &@ToString@#], 16,
                          Blue, Background -> Lighter[Yellow]]] & /@ f, 
  2], 
 Frame -> All]

Moreover, the help file for NextPrime[] doesn't state anything about its symbolic manipulation suitability, and the help for HeavisideTheta[] says:

HeavisideTheta can be used in integrals, integral transforms and differential equations.

and its derivative is evaluated as DiracDelta[].

When you plot these functions you get:

So it seems that from the whole set, only HeavisideTheta is treated symbolically.

However, when you try:

Reduce[HeavisideTheta@x == 1, x, Reals]
(*
-> Reduce::nsmet: This system cannot be solved with the methods available to Reduce. >>
*)

So the "symbolical manipulation" is not there (or so it looks like).

So the question is: What does it mean for a Mathematica function to be "suitable for symbolic manipulation"?

Answer 1

I've always considered the "suitable for symbolic manipuation" line to be a bit of truth wrapped in marketing speak and not meant to mean anything mathematically precise. The documentation center guides and tutorials are good examples of hyperbole in technical documentation (see for instance, the opening lines in Mathematical Typesetting).

Coming to the "bit of truth" part, I believe WRI's interpretation of "symbolic manipulation" is reflected in Symbolic Calculations

With Mathematica, you can differentiate an expression symbolically, and get a formula for the result.

So it's a simple interpretation which roughly means formula in, formula out. Whether expressions can be manipulated symbolically or not depends heavily on the internal implementation and as noted in the same document:

There are however many circumstances where it is mathematically impossible to get an explicit formula as the result of a computation.

Now coming to your HeavisideTheta example, here's a function that is effectively the same:

Clear[f]
f[x_] := Piecewise[{{0, x < 0}, {1, x > 0}}, HeavisideTheta[0]]

Now let's try some symbolic manipulations on each of them

funcs = {f, HeavisideTheta};
Integrate[#[x], {x, -2, 2}] & /@ funcs
(* {2, 2} *)

Table[Limit[#[x], x -> 0, Direction -> i] & /@ funcs, {i, {1, -1}}]
(* {{0, 0}, {1, 1}} *)

FourierTransform[#[x], x, w] & /@ funcs
(* {I/(Sqrt[2 π]] w) + Sqrt[π/2] DiracDelta[w], I/(Sqrt[2 π] w) + Sqrt[π/2] DiracDelta[w]} *)

Looks good... but:

Integrate[D[#[x], x], {x, -1, 1}] & /@ funcs
(* {0, 1} *)

Simplify[Reduce[#[x] == 1, x, Reals], Assumptions -> HeavisideTheta[0] != 1] & /@ funcs
(* x > 0, Reduce::nsmet: This system cannot be solved with the methods available to Reduce. >> } *)

So you can see that the built-in implementation knows how to differentiate HeavisideTheta correctly and the trade-off for that added knowledge is additional complexity which makes Reduce choke when trying to solve a relatively simple expression.