[Numpy-discussion] ANN: NumPy 1.5.0 beta 2

[Charles R Harris]

On Wed, Aug 18, 2010 at 6:50 AM, Charles R Harris <charlesr.harris@gmail.com
> wrote:

>
>
> On Wed, Aug 18, 2010 at 12:18 AM, Christoph Gohlke <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>> 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>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100818/a7f0230a/attachment-0001.html