Mailman 3 July 2008 - NumPy-Discussion

Ticket #794 and can o' worms.
by Charles R Harris 20 Jul '08

20 Jul '08

Hi All, I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here<http://thread.gmane.org/gmane.comp.python.numeric.general/21526/focus=21537>. The problems that arise come from conversion to different types. In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.]) In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1]) In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool) In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.]) In [30]: bool(NaN) Out[30]: True So there are problems with at minimum the following. 1) The way NaN is converted to bool. I think it should be False. 2) The way NaN is converted to int types. I think it should be 0. These problems show up in failing tests. I'm reverting the fix for now, but I wonder what we should do about these things. Chuck

3 6

Testing: Failed examples don't raise errors on buildbot.
by Charles R Harris 20 Jul '08

20 Jul '08

Alan, Stefan Not raising errors seems ok for examples, but some of the unit tests are also implemented as doctests and the failures are hidden in the logs. I'm not sure what to do about this, but thought it worth pointing out. Also, it would be nice if skipped tests didn't generate large bits of printout, it makes it hard to find relevant failures. Chuck

4 8

Dealing with NAN.
by Charles R Harris 20 Jul '08

20 Jul '08

The NAN macro isn't defined on all platforms and we have various workarounds scattered here and there. Is it reasonable to determine a suitable value of NAN for the various float types as part of the initial setup and configuration and have the results appended to one of the include files? This shouldn't be difficult for the gnu compilers, but might be a hassle for MSVC and some of the others. It can be hardwired into MSVC if we assume the Intel architecture. Chuck

1 0

MSVC warnings.
by Charles R Harris 20 Jul '08

20 Jul '08

The Windows_XP buildbot shows several warnings about npy_intp -> int conversions. Two of them look OK, but probably explicit casts should be made. The third is: numpy\core\src\ufuncobject.c(2422) : warning C4244: '=' : conversion from 'npy_intp' to 'int', possible loss of data Which looks possibly legitimate to me. Unfortunately, it looks like fixing it involves a change in the loop type. Chuck

1 0

Ticket review: #848, leak in PyArray_DescrFromType
by Michael Abbott 20 Jul '08

20 Jul '08

Only half of my patch for this bug has gone into trunk, and without the rest of my patch there remains a leak. Furthermore, it remains necessary to perform an extra INCREF on typecode before calling PyArray_FromAny ... as otherwise there is the real possibility that typecode will have evaporated by the time it's passed to scalar_value later down in the routine. I attach the patch I believe remains necessary against this routine: --- numpy/core/src/scalartypes.inc.src (revision 5411) +++ numpy/core/src/scalartypes.inc.src (working copy) @@ -1925,19 +1925,30 @@ goto finish; } + Py_XINCREF(typecode); arr = PyArray_FromAny(obj, typecode, 0, 0, FORCECAST, NULL); - if ((arr==NULL) || (PyArray_NDIM(arr) > 0)) return arr; + if ((arr==NULL) || (PyArray_NDIM(arr) > 0)) { + Py_XDECREF(typecode); + return arr; + } robj = PyArray_Return((PyArrayObject *)arr); finish: - if ((robj==NULL) || (robj->ob_type == type)) return robj; + if ((robj==NULL) || (robj->ob_type == type)) { + Py_XDECREF(typecode); + return robj; + } /* Need to allocate new type and copy data-area over */ if (type->tp_itemsize) { itemsize = PyString_GET_SIZE(robj); } else itemsize = 0; obj = type->tp_alloc(type, itemsize); - if (obj == NULL) {Py_DECREF(robj); return NULL;} + if (obj == NULL) { + Py_XDECREF(typecode); + Py_DECREF(robj); + return NULL; + } if (typecode==NULL) typecode = PyArray_DescrFromType(PyArray_@TYPE@); dest = scalar_value(obj, typecode); I can see that there might be an argument that PyArray_FromAny has the semantics that it retains a reference to typecode unless it returns NULL ... but I don't want to go there. That would not be a good thing to rely on -- and even with those semantics the existing code still needs fixing.

6 27

arccosh for complex numbers, goofy choice of branch
by Charles R Harris 20 Jul '08

20 Jul '08

OK, Which branch do we want to use. As it currently is in numpy and scipy.special arccosh(1.5) = 0.96242365011920694 arccosh(1.5+0j) = -0.96242365011920705 + 0.0j This is consistent with gsl, but inconsistent with Mathematica, NAG, Maple, and probably all sensible implementations which use the generally accepted principal value. I've left this inconsistency raising an error in the ufunc tests until we make a decision. It might be nice to know what FORTRAN and MatLab do with this. Chuck

7 16

Backport r5452?
by Charles R Harris 19 Jul '08

19 Jul '08

Robert, Is there any reason I shouldn't backport your build fixes? Chuck

2 1

Masked array fill_value
by Ryan May 19 Jul '08

19 Jul '08

Hi, I just noticed this and found it surprising: In [8]: from numpy import ma In [9]: a = ma.array([1,2,3,4],mask=[False,False,True,False],fill_value=0) In [10]: a Out[10]: masked_array(data = [1 2 -- 4], mask = [False False True False], fill_value=0) In [11]: a[2] Out[11]: masked_array(data = --, mask = True, fill_value=1e+20) In [12]: np.__version__ Out[12]: '1.1.0' Is there a reason that the fill_value isn't inherited from the parent array? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma

3 3

Buildbot errors on Windows_XP.
by Charles R Harris 19 Jul '08

19 Jul '08

Memmap problems. Chuck

1 0

ticket #842.
by Charles R Harris 19 Jul '08

19 Jul '08

Just wanted to bring attention to ticket #842<http://projects.scipy.org/scipy/numpy/ticket/842>because I think the fix should be pretty easy. I added a comment: The printing inconsistency is a duplicate of #841<http://projects.scipy.org/scipy/numpy/ticket/841>and has been fixed. What remains odd is that the conjugate is a scalar not an array. In [2]: type(conjugate(array(8+7j))) Out[2]: <type 'numpy.complex128'> In [3]: type((array(8+7j))) Out[3]: <type 'numpy.ndarray'> So I think all that needs to be done is fix the return type conjugate if we agree that it should be an array. Chuck

3 2