On Wed, Aug 18, 2010 at 6:50 AM, Charles R Harris <[email protected] > wrote:
> > > On Wed, Aug 18, 2010 at 12:18 AM, Christoph Gohlke <[email protected]>wrote: > >> >> >> On 8/17/2010 9:56 PM, Charles R Harris wrote: >> > >> > >> > On Tue, Aug 17, 2010 at 9:11 PM, Christoph Gohlke <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > >> > >> > On 8/17/2010 1:02 PM, Charles R Harris wrote: >> > > >> > > >> > > On Tue, Aug 17, 2010 at 1:38 PM, Christoph Gohlke < >> [email protected] >> > <mailto:[email protected]> >> > > <mailto:[email protected] <mailto:[email protected]>>> 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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
