[Numpy-discussion] ANN: NumPy 1.5.0 beta 2
Christoph Gohlke
cgohlke at uci.edu
Thu Aug 19 03:44:23 EDT 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 at gmail.com <mailto:charlesr.harris at gmail.com>> wrote:
>
>
>
> On Wed, Aug 18, 2010 at 12:18 AM, Christoph Gohlke <cgohlke at uci.edu
> <mailto:cgohlke at 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 at uci.edu <mailto:cgohlke at uci.edu>
> > <mailto:cgohlke at uci.edu <mailto:cgohlke at 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 at uci.edu <mailto:cgohlke at uci.edu>
> > <mailto:cgohlke at uci.edu <mailto:cgohlke at uci.edu>>
> > > <mailto:cgohlke at uci.edu <mailto:cgohlke at uci.edu>
> <mailto:cgohlke at uci.edu <mailto:cgohlke at 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