# What is the difference between a few simplification techniques?

I am trying to understand the difference between Refine, Simplify and FullSimplify, and when it's more appropriate to use a particular one. The help files on this are not entirely clear. For example, under the help for Refine it says

Use Simplify for more simplification rules:

Refine[Sqrt[x^2 + 2 x y + y^2], x + y >= 0]
(* Sqrt[x^2 + 2 x y + y^2] *)

Simplify[Sqrt[x^2 + 2 x y + y^2], x + y >= 0]
(* x + y *)


From this, I can't imagine why anyone would ever use Refine, if Simplify will get it simpler. Yet, it keeps turning up in answers on this site (e.g. here, here, or here), where Simplify would also work.

Then, regarding Simplify vs FullSimplify, the help file states:

Use FullSimplify to simplify expressions involving special functions:

Is there a guideline for which sorts of functions are considered "special functions"?

I realize that (based on the "More Information" section and personal experience) FullSimplify may take longer, but under what circumstances? Is a good general approach to try Simplify first, and then only if one is unhappy with the results, then try FullSimplify?

• Apr 20, 2012 at 2:01

The primary difference between Refine and the two *Simplify functions is that Refine only evaluates the expression according to the assumptions given. It might so happen to be the simplest form when evaluated, but it does not check to see if it is indeed the simplest possible form. You should use Refine when your goal is not to simplify the expression but to just see how the assumptions transform it (e.g., square root of a positive quantity).

Simplify, on the other hand, performs basic algebraic simplifications and transformations to arrive at the "simplest" result. Refine is one among them, and is also mentioned in its doc page. Here, "simplest" might not necessarily fit your definition of simple. It is what appears simple to Mathematica, and that is defined by LeafCount. Here's an example showing the difference between the two:

Refine[(x - 1)/Sqrt[x^2] + 1/x, x > 0]
(* Out= 1/x + (-1 + x)/x *)

Simplify[(x - 1)/Sqrt[x^2] + 1/x, x > 0]
(* Out= 1 *)


FullSimplify behaves the same as Simplify, except that it also does manipulations and simplifications when it involves special functions. It is indeed slower, as a result, because it has to try all the available rules. The list of special functions is found in guide/SpecialFunctions and it's not a non-standard usage of the term and you can also read about it on Wikipedia. So in all cases not involving special functions, you should use Simplify. You can certainly give FullSimplify a try if you're not satisfied with Simplify's result, but it helps to not start with it if you don't need it.

Here's an example showing the difference between Simplify and FullSimplify:

Simplify[BesselJ[n, x] + I BesselY[n, x]]
(* BesselJ[n, x] + I BesselY[n, x] *)

FullSimplify[BesselJ[n, x] + I BesselY[n, x]]
(* HankelH1[n, x] *)


### A few more notes on Simplify and FullSimplify:

As you have noted, FullSimplify is slow — sometimes it can take hours on end to arrive at the answer. The default for TimeConstrained, which is an option, is Infinity, which means that FullSimplify will take its sweet time to expand/transform until it is satisfied. However, it could very well be the case that a bulk of the time is spent trying out various transformations (which might eventually be futile) and the actual simplification step is quick. It helps to try out with a shorter time, and the documentation has a good example that shows this. This holds for Simplify too.

Note that setting the option TimeConstrained -> t does not mean that you'll get your answer in under t seconds. Rather, it means that Mathematica is allowed to spend at most t seconds for a single transformation/simplification step.

Similarly, you can exclude certain functions from being simplified using ExcludedForms or include other custom transformations using TransformationFunctions. You can even change the default measure of "simplicity" using ComplexityFunction, and here is an answer that uses this. However, these options are not available in Refine.

These are actually well documented in the documentation for both functions, but is not widely known and can often be the key to getting the result quickly or in the form you want.

• Interesting. They say FullSimplify is often slow, and I see that as a reason not to go there first. But, is Simplify measurably faster than Refine? Apr 20, 2012 at 2:06
• As an example: Simplify[Gamma[x] Gamma[1 - x]] is unproductive, while FullSimplify[Gamma[x] Gamma[1 - x]] does produce something "simpler". On the other hand, to get the full benefit of FullSimplify[], you will sometimes have to do a preliminary application of FunctionExpand[]. Apr 20, 2012 at 2:14
• I understand the difference/benefits of FullSimplify vs Simplify and I've seen the various examples in the help file. What about Refine? Why ever use it? Apr 20, 2012 at 2:20
• @R.M: very good answer, but since the question about potential "slowness" of FullSimplify has come up you probably might want to add a note about the presettings of the TimeConstraint options of the three functions. I think this is an important detail one should be aware of, especially since in combination with caching the result of consecutive runs might differ. It's probably also worth noting that one can control the rules to try (TransformationFunctions) and measure of simplicity (CompexityFunction). Apr 20, 2012 at 7:17
• @Stan I described it here: meta.mathematica.stackexchange.com/a/478/5 Please also see the comment re: browsers. It's now been almost 5 years, so I don't know if they still hold true or if things have improved since then.
– rm -rf
Jan 18, 2017 at 15:47

