Wed Jun 10 01:29:16 CDT 2009
On Wed, Jun 10, 2009 at 01:22, David Goldsmith<email@example.com> wrote:
> --- On Tue, 6/9/09, Robert Kern <firstname.lastname@example.org> 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:
> 16331778728383844.0) :-)
Umm, explaining the phenomenon necessarily entails showing examples of
the library functions it applies to. This particular phenomenon is
*about* how the standard, furnished mathematical functions behave,
nothing else. But I don't think a full, explicit list is necessary or
desirable. "Transcendental functions" plus a few notable examples
should cover it.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the Scipy-dev