From mdehoon at ims.u-tokyo.ac.jp Wed Mar 5 21:21:15 2003 From: mdehoon at ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon) Date: Wed Mar 5 21:21:15 2003 Subject: [Numpy-discussion] Integrating cephes with numpy Message-ID: <3E66DBAA.2010006@ims.u-tokyo.ac.jp> Hi everybody, You probably all know Travis Oliphant's SpecialFuncs (previously called cephes) module, which contains a large number of special functions. Currently it is not easy to install this module, since SpecialFuncs became a part of SciPy, which is great in itself but cannot be installed easily as other parts of SciPy depend on a host of other packages. As Scipy will get extended in the future, this problem will only get worse. Recently I have been asked several times for such a module for special functions, but I don't know where I can refer people to without qualms, especially for newbies. Since the 'cephes' part of SpecialFuncs is basically an extension of umathmodule.c in numpy, it seems that numpy would be the natural place for cephes. So I would suggest to integrate cephes with numpy, either by adding cephes' special functions to umathmodule.c or as a separate module (similar to the LinearAlgebra or RandomArray parts of numpy). In the process, we can solve some installation problems in cephes which seem to be recurring frequently (see the numpy mailing list for some examples). For the moment, I slapped together a version of the cephes module that can be installed more easily; however, I would think it is better to do this the right way and to avoid multiple variations of basically the same package floating around in cyberspace. Any opinions on this? If this seems like a good idea, I'd be happy to do some additional coding if needed to set this up, though Travis Oliphant has basically done everything already so I wouldn't think much further coding is needed. --Michiel de Hoon, University of Tokyo. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon From pearu at cens.ioc.ee Thu Mar 6 02:21:15 2003 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu Mar 6 02:21:15 2003 Subject: [Numpy-discussion] Integrating cephes with numpy In-Reply-To: <3E66DBAA.2010006@ims.u-tokyo.ac.jp> Message-ID: On Thu, 6 Mar 2003, Michiel Jan Laurens de Hoon wrote: > You probably all know Travis Oliphant's SpecialFuncs (previously called > cephes) module, which contains a large number of special functions. > Currently it is not easy to install this module, since SpecialFuncs > became a part of SciPy, which is great in itself but cannot be installed > easily as other parts of SciPy depend on a host of other packages. As > Scipy will get extended in the future, this problem will only get worse. Scipy subpackage 'special' can be installed standalone from scipy and all its dependencies that are irrelevant for the special package (just cd to scipy/special and do 'python setup_special.py install'). So, there should be no need for looking for a new/another home for cephes wrappers, especially because it would require double-maintaining basically of the same code. Pearu From paul at pfdubois.com Thu Mar 6 06:15:13 2003 From: paul at pfdubois.com (Paul F Dubois) Date: Thu Mar 6 06:15:13 2003 Subject: [Numpy-discussion] Integrating cephes with numpy In-Reply-To: <3E66DBAA.2010006@ims.u-tokyo.ac.jp> Message-ID: <000f01c2e3ea$aa745bc0$6601a8c0@NICKLEBY> FWIW, I am about to create an 'Extras' area in the Numeric cvs repository where non-core, distutils-enabled addons can be put by the numpy developers. These would be things that install as their own packages, not a part of Numeric or Numarray. > -----Original Message----- > From: numpy-discussion-admin at lists.sourceforge.net > [mailto:numpy-discussion-admin at lists.sourceforge.net] On > Behalf Of Michiel Jan Laurens de Hoon > Sent: Wednesday, March 05, 2003 9:25 PM > To: numpy-discussion at lists.sourceforge.net > Subject: [Numpy-discussion] Integrating cephes with numpy > > > Hi everybody, > > You probably all know Travis Oliphant's SpecialFuncs > (previously called > cephes) module, which contains a large number of special functions. > Currently it is not easy to install this module, since SpecialFuncs > became a part of SciPy, which is great in itself but cannot > be installed > easily as other parts of SciPy depend on a host of other packages. As > Scipy will get extended in the future, this problem will only > get worse. > Recently I have been asked several times for such a module > for special > functions, but I don't know where I can refer people to > without qualms, > especially for newbies. > > Since the 'cephes' part of SpecialFuncs is basically an extension of > umathmodule.c in numpy, it seems that numpy would be the > natural place > for cephes. So I would suggest to integrate cephes with > numpy, either by > adding cephes' special functions to umathmodule.c or as a separate > module (similar to the LinearAlgebra or RandomArray parts of > numpy). In > the process, we can solve some installation problems in cephes which > seem to be recurring frequently (see the numpy mailing list for some > examples). > > For the moment, I slapped together a version of the cephes > module that > can be installed more easily; however, I would think it is > better to do > this the right way and to avoid multiple variations of basically the > same package floating around in cyberspace. > > Any opinions on this? If this seems like a good idea, I'd be > happy to do > some additional coding if needed to set this up, though > Travis Oliphant > has basically done everything already so I wouldn't think > much further > coding is needed. > > --Michiel de Hoon, University of Tokyo. > > -- > Michiel de Hoon, Assistant Professor > University of Tokyo, Institute of Medical Science > Human Genome Center > 4-6-1 Shirokane-dai, Minato-ku > Tokyo 108-8639 > Japan > http://bonsai.ims.u-tokyo.ac.jp/~mdehoon > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. Available > on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > From jochen at jochen-kuepper.de Thu Mar 6 08:36:04 2003 From: jochen at jochen-kuepper.de (Jochen =?iso-8859-1?q?K=FCpper?=) Date: Thu Mar 6 08:36:04 2003 Subject: [Numpy-discussion] Integrating cephes with numpy In-Reply-To: <3E66DBAA.2010006@ims.u-tokyo.ac.jp> References: <3E66DBAA.2010006@ims.u-tokyo.ac.jp> Message-ID: <86n0k8tpzc.fsf@doze.rijnh.nl> On Thu, 06 Mar 2003 14:24:58 +0900 Michiel Jan Laurens de Hoon wrote: Michiel> You probably all know Travis Oliphant's SpecialFuncs Michiel> (previously called cephes) module, which contains a large Michiel> number of special functions. The special-funcs of GSL are wrapped in pygsl. Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll From paul at pfdubois.com Thu Mar 6 09:38:37 2003 From: paul at pfdubois.com (Paul Dubois) Date: Thu Mar 6 09:38:37 2003 Subject: [Numpy-discussion] Numeric 23.0 released Message-ID: <000201c2e407$0bb15430$6601a8c0@NICKLEBY> Numeric-23.0.tar.gz is available for download at http://prdownloads.sourceforge.net/numpy/Numeric-23.0.tar.gz?download The Windows zip and exe are ready to upload but I am having trouble with ftp. I will try later today if another developer doesn't beat me to it. A special thanks to all those who contributed bug fixes, especially Travis Oliphant, and all of you bug reporters out there. This is my last release as Head Nummie. The developers will now choose a new victim, er, I mean leader, as set out in our charter. I will still be an active developer and user. I want to thank all of you for your help and civility over the years I have done this job. And thank you to my supervisors over the years at Lawrence Livermore National Laboratory for encouraging me to do it. -- Paul Dubois Here comes the news: Version 23 March 2003 Important notice: Two packages have been removed from optional ones: PropertiedClasses, kinds. MA has been rewritten to use standard property and will not work for ancient Pythons. (Pre 2.1, I think). Use the MA / Propertied Classes from Numeric 22 if you can't use this one. The kinds package (subject of PEP-0242) will be released as a separate package shortly. PEP-0242 was withdrawn because this facility did not seem to be worth putting in the standard library, but kinds is correct as is. [ 695200 ] Richard Everson (R.M.Everson at exeter.ac.uk) has donated a dotblas Package that gets Numeric to use optimized BLAS libraries for dot innerproduct, and vdot --- a conjugate vector dot product he introduced. setup.py must be altered by the user in a manner similar to the alterations to use optimized BLAS for LinearAlgebra [675777] new-style classes as objects in a sequence were not being detected correctly by array_objecttype. Corrected array_objecttype to handle them. (Oliphant) [contribution] Fernando Perez has donated a revised version of the tutorial file view.py that seems to be less likely to hang the interpreter. [68392923] dimensions+scalar -> crash (jneb) Found divergent value of MAX_DIMS in ufuncobject.c; The value was 20 there and 40 in two other places. But 40 is ludicrous, we would never have that much memory available. Changed them all to 30. [ unreported ] Changed PY_VERSION_HEX check for version 2.2 to 0x0202000 as it should have been so that true_division numeric ops can be supported [ 614808 ] Inconsistent use of tabs and spaces Fixed as suggested by Jimmy Retzlaff LinearAlgebra.py Matrix.py RNG/__init__.py RNG/Statistics.py [ 621032 ] needless work in multiarraymodule.c Fixes suggested by Greg Smith applied. Also recoded OBJECT_DotProduct to eliminate a warning error. [ 630584 ] generalized_inverse of complex array Fix suggested by Greg Smith applied. [ 652061 ] PyArray_As2D doesn't check pointer. Fix suggested by Andrea Riciputi applied. [ 655512 ] inverse_real_fft incorrect many sizes Fix given by mbriest applied. [unreported] a.real increased reference count of a and raised error when a is not complex. Fixed to apparent intended behavior of returning an array with the same data. (Oliphant) Patch for 64-bit machines applied. Appears to work ok on 32 bit but don't have the machine to test the patch.(Dubois) [ 627771 ] matrixmultiply broken for non-contig (fixed, test case added) (Greg Smith) [unreported] Fixed ArrayPrinter when NaN's show up in Float32 precision. [ 545336 ] Bug in RandomArray.randint Changed the function ranf to type double (Chuck Harris) Harris is probably right that all floats should be double in this module but it may be this has performance or storage consequences that would bite somebody. I support RNG, not this one. -- Dubois From paul at pfdubois.com Thu Mar 6 13:34:36 2003 From: paul at pfdubois.com (Paul Dubois) Date: Thu Mar 6 13:34:36 2003 Subject: [Numpy-discussion] cvs help? Message-ID: <000001c2e427$e6c89e00$6601a8c0@NICKLEBY> I tried to put the kinds module at cvsroot/numpy/Extras/kinds. I didn't succeed. We now have a cvsroot/numpy/kinds (and an Extras from which I have already removed the contents of kinds after it got installed without the 'kinds' part.) CVS just never has mapped to my brain. I don't get something about it. If another developer knows how to fix this, great. Otherwise that is where it is going to sit. From haase at msg.ucsf.edu Thu Mar 6 16:43:06 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Thu Mar 6 16:43:06 2003 Subject: [Numpy-discussion] Please help - pointer to slice Message-ID: <02ab01c2e442$7abcc040$3b45da80@rodan> Hi, I am using SWIG to wrap some C++ function operating on numarray arrays. Everything works quite well -- up until yesterday... I have some 3d data and was thinking if the actual operation I want to do is done "slice by slice", I could just loop over Z in python and have my C function defined like this: void DoSomething(float * array2d, int nx, int ny) The python loop looks like this: arr = numarray.array(shape=(100,100,100), type=numarray.Float32) for z in range(nz): DoSomething( arr[z] ) SOMEHOW the pointer that get transfered to the C++ side is always the same as for the full (3d) array. if I try to debug this by doing: for z in range(nz): print repr(arr[z]._data) that also tells be that python / numarray thinks all slices are located at the same address, that is: every slice looks just like the full array. Please help, I don't know what to do... Sebastian Haase From falted at openlc.org Thu Mar 6 21:41:09 2003 From: falted at openlc.org (Francesc Alted) Date: Thu Mar 6 21:41:09 2003 Subject: [Numpy-discussion] Please help - pointer to slice In-Reply-To: <02ab01c2e442$7abcc040$3b45da80@rodan> References: <02ab01c2e442$7abcc040$3b45da80@rodan> Message-ID: <200303070640.17799.falted@openlc.org> A Divendres 07 Mar? 2003 01:42, Sebastian Haase va escriure: > if I try to debug this by doing: > for z in range(nz): > print repr(arr[z]._data) > > that also tells be that python / numarray thinks all slices are located at > the same address, that is: > every slice looks just like the full array. You can access the slices by taking into account the byte offset attribute. Look at the next example: In [20]: a=numarray.arange(100, shape=(10,10)) In [21]: a._data Out[21]: In [22]: a[1]._data Out[22]: as you already know, both memory buffers point to the same address. I guess this is implemented in that way so as to not copy data unnecessarily. now, look at: In [23]: a._byteoffset Out[23]: 0 In [24]: a[1]._byteoffset Out[24]: 40 So, you can know where the data actually starts by looking at the _byteoffset property. In fact, you should always look at it in order to get proper results!. In C, you can access to this information by looking at the byteoffset field in the PyArrayObject struct (look at chapter 10 in the User's Manual). Hope that helps, -- Francesc Alted From haase at msg.ucsf.edu Fri Mar 7 11:27:01 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Fri Mar 7 11:27:01 2003 Subject: [Numpy-discussion] Please help - pointer to slice References: <02ab01c2e442$7abcc040$3b45da80@rodan> <200303070640.17799.falted@openlc.org> Message-ID: <02f601c2e4df$72111fc0$3b45da80@rodan> Thanks, SO MUCH ... I almost went crazy yesterday - and was really desperate by the time I wrote that email. Somehow I newer needed that offset field until now. So: when I do the NA_InputArray call I get a "proper" C-array just that it does NOT necessarily start at NAimg->data but rather at NAimg->data + NAimg->byteoffset Again: thanks so much. BTW: Is there general interest in my SWIG typemaps. (SWIG is maybe the easiest way to wrap C/C++ functions (and classes) into Python (and/or Perl, Java, Ruby,...) ? I think especially for numerical stuff, that "link" in of interest. Sebastian ----- Original Message ----- From: "Francesc Alted" To: "Sebastian Haase" ; Sent: Thursday, March 06, 2003 9:40 PM Subject: Re: [Numpy-discussion] Please help - pointer to slice A Divendres 07 Mar? 2003 01:42, Sebastian Haase va escriure: > if I try to debug this by doing: > for z in range(nz): > print repr(arr[z]._data) > > that also tells be that python / numarray thinks all slices are located at > the same address, that is: > every slice looks just like the full array. You can access the slices by taking into account the byte offset attribute. Look at the next example: In [20]: a=numarray.arange(100, shape=(10,10)) In [21]: a._data Out[21]: In [22]: a[1]._data Out[22]: as you already know, both memory buffers point to the same address. I guess this is implemented in that way so as to not copy data unnecessarily. now, look at: In [23]: a._byteoffset Out[23]: 0 In [24]: a[1]._byteoffset Out[24]: 40 So, you can know where the data actually starts by looking at the _byteoffset property. In fact, you should always look at it in order to get proper results!. In C, you can access to this information by looking at the byteoffset field in the PyArrayObject struct (look at chapter 10 in the User's Manual). Hope that helps, -- Francesc Alted From haase at msg.ucsf.edu Fri Mar 7 12:16:27 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Fri Mar 7 12:16:27 2003 Subject: [Numpy-discussion] numarray.fromfunction and Float32 Message-ID: <031a01c2e4e6$6649aa70$3b45da80@rodan> Hi, I am just looking into numarray.fromfuntion. I have e.g. this: def func(x,y,z): return 1.2*(x+y+z) a = na.fromfunction(func, (nz,ny,nx)) b = a.astype(na.Float32) Is there a way to tell fromfunction to _directly_ generate a Float32 typed array. As I see it only "standard" Python type are possible now. Or: Is there a scalar conversion function like numarray.Float32( 3.141 ) ? Thanks, Sebastian Haase From fperez at colorado.edu Fri Mar 7 18:01:04 2003 From: fperez at colorado.edu (Fernando Perez) Date: Fri Mar 7 18:01:04 2003 Subject: [Numpy-discussion] Please help - pointer to slice In-Reply-To: <02f601c2e4df$72111fc0$3b45da80@rodan> References: <02ab01c2e442$7abcc040$3b45da80@rodan> <200303070640.17799.falted@openlc.org> <02f601c2e4df$72111fc0$3b45da80@rodan> Message-ID: <3E694EBE.3080200@colorado.edu> Sebastian Haase wrote: > Thanks, SO MUCH ... > I almost went crazy yesterday - and was really desperate by the time I wrote > that email. > Somehow I newer needed that offset field until now. So: when I do the > NA_InputArray call I get a "proper" C-array > just that it does NOT necessarily start at NAimg->data > but rather at > NAimg->data + NAimg->byteoffset Well, in case you (or others) find it useful, I'm including here a little library I wrote for accessing general Numeric 2-d arrays (contiguous or not) in an easy manner. Here's a snippet of a simple (included) example of a function to print an integer array: static PyObject *idisp(PyObject *self, PyObject *args) { PyArrayObject *array; int **arr; // for the data area int i,j,cs; if (!PyArg_ParseTuple(args, "O!",&PyArray_Type,&array ) ) return NULL; arr = imatrix_data(array,&cs); for (i=0;idimensions[0];++i) { for (j=0;jdimensions[1];j+=cs) printf("%5d ",arr[i][j]); printf("\n"); } free(arr); Py_INCREF(Py_None); return Py_None; } You get the **arr pointer and you can then manipulate it as a[i][j] conveniently. The supplied example file may be enough for many to write their Numpy C extensions without much trouble. > Again: thanks so much. > BTW: Is there general interest in my SWIG typemaps. (SWIG is maybe the > easiest way to wrap C/C++ functions (and classes) > into Python (and/or Perl, Java, Ruby,...) ? I think especially for > numerical stuff, that "link" in of interest. I'd love to see them. So far I've either used high-level stuff like weave.inline() or just written the extensions by hand (as in the code I'm supplying here). I'd like to see this, especially if there is an easy way to handle contiguity issues with it. Best, f. -------------- next part -------------- A non-text attachment was scrubbed... Name: libnumpy-access.tgz Type: application/x-gzip Size: 4516 bytes Desc: not available URL: From jmiller at stsci.edu Sat Mar 8 03:56:06 2003 From: jmiller at stsci.edu (Todd Miller) Date: Sat Mar 8 03:56:06 2003 Subject: [Numpy-discussion] numarray.fromfunction and Float32 References: <031a01c2e4e6$6649aa70$3b45da80@rodan> Message-ID: <3E69DE61.4080604@stsci.edu> Sebastian Haase wrote: >Hi, >I am just looking into numarray.fromfuntion. >I have e.g. this: > >def func(x,y,z): > return 1.2*(x+y+z) > >a = na.fromfunction(func, (nz,ny,nx)) >b = a.astype(na.Float32) > >Is there a way to tell fromfunction to _directly_ generate a Float32 typed >array. > I don't think so. Numeric does not have this capability either, although it appears easy enough to add it. >As I see it only "standard" Python type are possible now. >Or: Is there a scalar conversion function like numarray.Float32( 3.141 ) ? > You can create rank-0 numarrays which are essentially typed scalars; these are not, however, widely used. >>> import numarray >>> a = numarray.array(3.141, type=numarray.Float32) > >Thanks, >Sebastian Haase > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger >for complex code. Debugging C/C++ programs can leave you feeling lost and >disoriented. TotalView can help you find your way. Available on major UNIX >and Linux platforms. Try it free. www.etnus.com >_______________________________________________ >Numpy-discussion mailing list >Numpy-discussion at lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > From jmiller at stsci.edu Sat Mar 8 04:02:01 2003 From: jmiller at stsci.edu (Todd Miller) Date: Sat Mar 8 04:02:01 2003 Subject: [Numpy-discussion] Please help - pointer to slice References: <02ab01c2e442$7abcc040$3b45da80@rodan> <200303070640.17799.falted@openlc.org> <02f601c2e4df$72111fc0$3b45da80@rodan> Message-ID: <3E69DFA1.7080908@stsci.edu> Sebastian Haase wrote: >Thanks, SO MUCH ... >I almost went crazy yesterday - and was really desperate by the time I wrote >that email. >Somehow I newer needed that offset field until now. So: when I do the >NA_InputArray call I get a "proper" C-array >just that it does NOT necessarily start at NAimg->data >but rather at >NAimg->data + NAimg->byteoffset > > The numarray-0.4 manual (available at: http://prdownloads.sourceforge.net/numpy/numarray-0.4.pdf?download) documents how to write Python stubs using the "high level" API on Page 70. The thing you appear to be missing is a call to NA_OFFSETDATA which gets a pointer to the data in an array by adding the buffer pointer and byteoffset together. Todd >Again: thanks so much. >BTW: Is there general interest in my SWIG typemaps. (SWIG is maybe the >easiest way to wrap C/C++ functions (and classes) >into Python (and/or Perl, Java, Ruby,...) ? I think especially for >numerical stuff, that "link" in of interest. > >Sebastian > > >----- Original Message ----- >From: "Francesc Alted" >To: "Sebastian Haase" ; > >Sent: Thursday, March 06, 2003 9:40 PM >Subject: Re: [Numpy-discussion] Please help - pointer to slice > > >A Divendres 07 Mar? 2003 01:42, Sebastian Haase va escriure: > > >>if I try to debug this by doing: >>for z in range(nz): >> print repr(arr[z]._data) >> >>that also tells be that python / numarray thinks all slices are located at >>the same address, that is: >>every slice looks just like the full array. >> >> > >You can access the slices by taking into account the byte offset >attribute. Look at the next example: > >In [20]: a=numarray.arange(100, shape=(10,10)) > >In [21]: a._data >Out[21]: > >In [22]: a[1]._data >Out[22]: > >as you already know, both memory buffers point to the same address. I guess >this is implemented in that way so as to not copy data unnecessarily. > >now, look at: > >In [23]: a._byteoffset >Out[23]: 0 > >In [24]: a[1]._byteoffset >Out[24]: 40 > >So, you can know where the data actually starts by looking at the >_byteoffset property. In fact, you should always look at it in order to get >proper results!. > >In C, you can access to this information by looking at the byteoffset field >in the PyArrayObject struct (look at chapter 10 in the User's Manual). > >Hope that helps, > >-- >Francesc Alted > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger >for complex code. Debugging C/C++ programs can leave you feeling lost and >disoriented. TotalView can help you find your way. Available on major UNIX >and Linux platforms. Try it free. www.etnus.com >_______________________________________________ >Numpy-discussion mailing list >Numpy-discussion at lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > From haase at msg.ucsf.edu Mon Mar 10 12:33:35 2003 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Mon Mar 10 12:33:35 2003 Subject: [Numpy-discussion] Please help - pointer to slice References: <02ab01c2e442$7abcc040$3b45da80@rodan> <200303070640.17799.falted@openlc.org> <02f601c2e4df$72111fc0$3b45da80@rodan> <3E694EBE.3080200@colorado.edu> Message-ID: <017501c2e744$30e0dab0$3b45da80@rodan> > Well, in case you (or others) find it useful, I'm including here a little > library I wrote for accessing general Numeric 2-d arrays (contiguous or not) > in an easy manner. > > Here's a snippet of a simple (included) example of a function to print an > integer array: > > static PyObject *idisp(PyObject *self, PyObject *args) > { > PyArrayObject *array; > int **arr; // for the data area > int i,j,cs; > > if (!PyArg_ParseTuple(args, "O!",&PyArray_Type,&array ) ) > return NULL; > > arr = imatrix_data(array,&cs); > for (i=0;idimensions[0];++i) { > for (j=0;jdimensions[1];j+=cs) > printf("%5d ",arr[i][j]); > printf("\n"); > } > free(arr); > > Py_INCREF(Py_None); > return Py_None; > } > > You get the **arr pointer and you can then manipulate it as a[i][j] > conveniently. The supplied example file may be enough for many to write their > Numpy C extensions without much trouble. > > > Again: thanks so much. > > BTW: Is there general interest in my SWIG typemaps. (SWIG is maybe the > > easiest way to wrap C/C++ functions (and classes) > > into Python (and/or Perl, Java, Ruby,...) ? I think especially for > > numerical stuff, that "link" in of interest. > > I'd love to see them. So far I've either used high-level stuff like > weave.inline() or just written the extensions by hand (as in the code I'm > supplying here). I'd like to see this, especially if there is an easy way to > handle contiguity issues with it. You are using Numeric not numarray , right? In any case : My thinking goes as follows: I was looking for a wrapping-solution that would be most transparent to the people that would write the C/C++ code (or even Fortran, BTW) Since I already had some experience using SWIG, that's what I wanted to use to handle the "numarray binding". SWIG has a quite strong (meaning: flexible, general) way of handling data types. They call it "type maps": Once you have that in place (later more) the whole "binding" looks like this: (an example) C side: double sebFunc(float *arr, int nx, int ny, int nz) { double a =0; for(int i=0;i