7
$\begingroup$

I have this function:

$\frac{(1-\cos (\theta )) $

and I want to know its value for $x=\pi$, $\theta=0$ and $n\in\mathbb{N}$. It is clear that both numerator and denominator are zero, so the result must be indeterminate, but Mathematica gives zero!

((1 - Cos[\[Theta]]) Sin[n x])/((-1) -> \[Pi] } // 
 FullSimplify[#, Assumptions ->  n > 0 && n \[Element] Integers ] &

I wonder if someone explains what is happening here.

$\endgroup$
  • 6
    $\begingroup$ In general this happens when numerator becomes an "explicit" zero upon evaluation, while denominator is a "hidden" zero. $\endgroup$ – Daniel Lichtblau May 29 at 17:18
9
$\begingroup$

It has to do with how the evaluation is performed. The substitution results in

(0*Sin[n*Pi])/(2*(-1)^(1 + n)*Pi + 2*Pi*Cos[n*Pi])

which evaluates to 0 before it gets passed to FullSimplify. Before it is passed, n is just a variable, so the expression is not Indeterminate.

If you wish to get Indeterminate, just use FullSimplify as follows:

((1 - Cos[θ]) Sin[n x])/((-1)^(1 + n) π + (-1)^(1 + n) π Cos[θ] + 
    2 π Cos[n x] + Cos[n x] - Cos[θ] Cos[n x]) // 
 FullSimplify[#, 
   Assumptions -> θ == 0 && x == π && n > 0 && n ∈ Integers] &
| improve this answer | |
$\endgroup$
  • $\begingroup$ Are they working on fixing bugs like this? This seems like it may be one of those bugs that seems harmless enough in toy examples, but could cause subtle problems in larger models in which it wouldn't be so easily identified. $\endgroup$ – Nat May 30 at 9:24
  • $\begingroup$ @Nat Your code breaks up into two steps the computation you want carry out. As I pointed out, in the first step, n is treated as a generic variable and the rule that zero times an algebraic expression is zero is applied. I think you'd have to get rid of the multiply-by-zero rule (except in the case of numeric quantities), but that would give an unusable system (because expression-size would explode if nothing could be simplified). So this is a design choice and WRI does not consider it a bug; thus it will never be fixed. $\endgroup$ – Michael E2 May 30 at 15:28
  • $\begingroup$ @Nat Another approach is to ask if there is a robust way to set up the work you want to do which avoids such pitfalls of the system. The Simplify plus Assumptions method is such an approach, but I am not sure how robust it is. If you're worried about the strict application of algebraic rules, you should be interested in this. $\endgroup$ – Michael E2 May 30 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy