math: Expm1(x) is off by 1 for values of x around [14, 34]

[mdempsky]

http://play.golang.org/p/Ji-WVA0TM4

This is due to this error caught by cmd/vet:

expm1.go:230: (0x3ff - k) might be too small for shift of 52

The problem is k is an int, so the shift here:

t := Float64frombits(uint64((0x3ff - k) << 52)) // 2**-k

happens before the conversion to uint64.

This only affects amd64p32 and arm, because they're the only ports with 32-bit ints that use the portable Expm1 implementation.

The fix is obvious (convert to uint64 before the shift), but I'm not sure the best way to write a test for this. I thought I'd just add an entry to vfexpm1SC and expm1SC, but TestExpm1 uses alike for testing those, and 386's assembly version of Expm1 returns a slightly different value for Expm1(20) than the portable Go version.

[bradfitz]

Just write a new "func TestWhatever" if one of the existing tables aren't quite appropriate or convenient.

[cldorian]

The entries ending in "SC" are used for testing for "Special Conditions", which means NaN, Inf, and signed zero. That's why they use alike() to compare, rather than close(), veryclose(), etc.

I suggest adding another for loop. Scale the size of of the vf[] arguments and create expm1Large[] containing the expected answers. See the cosLarge as an example.

[gopherbot]

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