Mailman 3 April 2006 - NumPy-Discussion

Can't install numpy-0.9.6-1.i586.rpm on FC5
by Doug Nadworny 26 Apr '06

26 Apr '06

when trying to install numpy-0.9.6-1.i586.rpm on Fedora Core 5, rpm reports incorrectly that python is the incorrect version, even though it is correct: >rpm -i --test numpy-0.9.6-1.i586.rpm ## Tests dependences of rpm package error: Failed dependencies: python-base >= 2.4 is needed by numpy-0.9.6-1.i586 >python -V Python 2.4.2 Is there a way around this? TIA, Doug N

2 1

Possible ref.count bug in changeset #2422
by Pearu Peterson 26 Apr '06

26 Apr '06

Hi, Shouldn't result be Py_INCRE'ted when it is equal to Py_NotImplemented and returned from array_richcompare? Pearu

2 1

obtain indexes of a sort ?
by Simon Burton 26 Apr '06

26 Apr '06

Is it possible to obtain a permutation (array of indices) representing the transform that sorts an array ? Is there a numpy way of doing this ? I can do it in python as: a = [ 6, 5, 99, 2 ] idxs = range(len(a)) z = zip(idxs,a) def zcmp(u,v): if u[1]<=v[1]: return -1 return 1 z.sort( zcmp ) idxs = [u[0] for u in z] # <--- permutation Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

4 3

Building Numpy with Windows and MKL?
by Sungho Hong 26 Apr '06

26 Apr '06

Has anyone tried to install numpy with MS Windows and Intel Math Kernel Library, especially using the VC 2003 compiler? I began with MKLROOT=C:\Program Files\Inter\plsuite, but the setup.py seems to have a problem with finding the library path. In that case, how do manually set up all the relevant paths manually? Thanks. - SH

1 0

Chang*ed* the Trac authentication
by Robert Kern 26 Apr '06

26 Apr '06

Trying not to embarass myself again, I made the changes without telling you. :-) In order to create or modify Wiki pages or tickets on the NumPy and SciPy Tracs, you will have to be logged in. You can register yourself by clicking the "Register" link in the upper right-hand corner of the page. Developers who previously had accounts have the same username/password as before. You can now change your password if you like. Only developers have the ability to close tickets, delete Wiki pages entirely, or create new ticket reports (and possibly a couple of other things). Developers, please enter your name and email by clicking on the "Settings" link up at top once logged in. Thank you for your patience. If there are any problems, please email me, and I will try to correct them quickly. -- Robert Kern robert.kern(a)gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

2 1

vat
by Frida Maldonado 26 Apr '06

26 Apr '06

1 0

SWIG wrappers: Passing NULL pointers or arrays
by Albert Strasheim 25 Apr '06

25 Apr '06

Hello all, I've currently wrapping a C library (libsvm) with NumPy. libsvm has a few structs similiar to the following: struct svm_parameter { double* weight; int nr_weight; }; In my SWIG wrapper I did the following: struct svm_parameter { %immutable; int nr_weight; %mutable; double* weight; %extend { svm_parameter() { struct svm_parameter* param = (struct svm_parameter*) malloc(sizeof(struct svm_parameter)); param->nr_weight = 0; param->weight = 0; return param; } ~svm_parameter() { free(self->weight); free(self); } void _set_weight(double* IN_ARRAY1, int DIM1) { free(self->weight); self->nr_weight = DIM1; self->weight = malloc(sizeof(double) * DIM1); if (!self->weight) { SWIG_exception(SWIG_MemoryError, "OOM"); } memcpy(self->weight, IN_ARRAY1, sizeof(double) * DIM1); return; fail: self->nr_weight = 0; self->weight = 0; } } }; This works pretty well (suggestion welcome though). However, one feature that I think is lacking from the current array typemaps is a way of passing NULL to the C function. On the Python side I want to be able to do: svm_parameter.weight = N.array([1.0,2.0]) or svm_parameter.weight = None This heads off to __setattr__ where the following happens: def __setattr__(self, attr, val): if attr in ['weight', 'weight_label']: set_func = getattr(self, '_set_%s' % (attr,)) set_func(val) else: super(svm_parameter, self).__setattr__(attr, val) At this point the typemap magic kicks in. However, passing a None doesn't work, because somewhere down the line somebody checks for the int argument. The current typemap looks like this: %define TYPEMAP_IN1(type,typecode) %typemap(in) (type* IN_ARRAY1, int DIM1) (PyArrayObject* array=NULL, int is_new_object) { int size[1] = {-1}; array = obj_to_array_contiguous_allow_conversion($input, typecode, &is_new_object); if (!array || !require_dimensions(array,1) || !require_size(array,size,1)) SWIG_fail; $1 = (type*) array->data; $2 = array->dimensions[0]; } %typemap(freearg) (type* IN_ARRAY1, int DIM1) { if (is_new_object$argnum && array$argnum) Py_DECREF(array$argnum); } %enddef I quickly hacked up the following typemap that seems to deal gracefully when a None is passed instead of an array. Changed lines: if ($input == Py_None) { is_new_object = 0; $1 = NULL; $2 = 0; } else { int size[1] = {-1}; array = obj_to_array_contiguous_allow_conversion($input, typecode, &is_new_object); if (!array || !require_dimensions(array,1) || !require_size(array,size,1)) SWIG_fail; $1 = (type*) array->data; $2 = array->dimensions[0]; } Now I can write my set_weight function as follows: void _set_weight(double* IN_ARRAY1, int DIM1) { free(self->weight); self->weight = 0; self->nr_weight = DIM1; if (DIM1 > 0) { self->weight = malloc(sizeof(double) * DIM1); if (!self->weight) { SWIG_exception(SWIG_MemoryError, "OOM"); } memcpy(self->weight, IN_ARRAY1, sizeof(double) * DIM1); } return; fail: self->nr_weight = 0; } Does it make sense to add this to the typemaps? Any other comments? Are there better ways to accomplish this? Regards, Albert

