NumPy-Discussion July 2008

numpy-discussion@python.org

115 participants
198 discussions

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

chararray __mod__ behavior
by Alan McIntyre 19 Jul '08

19 Jul '08

This seems odd to me: >>> A=np.array([['%.3f','%d'],['%s','%r']]).view(np.chararray) >>> A % np.array([[1,2],[3,4]]) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/local/lib/python2.5/site-packages/numpy/core/defchararray.py", line 126, in __mod__ newarr[:] = res ValueError: shape mismatch: objects cannot be broadcast to a single shape Is this expected behavior? The % gets broadcast as I'd expect for 1D arrays, but more dimensions fail as above. Changing the offending line in defchararray.py to "newarr.flat = res" makes it behave properly.

2 2

← Newer
1
...
6
7
8
9
10
11
12
...
20
Older →

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

NumPy-Discussion July 2008