problem finding limits when L'hopital's rule is needed

Now that I have an expression f(x)=(x^2-1)/(exp(x)-exp(1)), and I want its limit at x -> 1, according to L'hopital's rule it should be 2/e and so does the plot tells me. However when I use the limit function limit((x^2-1)/(exp(x)-exp(1)),x,1,'right') or limit((x^2-1)/(exp(x)-exp(1)),x,1,'left') it tells me the result is 0.

Answer 1

[John D'Errico]

As always, you need to be careful when using floating point numbers. See the difference between what I wrote here, and what you did.

limit((x^2-1)/(exp(x)-exp(sym(1))),x,1,'right')
ans =
2*exp(-1)

As you can see, the only thing I did differently was use exp(sym(1)) instead of exp(1). The problem is, exp(1) is not the same as exp(sym(1)). exp(1) is internally converted to a double precision number, BEFORE it is passed to the symbolic tool. The latter is a symbolic form. The former, just a number that closely approximates the other.

vpa(exp(sym(1)) - exp(1))
ans =
-0.00000000000000029952452067713760251402983343623

So, then when limit is applied to that function as you write it, the denominator does not in fact approach zero, while the numerator does approach zero. So limit has no problem with returning zero as a result to your original function.

Just for kicks, I had to try passing this function into my own limit estimation tool. Limest is on the file exchange, although limit does just fine.

format long g
[L,Lerr] = limest(@(x) (x.^2-1)./(exp(x)-exp(1)),1)
L =
         0.735758882343249
Lerr =
       9.1796716481729e-14

2*exp(-1)
ans =
         0.735758882342885

[Duoyuan Wang]

Thanks, I think the sym(1) is what I'm looking for.

[John D'Errico]

It really is. This is a problem whenever the parser will evaluate a sub-expression, before it passes something to a function. Here, if the symbolic toolbox could be smart enough to grab that line before exp(1) was evaluated, then there would be no problem. But it cannot do that. x^2-1 is not a problem, because 1 is an integer already. But exp(1) is a problem, because that result is not an integer. It is not exact, but stored in double precision, before the symbolic toolbox is able to know what it is.

SOMETIMES the symbolic TB is smart enough to catch these things. For example

x = sym(1 + 2/3)
x =
5/3

Here, even though the fraction is not stored in exact form, sym gets it right.

sprintf('%0.55f',2/3)
ans =
0.6666666666666666296592325124947819858789443969726562500

The fraction ⅔ is NOT representable exactly as a float, but sym caught that one.

The rule is to be careful always with these things.