1 0

announce: pyjit, a little jit for creating numpy ufuncs
by Simon Burton 25 Apr '06

25 Apr '06

Hi, Inspired by numexpr, pypy and llvm, i've built a simple JIT for creating numpy "ufuncs" (they are not yet real ufuncs). It uses llvm[1] as the backend machine code generator. The main things it can do are: *) parse simple python code (function def's) *) generate SSA assembly code for llvm *) build ufunc code for applying to numpy array's When I say simple I mean it: def calc(a,b): c = (a+b)/2.0 return c No control flow or type inference has been implemented. As with numexpr, significant speedups are possible. I'm putting this announce here to see what the other numpy'ers think. $ svn co http://rubis.rsise.anu.edu.au/local/repos/elefant/pyjit bye, Simon. [1] http://llvm.org/ -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

3 3

SWIG wrappers: Inplace arrays
by Albert Strasheim 25 Apr '06

25 Apr '06

Hello all I am using the SWIG Numpy typemaps to wrap some C code. I ran into the following problem when wrapping a function with INPLACE_ARRAY1. In Python, I create the following array: x = array([],dtype='<i4') When this is passed to the C function expecting an int*, it goes via obj_to_array_no_conversion in numpy.i where a direct comparison of the typecodes is done, at which point a TypeError is raised. In this case: desired type = int [typecode 5] actual type = long [typecode 7] The typecode is obtained as follows: #define array_type(a) (int)(((PyArrayObject *)a)->descr->type_num) Given that I created the array with '<i4', I would expect type_num to map to int instead of long. Why isn't this happening? Assuming the is a good reason for type_num being what it is, I think obj_to_array_no_conversion needs to be slightly cleverer about the conversions it allows. Is there any way to figure out that int and long are actually identical (at least on my system) using the Numpy C API? Any other suggestions or comments for solving this problem? Thanks! Regards, Albert

2 2

Re: [Numpy-discussion] Broadcasting rules (Ticket 76).
by tim.hochberg＠cox.net 25 Apr '06

25 Apr '06

---- Travis Oliphant <oliphant.travis(a)ieee.org> wrote: > Sasha wrote: > > In this category, I would suggest to allow broadcasting to any > > multiple of the dimension even if the dimension is not 1. I don't see > > what makes 1 so special. > > > What's so special about 1 is that the code for it is relatively > straightforward and already implemented using strides. Altering the > code to allow any multiple of the dimension would be harder and slower. It also does the right thing most of the time and is easy to understand. It's my expectation that oppening up broadcasting will be more effective in masking errors than in enabling useful new behaviour. I think that's my ticket being discussed here. If so, it was motivated by a case that stopped working because the looser broadcasting behaviour was preventing some other broadcasting from taking place. I'm not home right now, so I can't provide details; I'll do that on Thursday. Just keep in mind that it's much easier to keep the broadcasting rules restrictive for now and loosen them up later than to try to tighten them up later if loosening them up turns out to not be a good idea. -tim

1 0