Bug introduced in 9.0 and persisting through 12.2

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

(*  0.  *)

(*  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:

(* E^(-25 (1-2 i)^2) *)

Apparently, the float point math causes the problem.

  • $\begingroup$ As an additional diagnostic point, what happens if you replace 0.5 with 1/2? $\endgroup$
    – J. M.'s torpor
    May 6 '15 at 21:34
  • $\begingroup$ It does the right simplification, but takes a long time, see the edited question. $\endgroup$ May 6 '15 at 21:45
  • 2
    $\begingroup$ Same result on windows 9.0.1. Also Table[FullSimplify[Exp[-k (i - 0.5)^2]], {k, 73, 74, 0.01}] gives fun results. $\endgroup$
    – wxffles
    May 6 '15 at 21:46
  • $\begingroup$ In version 8, the first line with FullSimplify stays unevaluated, so the result is the same as for Simplify. $\endgroup$
    – Jens
    May 6 '15 at 22:48
  • 1
    $\begingroup$ Please send this to support@wolfram.com. $\endgroup$ May 7 '15 at 6:34

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

  Sinh[100.*x] *)

c1 - c2

(* 0. *)

[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.


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]

neighborhood around 0.5

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)


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)
  • 2
    $\begingroup$ Well, yes, but the point is that Mathematica should not assume anything about i. It's better to not simplify at all than simplify to a wrong number. However, I agree that extremely small or large float point numbers should be avoided altogether. $\endgroup$ Oct 22 '15 at 13:15
  • 2
    $\begingroup$ @DavidZwicker I think it's not that wrong, please see my edit. And exactly because no assumption is made on i (like the one I made by i->δ+.5), the expression is evaluation to 0 (of the machine precision) as a general result. The interval where the expression is greater than machine-precision zero is so small, that I look it like a practical "null set". But I agree there might be better way for the summation and cancelling procedure ilian explained. $\endgroup$
    – Silvia
    Oct 23 '15 at 2:14
  • $\begingroup$ Good explaination. However, in v10.3, the last output is E^(-100.2.*(-0.52. + i)^2) instead of E^(-100.10.*(-0.510. + i)^2). i.e. The precision of -100. is changed to 2. instead of 10. Why is the case? $\endgroup$
    – luyuwuli
    Mar 5 '16 at 8:22
  • $\begingroup$ @luyuwuli That's a good question. I don't know why and I think it deserve a separated question. $\endgroup$
    – Silvia
    Mar 7 '16 at 5:10

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 [...]


Your Answer

