--- On Tue, 6/9/09, Robert Kern <robert.kern@gmail.com> wrote:
I should probably 'Note' this tanh's doc (and other transcendentals that may exhibit this behavior).
<shrug> It's generic to all floating point implementations of transcendentals. I'd prefer not to clutter up each ufunc's docs. A section in the User's Guide about floating point arithmetic in general might be worthwhile, though.
With a list of numpy-furnished functions to which the "problem" applies. (It's one thing to explain the phenomenon in general, and once this is done the "pedestrian" user may then be alert to the danger in source code, but still forget, or simply not realize, that it applies to library functions as well. Put another way, though one will certainly recognize that their own numerics will be subject to this, they might still expect that standard, furnished mathematical functions will have been written to be more "robust" w/ respect to their exact mathematical properties. I certainly wouldn't have _expected_ this problem w/ good old regular tan - my default assumption would be that N.tan(N.pi/2) would return N.inf or N.nan, not:
N.tan(N.pi/2) 16331778728383844.0) :-)
DG