Mailman 3 July 2006 - NumPy-Discussion

Please comment on SVN versioning convention
by Travis Oliphant 24 Jul '06

24 Jul '06

Andrew Straw has emphasized that the current strategy of appending the SVN version number to development versions of the SVN tree makes it hard to do version sorting. His proposal is to not change the version number until the first beta comes out. In other words, the trunk should not be 1.1 but 1.0dev? Are there any opposing opinions to this change. I personally think that is a confusing numbering scheme because 1.0dev seems to imply it's the development for version 1.0 instead of 1.1. But, if several others think it's a good idea to support easy-sorting of version numbers, then I will conceed. Perhaps we can have a version 'number' as 1.0plus? -Travis

6 11

matrix-related bug in 1.0b1
by Sven Schreiber 24 Jul '06

24 Jul '06

Hi, Summary: Slicing seems to be broken with matrices now. I eagerly installed the new beta, but soon stumbled over this bug. I hope I'm missing something, but afaics that behavior used to be different (and correct) before in 0.9.8. Don't know exactly when this changed, though. I did a fresh install (uninstalled old numpy and also matplotlib first) of the official binary for windows/python 2.4. Example: >>> import numpy as n >>> n.__version__ '1.0b1' >>> import numpy.matlib as m >>> a = n.zeros((2,3)) >>> b = m.zeros((2,3)) >>> a[:1,:].shape (1, 3) >>> b[:1,:].shape (3, 1) >>> Note the array slicing works correct, but the equivalent thing with the matrix does not. I also noticed the following (in a new python session) import strangeness: >>> import numpy >>> numpy.matlib.zeros((2,3)) Traceback (most recent call last): File "<interactive input>", line 1, in ? AttributeError: 'module' object has no attribute 'matlib' >>> Why is the direct access to matlib impossible? Either I'm missing something (I well may be, because I'm melting away at 36 centigrades or so...), or imho a new beta should be put out quickly to enable further testing (and use). Thanks, Sven

3 5

numpy.prod() vs. numpy.product()
by Sebastian Haase 24 Jul '06

24 Jul '06

Hi, Are numpy.product() and numpy.prod() doing the exact same thing ? If yes, why are they pointing to two different functions ? >>> N.prod <function prod at 0x43cef56c> >>> N.product <function product at 0x43cef304> Thanks, Sebastian Haase

2 1

Fresh svn numpy install fails 2 tests (OS X)
by Steve Lianoglou 24 Jul '06

24 Jul '06

Hi folks, Since 1.0 release is eminent, I just wanted to draw the attention to two failures I get when I run numpy.test(1). I've never been able to get numpy to pass all test cases, but now it fails a second one, so .. I'm pasting it below. Please let me know if these are non-consequential. System info: + Intel Mac (MacBook Pro) + OS X.4.7 + numpy version: 1.0.2881 test failures: FAIL: check_large_types (numpy.core.tests.test_scalarmath.test_power) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/local/lib/python2.4/site-packages/numpy/core/tests/ test_scalarmath.py", line 47, in check_large_types assert b == 6765201, "error with %r: got %r" % (t,b) AssertionError: error with <type 'float128scalar'>: got 0.0 ====================================================================== FAIL: check_types (numpy.core.tests.test_scalarmath.test_types) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/local/lib/python2.4/site-packages/numpy/core/tests/ test_scalarmath.py", line 20, in check_types assert a == 1, "error with %r: got %r" % (atype,a) AssertionError: error with <type 'float128scalar'>: got 1.02604810941480982577e-4936 ---------------------------------------------------------------------- Ran 468 tests in 1.157s FAILED (failures=2) Out[2]: <unittest.TextTestRunner object at 0x15e3510> ---------------------------------------- Thanks, -steve

2 1

SVN changes that need to go into 1.0 and 1.1
by Travis Oliphant 24 Jul '06

24 Jul '06

For the next several months until 1.0 comes out. Please make changes that go into 1.0 to the ver1.0 branch of the NumPy SVN tree. Then, periodically, we can merge those changes back to the trunk for ver 1.1 -Travis

1 0

Re: [Numpy-discussion] how add new attribute to a numpy array object ?
by Sebastian Haase 24 Jul '06

24 Jul '06

