[Numpy-discussion] ANN: NumPy 1.5.0 beta 2

Christoph Gohlke cgohlke@uci....
Thu Aug 19 02:44:23 CDT 2010



On 8/18/2010 6:00 AM, Charles R Harris wrote:
>
>
> On Wed, Aug 18, 2010 at 6:50 AM, Charles R Harris
> <charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>> wrote:
>
>
>
>     On Wed, Aug 18, 2010 at 12:18 AM, Christoph Gohlke <cgohlke@uci.edu
>     <mailto:cgohlke@uci.edu>> wrote:
>
>
>
>         On 8/17/2010 9:56 PM, Charles R Harris wrote:
>         >
>         >
>         >  On Tue, Aug 17, 2010 at 9:11 PM, Christoph Gohlke
>         <cgohlke@uci.edu <mailto:cgohlke@uci.edu>
>         >  <mailto:cgohlke@uci.edu <mailto:cgohlke@uci.edu>>> wrote:
>         >
>         >
>         >
>         >      On 8/17/2010 1:02 PM, Charles R Harris wrote:
>         >  >
>         >  >
>         >  >  On Tue, Aug 17, 2010 at 1:38 PM, Christoph Gohlke
>         <cgohlke@uci.edu <mailto:cgohlke@uci.edu>
>         >  <mailto:cgohlke@uci.edu <mailto:cgohlke@uci.edu>>
>         >  > <mailto:cgohlke@uci.edu <mailto:cgohlke@uci.edu>
>         <mailto:cgohlke@uci.edu <mailto:cgohlke@uci.edu>>>> wrote:
>         >  >
>         >  >
>         >  >
>         >  >      On 8/17/2010 8:23 AM, Ralf Gommers wrote:
>         >  >
>         >  >          I am pleased to announce the availability of the second
>         >      beta of
>         >  >          NumPy
>         >  >          1.5.0. This will be the first NumPy release to include
>         >      support for
>         >  >          Python 3, as well as for Python 2.7.
>         >  >
>         >  >          Please try this beta and report any problems on the
>         NumPy
>         >  >          mailing list.
>         >  >          Especially with Python 3 testing will be very
>         useful. On Linux
>         >  >          and OS X
>         >  >          building from source should be straightforward, for
>         >      Windows a binary
>         >  >          installer is provided. There is one important known
>         issue
>         >      on Windows
>         >  >          left, in fromfile and tofile (ticket 1583).
>         >  >
>         >  >          Binaries, sources and release notes can be found at
>         >  > https://sourceforge.net/projects/numpy/files/
>         >  > <https://sourceforge.net/projects/numpy/files/>
>         >  >
>         >  >          Enjoy,
>         >  >          Ralf
>         >  >
>         >  >
>         >  >      NumPy 1.5.0 beta 2 built with msvc9/mkl for Python 2.7
>         and 3.1 (32
>         >  >      and 64 bit) still reports many (> 200) warnings and three
>         >      known test
>         >  >      failures/errors. Nothing serious, but it would be nice
>         to clean up
>         >  >      before the final release.
>         >  >
>         >  >      The warnings are of the type "Warning: invalid value
>         >      encountered in"
>         >  >      for the functions reduce, fmax, fmin, logaddexp,
>         maximum, greater,
>         >  >      less_equal, greater_equal, absolute, and others. I do
>         not see
>         >      any of
>         >  >      these warnings in the msvc9 builds of numpy 1.4.1.
>         >  >
>         >  >
>         >  >  The warnings were accidentally turned off for earlier
>         versions of
>         >      Numpy.
>         >  >  I expect these warnings are related to nans and probably due to
>         >      problems
>         >  >  with isnan or some such. Can you take a closer look? The
>         fmax function
>         >  >  should be easy to check out.
>         >  >
>         >  > <sniip>
>         >  >
>         >  >  Chuck
>         >  >
>         >
>         >
>         >      Thanks for the hint. Warnings are issued in the test_umath
>         test_*nan*
>         >      functions. The problem can be condensed to this statement:
>         >
>         >  > >> numpy.array([numpy.nan]) > 0
>         >      Warning: invalid value encountered in greater
>         >      array([False], dtype=bool)
>         >
>         >
>         >      When using msvc, ordered comparisons involving NaN raise
>         an exception
>         >      [1], i.e. set the 'invalid' x87 status bit, which leads to
>         the warning
>         >      being printed. I don't know if this violates IEEE 754 or
>         C99 standards
>         >      but it does not happen with the gcc builds. Maybe
>         >      seterr(invalid='ignore') could be added to the test_*nan*
>         functions?
>         >
>         >      [1]
>         http://msdn.microsoft.com/en-us/library/e7s85ffb%28v=VS.90%29.aspx
>         >
>         >
>         >  OK, this does seem to be the standard. For instance
>         >
>         >  The isless macro determines whether its first argument is less
>         than its
>         >  second
>         >  argument. The value of isless(x, y) is always equal to (x) <
>         (y); however,
>         >  unlike (x) < (y), isless(x, y) does not raise the ‘‘invalid’’
>         floating-point
>         >  exception when x and y are unordered.
>         >
>         >  There are other macros for the rest of the comparisons. Can
>         you check if
>         >  MSVC has these macros available?
>         >
>
>         MSVC doesn't have these macros. It should not be too difficult
>         to define
>         them according to
>         http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/platform-win32.cc
>
>         int isless(double x, double y) {
>            return isnan(x) || isnan(y) ? 0 : x < y;
>         }
>
>
>         int isgreater(double x, double y) {
>            return isnan(x) || isnan(y) ? 0 : x > y;
>         }
>
>
>     Looks like we should just rewrite the ufuncs. Having these checks
>     will slow things down a bit but it is probably the easiest way to
>     make things portable without doing a lot of complicated work to
>     determine what the platform does. However, this means that numpy
>     won't ever set exceptions when nans are encountered and this is a
>     design decision we should make up front.
>
>
> Thinking about it a bit more, I don't think we should fix the
> comparisons, rather we should fix the tests to ignore the warnings.
> OTOH, since we already have defined behaviors for max/min/fmax/fmin
> maybe we should fix those functions. Or maybe not, since warning on
> invalid values is orthogonal to what we do with them. Hmm...
>
> Chuck
>

I opened a ticket and attached a patch that silences the warnings during 
the tests.

http://projects.scipy.org/numpy/ticket/1587

--
Christoph


More information about the NumPy-Discussion mailing list