Probably the thing to do for reliable behaviour is to decide on the behaviour we want and then implement it "by hand". I.e., either clear the FP flags inside the ufunc loop (if we decide that log shouldn't raise a warning), or else check for nan and set the invalid flag ourselves. (Checking for nan should be much cheaper than computing log, I think, so this should be okay speed-wise?) On 23 Aug 2013 13:16, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
These things may depend on how the compiler implements various calls. Some errors went the other way with Julian's SIMD work, i.e., errors getting set that were not set before. I'm not sure what can be done about it.
On Thu, Aug 22, 2013 at 8:32 PM, Warren Weckesser < warren.weckesser@gmail.com> wrote:
I'm investigating a test error in scipy 0.13.0 beta 1 that was reported by Christoph Gohlke. The scipy issue is here: https://github.com/scipy/scipy/issues/2771
I don't have a Windows environment to test it myself, but Christoph reported that this code:
``` import numpy as np
data = np.array([-0.375, -0.25, 0.0]) s = np.log(data) ```
does not generate two RuntimeWarnings when it is run with numpy 1.7.1 in a 32 bit Windows 8 environment (numpy 1.7.1 compiled with Visual Studio compilers and Intel's MKL). In 64 bit Windows, and in 64 bit linux, it generates two RuntimeWarnings.
The inconsistency seems like a bug, possibly this one: https://github.com/numpy/numpy/issues/1958.
Can anyone check if this also occurs in the development branch?
ISTR that is can also depend on instruction reordering in the hardware. There was a bug opened on gcc for this a couple of years ago, but I did not have the impression that it was going to get fixed any time soon. Explicitly checking may add noticeable overhead and probably needs to be
On Fri, Aug 23, 2013 at 6:29 AM, Nathaniel Smith <njs@pobox.com> wrote: profiled if we go that way. Chuck