On Monday 24 July 2006 12:23, Travis Oliphant wrote: > Sebastian Haase wrote: > > Hi, > > I have a (medical) image file. > > I wrote a nice interface based on memmap using numarray. > > The class design I used was essentially to return a numarray array > > object with a new "custom" attribute giving access to special > > information about the base file. > > > > Now with numpy I noticed that a numpy object does not allow adding new > > attributes !! (How is this ? Why ?) > > > > Travis already suggested (replying to one of my last postings) to create > > a new sub class of numpy.ndarray. > > > > But how do I initialize an object of my new class to be "basically > > identically to" an existing ndarray object ? > > Normally I could do > > class B(N.ndarray): > > pass > > a=N.arange(10) > > a.__class__ = B > > > > BUT I get this error: > > #>>> a.__class__ = B > > Traceback (most recent call last): > > File "<input>", line 1, in ? > > TypeError: __class__ assignment: only for heap types > > > > What is a "heap type" ? Why ? How can I do what I want ? > > A heap type is one created in Python (i.e. not builtin with C). > > You should be able to do > > a = a.view(B) > > -Travis Thanks - (I'm just replying because I assume your helpful answer was mistakenly sent to me only and did not make it to the list)

1 0

C extensions: is Py_XDECREF() needed when using PyArray_FromAny()
by Sebastian Haase 24 Jul '06

24 Jul '06

Hi, I'm converting SWIG typemap'ed C extensions from numarray to numpy. I studied (and use parts of) numpy.i from the doc directory. I noticed that there is no decref for the TYPEMAP_INPLACE2 typemap. This uses a function obj_to_array_no_conversion() which in turn just returns the original PyObject* ( casted to a PyArrayObject* after some sanity checks) It looks to me that in this case there should be an explicit Py_INCREF() - in case the function is threaded (releases the Python GIL) since it holds a pointer to that object's data . (Alternatively) Travis suggested (at the http://www.scipy.org/Converting_from_numarray wiki page) using PyArray_FromAny - is this incrementing the ref.count (implicitely) ? The numarray equivalent (NA_InputArray) IS incrementing the ref.count (as far as I know...). Furthermore on that same wiki page the PyArray_FromAny() is called together with PyArray_DescrFromType(<type>). After searching through the numpy source I found that in blasdot/_dotblas.c (in dotblas_matrixproduct() )there is an explicit Py_INCREF even on the dtype returned from PyArray_DescrFromType. I would argue that ref.counting is always very tricky territory ;-) Hopefully someone can enlighten me . Thanks, Sebastian Haase

2 1

bug in numpy recarray ?
by Sebastian Haase 24 Jul '06

24 Jul '06

Hi! I'm trying to convert my numarray records code to numpy. >>> type(m.hdrArray) <class 'numpy.core.records.recarray'> >>> m.hdrArray.d [(array([ 1., 1., 1.], dtype=float32),)] but I get: >>> m.hdrArray[0].getfield('d') 5.43230922614e-312 Am I missing something or is this a bug ? Further details: >>> m.hdrArray.dtype.descr [('Num', [('f1', '<i4', 3)]), ('PixelType', [('f1', '<i4')]), ('mst', [('f1', '<i4', 3)]), ('m', [('f1', '<i4', 3)]), ('d', [('f1', '<f4', 3)]), ####!!!! ('angle', [('f1', '<f4', 3)]), ('axis', [('f1', '<i4', 3)]), ('mmm1', [('f1', '<f4', 3)]), ('type', [('f1', '<i2')]), ('nspg', [('f1', '<i2')]), ('next', [('f1', '<i4')]), ('dvid', [('f1', '<i2')]), ('blank', [('f1', '|i1', 30)]), ('NumIntegers', [('f1', '<i2')]), ('NumFloats', [('f1', '<i2')]), ('sub', [('f1', '<i2')]), ('zfac', [('f1', '<i2')]), ('mm2', [('f1', '<f4', 2)]), ('mm3', [('f1', '<f4', 2)]), ('mm4', [('f1', '<f4', 2)]), ('ImageType', [('f1', '<i2')]), ('LensNum', [('f1', '<i2')]), ('n1', [('f1', '<i2')]), ('n2', [('f1', '<i2')]), ('v1', [('f1', '<i2')]), ('v2', [('f1', '<i2')]), ('mm5', [('f1', '<f4', 2)]), ('NumTimes', [('f1', '<i2')]), ('ImgSequence', [('f1', '<i2')]), ('tilt', [('f1', '<f4', 3)]), ('NumWaves', [('f1', '<i2')]), ('wave', [('f1', '<i2', 5)]), ('zxy0', [('f1', '<f4', 3)]), ('NumTitles', [('f1', '<i4')]), ('title', [('f1', '|S80', 10)])] >>> >>> >>> m.hdrArray[0].dtype.descr [('Num', [('f1', '<i4', 3)]), ('PixelType', [('f1', '<i4')]), ('mst', [('f1', '<i4', 3)]), ('m', [('f1', '<i4', 3)]), ('d', [('f1', '<f4', 3)]), ####!!!! ('angle', [('f1', '<f4', 3)]), ('axis', [('f1', '<i4', 3)]), ('mmm1', [('f1', '<f4', 3)]), ('type', [('f1', '<i2')]), ('nspg', [('f1', '<i2')]), ('next', [('f1', '<i4')]), ('dvid', [('f1', '<i2')]), ('blank', [('f1', '|i1', 30)]), ('NumIntegers', [('f1', '<i2')]), ('NumFloats', [('f1', '<i2')]), ('sub', [('f1', '<i2')]), ('zfac', [('f1', '<i2')]), ('mm2', [('f1', '<f4', 2)]), ('mm3', [('f1', '<f4', 2)]), ('mm4', [('f1', '<f4', 2)]), ('ImageType', [('f1', '<i2')]), ('LensNum', [('f1', '<i2')]), ('n1', [('f1', '<i2')]), ('n2', [('f1', '<i2')]), ('v1', [('f1', '<i2')]), ('v2', [('f1', '<i2')]), ('mm5', [('f1', '<f4', 2)]), ('NumTimes', [('f1', '<i2')]), ('ImgSequence', [('f1', '<i2')]), ('tilt', [('f1', '<f4', 3)]), ('NumWaves', [('f1', '<i2')]), ('wave', [('f1', '<i2', 5)]), ('zxy0', [('f1', '<f4', 3)]), ('NumTitles', [('f1', '<i4')]), ('title', [('f1', '|S80', 10)])] Thanks, Sebastian Haase