Refine vs Simplify

Mathematica is a term rewriting system, whenever we enter an expression, then it is evaluated by term rewriting using (built-in or user-defined) rewrite rules (see e.g. Evaluation) , so by default it "simplifies" some expressions, e.g. :

a + b - a

b


So this makes an impression, that Refine performs some simplifications, although documentation states that it yields the form of an expression which would be obtained if symbols in it were replaced by explicit numerical expressions satisfying the assumptions (defualt if not specified).

However, sometimes algorithms behind Simplify appear not easily adjusting to do simple tasks unlike Refine, although they contain transformations done by Refine. A direct example :

{Refine, Simplify, FullSimplify} @@ {-Re[x + y], (x | y) \[Element] Reals} // Through

{-x - y, -Re[x + y], -Re[x + y]}


We can get -(x+y) with Simplify and FullSimplify as well if we choose an appropriate ComplexityFunction (not accessible with Refine), you may look here. Simplification techniques offered by Simplify and FullSimplify include options like Trig, TransformationFunctions,ExcludedForms etc. unlike for Refine, where we can specify only assumptions or TimeConstraint.

Simplify vs FullSimplify

Expressions involving special functions

FullSimplify allows simplifications involving special functions unlike Simplify. There is no general definition of special functions, but basic ones are solutions of second order linear ordinary differential equations like e.g. hypergeometric functions, Bessel functions, Gegenbauer polynomials etc. on the other hand i.e. Riemann zeta function $\zeta\;$, one of the most amazing special functions is not a solution of any differential equation, however there is e.g. a functional equation relating it to Euler $\Gamma\;$ function : $$\zeta(z) = 2^z\pi^{z-1}\ \sin\left(\frac{\pi z}{2}\right)\ \Gamma(1-z)\ \zeta(1-z)$$ which helps to find easily trivial zeros of $\zeta$.

A = Through /@ {Simplify, FullSimplify} /@ {2^z Pi^(z - 1) Sin[Pi z/2] Gamma[1 - z] Zeta[1 - z],
Gamma[1 - x] Gamma[x] Sin[Pi x]};
Grid[ Array[ InputField[ Dynamic[ A[[#1, #2]]], FieldSize -> 20] &, {2, 2}]] Elementary expressions

Simplify is clearly more limited than FullSimplify and the differences are distingushible not only for special functions. See for example this post for an apparent difference of behaviors for simple polynomials. Here is another difference for quite elementary expressions :

Through @ { Simplify, FullSimplify } @
(Sqrt[ a^2 - 2 a b c + b^2 c^2] /. {a -> 8, b -> Sqrt, c -> 3})

{ Sqrt[ 82 - 48 Sqrt], 8 - 3 Sqrt}


Clearly, if we assume e.g. b -> Sqrt, then Simplify cannot tackle such a simple expression, although it can do it on a more general symbolic level if an appropriate assumption is given :

{Simplify, FullSimplify} @@ {Sqrt[a^2 - 2 a b c + b^2 c^2], a - b c > 0} // Through

{a - b c, a - b c}


and we see that Refine does not simplify anything here.

Another slightly more involved example, where Simplify works with assumptions only on the symbolic level :

Column @
Through @
({Refine, Simplify, FullSimplify} @@
{a + b + c - Sqrt[a^2 + b^2 + c^2 + 2 b c + 2 Sqrt[a^2 b^2 + a^2 c^2 + 2 (a^2) b c]],
a > 0 && b + c > 0}) but not for numeric values :

Column @ Through @ {Refine, Simplify, FullSimplify} @
(Sqrt + 2 Sqrt + 3 Sqrt - Sqrt[ 12 Sqrt + 2 Sqrt[24 Sqrt + 114] + 59]) Refine dosen't do anything here, i.e. it works here just like Identity, Simplify here only groups terms (24 Sqrt + 114 -> 6( 19 + 4 Sqrt), while FullSimplify does the full simplification.

Using Simplify is of course advantageous (because of time needed to perform a task) when we want to deal with large expressions and apply some simple algebraic transformations, e.g. for tensors in general relativity.

• +1 For the example where Refine gives a simpler expression than `*Simplify~. Apr 20, 2012 at 20:30
• "There is no general definition of special functions..." - the working definition I'm accustomed to is that it's "special" if it's not an elementary function (algebraics, exponentials, logarithms, trigonometric/hyperbolic functions and their inverses, combinations and compositions thereof.) Jun 9, 2012 at 10:11
• "...no general definition...", you mentioned the working definition, there is also "...solutions of second order linear ordinary differential equations of mathematical physics". Those both are quite different so the statement "there is no general definition of special functions..." is perfectly correct. Jun 9, 2012 at 10:42