I am trying to compute a sequence of terms, which have a form similar to $g(z)$ at different points $z$. For $z$ close to 0, I have observed that the terms are evaluated as 0/0 (indeterminate form) instead of full simplification first, and then substitution, which would give the correct answer. I have quoted here, a snippet of code that represents the issue I encounter.

f[ z_] = Sin[z];
g[ z_] := FullSimplify[f[ z]/f[ z]];

Limit[g[z], z -> 0]
(* 1 *)

During evaluation of In[74]:= Power::infy: Infinite expression 1/0 encountered.
During evaluation of In[74]:= Infinity::indet: Indeterminate expression 0 ComplexInfinity encountered.

How can I ensure that the full simplify is performed before evaluation is done? Thankyou.

  • $\begingroup$ you defined g to take two arguments g[n_, z_] . But you are calling it using one argument g[z]? How did it work for you? $\endgroup$
    – Nasser
    Nov 2, 2023 at 5:59
  • $\begingroup$ I have just edited my post to make the correction. It was a residual typo from simplifying my original problem. Thankyou for pointing it out. $\endgroup$
    – sai
    Nov 2, 2023 at 6:03
  • 2
    $\begingroup$ If you use Set instead of SetDelayed, it's fine: g[ z_] = FullSimplify[f[ z]/f[ z]] evaluates directly to 1 (notice the lack of colon in front of the equal signs). I see a lot of recommendations saying to default to SetDelayed (:=) for function definitions, but it's really not necessary once you're careful about your global variable declarations. $\endgroup$
    – march
    Nov 2, 2023 at 16:54
  • $\begingroup$ I don't think your question is well-stated. Your "real" code can't possibly be FullSimplify[f[ z]/f[ z]], and this is such a special case that solutions to this special case probably won't generalize to your "real" code. Is the problem really evaluation order, or is it a matter of accuracy? You said "For z close to 0", and that's what made me think this is an accuracy issue. $\endgroup$
    – lericr
    Nov 2, 2023 at 17:25
  • $\begingroup$ +1 to @march for suggesting just Set. You can also verify it's doing exactly what they're suggesting by comparing the DownValues between using Set and SetDelayed. I use this trick for immediate evaluation and assignment of functions like this all the time. $\endgroup$ Nov 2, 2023 at 18:03

2 Answers 2


This is just evaluation order. One way to workaround it could be

f[z_] = Sin[z]
g[z_] := Module[{x}, FullSimplify[f[x]/f[x]] /. x -> z]

And now

Mathematica graphics

There might be other ways.

  • $\begingroup$ This process seems to be very slow as opposed to direct evaluation to the point that it is not feasible in my original problem. Is the rate limiting process the use of FullSimplify? $\endgroup$
    – sai
    Nov 2, 2023 at 6:35
  • $\begingroup$ @sai FullSimplify is known to be very slow! (it tries many many things more compared to Simplify). Try with only Simplify? in my codes I always try Simplify first and if that fails, only then try FullSimplify. $\endgroup$
    – Nasser
    Nov 2, 2023 at 6:53
  • $\begingroup$ I have tried Simplify and it is still very slow. $\endgroup$
    – sai
    Nov 2, 2023 at 6:58
  • $\begingroup$ @sai well if Simplify is also slow, then this issue has nothing really to do with the above code I have, right? I am just using your code and you had Simplify in there. You question was about evaluation order and not why Simplify is slow or not. May be you could ask separate question on that if you want. $\endgroup$
    – Nasser
    Nov 2, 2023 at 7:01
  • $\begingroup$ I have asked another related question where I think I can circumvent simplify. Thankyou for your suggestion. I will still keep this question open in case there are workarounds to this issue. $\endgroup$
    – sai
    Nov 2, 2023 at 7:16
f[z_] := Sin[z];
g[z_] := f[z]/f[z]


(* 1 *)

Limit[g[z], z -> 0]

(* 1 *)



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.