2 1

Re: [Numpy-discussion] numpy 1.0
by Travis Oliphant 24 Jul '06

24 Jul '06

Graham Cummins wrote: > Greetings, > > I just downloaded numpy 1.0b1. I see a lot of changes from 0.9.8, and > I'm curious as to whether these changes will be a lasting property of > numpy 1.0 and later. > > Most of the changes relate to nomenclature for type constants (e.g. > int32, complex128, newaxis) and functions (e.g. inverse_real_fft -> > ifft). Although it takes some time to comb through code for all of the > possible name changes (there are lots!), it's easy enough to do. Release notes will be forthcoming. These changes will be lasting... What changed is that "old" names were placed only in a compatibility module (numpy.oldnumeric). Import from there if you want the old names (convertcode was also changed to alter Numeric-->numpy.oldnumeric. This was done so as to make it clearer what is "old" and for compatibility purposes only and what new code should be written with. > > The thing that is taking me longer is (as usual) converting c > extensions. Float32, and PyArray_Float32 used to be defined in 0.9.8, > and are now not. AFAICT, npy_float works in the same way Float32 used > to work, but I haven't yet figured out what to use in place of > PyArray_Float32 in, for example "PyArray_FROM_OTF(data, ?? , ALIGNED | > CONTIGUOUS);" > Here, we assigned the prefixes NPY_ and npy_ to all the old CAPITALIZED and uncapitalized names, respectively to avoid the problem of name clashes which occurs commonly when using NumPy to wrap another library. The un-prefixed names are still available when you use #include "numpy/noprefix.h" (which is what NumPy itself uses). > > On another topic, when I install numpy (version 0.9.8 or 1.0b1) using > "seutup.py install", the headers needed to build extensions don't get > moved into my python distribution directory tree. I've been moving > these files by hand, and that seems to work, but could I pass some > argument to distutils that would do this automatically? To support multiple-version installations of NumPy (like eggs allow) it's important to put the headers in their own location and not in a system-wide directory. If you want to place them system-wide, you currently need to copy them by hand. But, it's not recommended to do that. Just append the output of numpy.get_include() to the list of include directories. -Travis

1 0

to yarec
by Jordana Hollingshead 24 Jul '06

24 Jul '06

Bes k t S v el s li y ng W v atc u he h s R y OL j EX C y ART f IER BR e EI y TLIN k G BV p LGA q RI OM g EG z A P v ATE z K P x hilip h pe and man o y othe f r Han a dbag r s & Pu p rs w es, TI k FFA l NY & CO Je m werl t y Or z de v r T j ODA c Y and sav k e 2 o 5 % http://righttherehun.com share of the reward. And so Bilbo was swung down from the wall, and departed with nothing for all his trouble, except the armour which Thorin had given him already. More than one of the dwarves in their hearts felt shame and pity at his going. Farewell! he cried to them. We may meet again as friends. Be off! called Thorin. You have mail upon you, which was

1 0