FullSimplify wrongly reduces expression to zero

Question

Bug introduced in 9.0 and persisting through 12.2

---

I get the following output with a fresh Mathematica (ver 10.0.2.0 on Mac) session

FullSimplify[Exp[-100*(i-0.5)^2]]
(*  0.  *)

Simplify[Exp[-100*(i-0.5)^2]]
(*  E^(-100. (-0.5+i)^2)  *)

FullSimplify seems to be a bit overambitious and kills the expression completely. Is there anything that explains this behavior or is this simply a bug?

As suggested in the comments, I did an additional test:

FullSimplify[Exp[-100*(i-1/2)^2]]
(* E^(-25 (1-2 i)^2) *)

Apparently, the float point math causes the problem.

Answer 1

This is certainly an undesirable result, although FullSimplify isn't doing anything wrong.

The transformations performed are

Map[ExpandAll, ExpToTrig[E^(-100 (-0.5 + x)^2)]]

(* Cosh[25. - 100. x + 100 x^2] - Sinh[25. - 100. x + 100 x^2] *)

Map[TrigExpand, %]

(* 0. *)

where all coefficients in the expanded form of both the Cosh and Sinh summands are the same up to machine precision, leading to cancellation.

For example, looking at just the following terms,

(c1 = Coefficient[TrigExpand[Cosh[25. - 100. x + 100 x^2]], Sinh[x^2]^97]) // InputForm

(* 5.821596111427648*^15*Cosh[100.*x]*Cosh[x^2]^3 - 5.821596111427648*^15*Cosh[x^2]^3*
  Sinh[100.*x] *)

(c2 = Coefficient[TrigExpand[Sinh[25. - 100. x + 100 x^2]], Sinh[x^2]^97]) // InputForm

(* 5.821596111427648*^15*Cosh[100.*x]*Cosh[x^2]^3 - 5.821596111427648*^15*Cosh[x^2]^3*
  Sinh[100.*x] *)

c1 - c2

(* 0. *)

Answer 2

[Too long for a comment.]

I very much doubt this will be "fixed" in any general way, and in fact am not convinced it is "broken" (in any general way). (Full)Simplify has to rely on any number of methods that manipulate rational/trig functions. These are all based on exact methods that have, of necessity, been adapted (more to the point, coopted) for use in the realm of approximate coefficients. With bignums and significance arithmetic these changes generally do alright. With machine numbers there is not a chance that all heuristics will meet all needs at all times. The things I have tried to optimize for include

(1) Avoid crashes

(2) Avoid "small" residual expressions wherein coefficients are on the order of a machine precision ULP (because these really mess up zero testing and related things that rely on a decision procedure, hence will mess up Series, Limit, Integrate...

(3) Try to get cancellations to be sensible e.g. for Together.

What this means is that smallish machine precision values might get chopped inside code that is primarily based on exact methods. Frankly, I'm happy we've managed to push the algorithms as far as we have in terms of handling approximate input. The literature on "symbolic-numeric manipulation" is not so optimistic, the best methods are not too fast, there are tolerances to be set or deduced, etc.

Answer 3

Although confirmed by Wolfram officially, I will still hesitate to call this a bug.

The expression DOES very close to zero (though not a constant) everywhere except in a small neighborhood around $i=0.5$:

LogPlot[E^(-25 (1 - 2 i)^2), {i, -1, 2}, PlotRange -> All]

There is no way $10^{-80}$ can be handled correctly with a machine precision method.

One of the properer ways is do the math near $0.5$:

FullSimplify[E^(-100 (i - .5)^2) /. i -> δ + .5] /. δ -> i - .5

E^(-100 (-0.5 + i)^2)

Edit

To answer OP's comment, I still think it's actually a problem with using machine-precision number at an inappropriate place. Try change 0.5 to an arbitrary-precision number, say 0.5`2, then the result will be fine:

FullSimplify[Exp[-100*(i - 0.5`2)^2]] // InputForm

E^(-100.`10.*(-0.5`10. + i)^2)

Answer 4

The behavior seems to be a bug of Mathematica. Here is an excerpt from an email I got from Wolfram after asking them about the problem:

It does seem that the answer of FullSimplify is incorrect especially since the exponential function is not identical to zero (or a very-close-to-zero constant). Therefore, I filed a report with our development team raising the issue [...]