# Integrate is not using Assumptions correctly

My question here is distinct to those that appear to have been asked earlier here, such as 19833.

The broad problem is that Mathematica is not simplifying the Assumptions given before usage. This is the simplest example similar to where the problem is occuring in my work, which is basically the orthogonality of the Spherical Harmonics with Cos[θ]:

Assuming[m∈Integers&&-1<m<1, Integrate[Integrate[SphericalHarmonicY[1,m,θ,ϕ]*Cos[θ],{ϕ,0,2π}]*Sin[θ],{θ,0,π}]


This gives an output of 0. Now, the assumptions I've given already constrain m==0, in which case I should have a nonzero output. In fact Reduce[m∈Integers&&-1<m<1] gives me m==0, as expected, and then

Assuming[m==0, Integrate[Integrate[SphericalHarmonicY[1,m,θ,ϕ]*Cos[θ],{ϕ,0,2π}]*Sin[θ],{θ,0,π}]


gives me the expected answer of 2√(π/3).

So the question is basically this: Why isn't Mathematica giving the same answer under two equivalent set of Assumptions?

Also, in reference to the discussions in other questions like 19833, I'd like to point out that this equivalent behavior is obtained if I put the Assumptions inside the Integrate function instead, i.e., it still gives 0 when the assumption looks like m∈Integers&&-1<m<1, and the nonzero answer when the assumption looks like m==0.

EDIT: Why I think this question is distinct from the previously asked ones: My understanding of the resolution to the previously asked questions would indicate that using Integrate[...,Assumptions->...] would resolve the issue, which in this case it does not, as explicitly mentioned above. Further, from previous answers I would not be inclined to believe that Assuming[m∈Integers&&-1<m<1, Integrate[...] and Assuming[Reduce[m∈Integers&&-1<m<1], Integrate[...] would give distinct results, which it does in this case.

• Possible duplicate of Usage of Assuming for Integration Aug 1, 2017 at 20:52
• Maybe this is a better choice for a duplicate. Aug 1, 2017 at 20:54
• @DanielLichtblau: No, not quite. It isn't a duplicate of the first one, as I've explicitly discussed in my question. It isn't a duplicate of the second, because the assumptions in my question are significantly more constrained, and the answer is different for two equivalent assumptions. This is what I think makes it different from the two questions you've linked, and other similar ones. If you think similar ideas might be useful here, then do let me know. Aug 2, 2017 at 0:50
• Maybe you could explain explicitly why @DanielLichtblau's discussion of how Integrate deals with assumptions in Usage of Assuming for Integration doesn't help. Yes, the question is different. But the answer seems very applicable. (And note that Assuming[Reduce[m \[Element] Integers && -1 < m < 1], Integrate[...]] simplifies the assumptions and gives the expected result.) Aug 2, 2017 at 11:22
• @aardvark2012: From @DanielLichtblau's discussion, would you expect Assuming[m∈Integers&&-1<m<1, Integrate[...]] and Assuming[Reduce[m∈Integers&&-1<m<1], Integrate[...] to give distinct results? If so then I am clearly not following the discussion. Further, my understanding of Daniel's discussion would imply that using Integrate[...,Assumptions->...] would resolve the problem, which in this case it does not. Aug 2, 2017 at 15:41

## 1 Answer

No function tries to Simplify or Reduce the value of Assumptions. This is potentially very expensive. When you add or remove assumptions, certain basic consistency tests are performed as well as reducing the expressions to certain canonical forms. This is why, for example,

Integrate[a x, x, Assumptions -> x > 0 && x < 0]


generates a ::cas message, or why assumptions like {a,b,c} ∈ Reals becomes a | b | c ∈ Reals. But nothing resembling quantifier elimination (which is basically what your example is asking for) is performed. If you want that done, call Reduce on your assumptions before hand.

A couple of related comments and tips. Avoid disjunctions, the Assumptions mechanism doesn't deal particularly well with them except when combining inequalities. Conversely, conjunctions tend to work better. Different ways of expressing conditions can cause different answers not just because its non-trivial to show they are equivalent, but because they may cause different branches of the function to be entered.