Simpler test case: http://play.golang.org/p/oqww8UyFBQ

The docs do say

Very large values overflow to 0 or +Inf.

@cespare Yes, just noticed as well. That said, this can probably be fixed w/o costing too much in the general case: If the result is 0 and the input is positive, the result should be +Inf.

It would be a backward compatible change that would make Exp behave less surprising.

The threshold for returning +Inf is in exp.go (Overflow = 7.09782712893383973096e+02). Shouldn't it better to check this value in every implementation? This way all architectures should return the same, as currently arm (Raspberry Pi) returns +Inf

@siritinga Ideally, all platforms behave the same. On x86, the code is in assembly for speed. We want to make sure to not impact the performance significantly in the common case.

Either way, the current behavior is documented and thus this is technically not a bug. Leaving open for now because it would be nicer to behave exp in less surprising ways.

I hadn't noticed that documentation either. It is surprising, and as far as I know not a well known possible behavior of exp. For example, Matlab, Octave, Fortran, Julia, numpy.Exp, C, and C++ all return inf for the test case I posted.

Related #7394

I do notice that the document says with very large values math.Exp will overflow to 0 or +Inf. But I found it will overflow to unforeseen numbers, not just zero or +Inf, for example:

fmt.Println(math.Exp(1.48852223e+09))

return is 0.0027127673070219977, rather than 0 or +Inf.

In fact, with almost identical numbers, ouput may vary huge. eg. https://play.golang.org/p/D-XAs6nXN2

This may cause trouble. First I assume the zero return with positive value is +Inf, according to the document. The behavior of my program is strange, it cost me a full day to find why.

(math.Exp(1.48852223e+09) returning 0.0027127673070219977 is definitely a problem, the documentation says

Very large values overflow to 0 or +Inf

On second thought, let's keep this issue about the "exp returning 0 instead of +Inf" problem. I've filed #18912 for the wrong values problem.

CL https://golang.org/cl/36271 mentions this issue.