Wed Jun 10 01:22:28 CDT 2009
--- On Tue, 6/9/09, Robert Kern <email@example.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:
More information about the Scipy-dev