Mailman 3 May 2011 - NumPy-Discussion

re turning a tuple of arrays with apply_along_axis
by Pedro G 07 May '11

07 May '11

Hello, I'm trying to use apply_along_axis with a function that returns 2 arrays, but I always get different error messages. For example, here is a test: >>> from numpy import * >>> def f(x): ... a = array([1, 2, 3], dtype=float) ... b = array([4, 5, 6], dtype=float) ... return (a, b) ... >>> x = arange(60).reshape(5, 4, 3) >>> x array([[[ 0, 1, 2], [ 3, 4, 5], [ 6, 7, 8], [ 9, 10, 11]], [[12, 13, 14], [15, 16, 17], [18, 19, 20], [21, 22, 23]], [[24, 25, 26], [27, 28, 29], [30, 31, 32], [33, 34, 35]], [[36, 37, 38], [39, 40, 41], [42, 43, 44], [45, 46, 47]], [[48, 49, 50], [51, 52, 53], [54, 55, 56], [57, 58, 59]]]) >>> f(1) (array([ 1., 2., 3.]), array([ 4., 5., 6.])) >>> f(array([1, 5, 9])) (array([ 1., 2., 3.]), array([ 4., 5., 6.])) >>> a, b = apply_along_axis(f, 0, x) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python3.2/dist-packages/numpy/lib/shape_base.py", line 106, in apply_along_axis outarr[tuple(i.tolist())] = res ValueError: operands could not be broadcast together with shapes (2) (2,3) I'm using python 3.2 and numpy 1.6.0 RC2. Does anyone know an efficient way to do this? Thanks Pedro -- View this message in context: http://old.nabble.com/returning-a-tuple-of-arrays-with-apply_along_axis-tp3… Sent from the Numpy-discussion mailing list archive at Nabble.com.

1 0

Re: [Numpy-discussion] ANN: Numpy 1.6.0 release candidate 2
by DJ Luscher 06 May '11

06 May '11

Pearu Peterson <pearu.peterson <at> gmail.com> writes: > > > Thanks for the bug report!These issues are now fixed in: https://github.com/numpy/numpy/commit/f393b604 Ralf, feel free to apply this changeset to 1.6.x branch if appropriate.Regards,Pearu > Excellent! Thank you. I'll cautiously add another concern because I believe it is related. Using f2py to compile subroutines where dimensions for result variable are derived from two argument usage of size of an assumed shape input variable does not compile for me. example: <foo_size.f90> subroutine trans(x,y) implicit none real, intent(in), dimension(:,:) :: x real, intent(out), dimension( size(x,2), size(x,1) ) :: y integer :: N, M, i, j N = size(x,1) M = size(x,2) DO i=1,N do j=1,M y(j,i) = x(i,j) END DO END DO end subroutine trans For this example the autogenerated fortran wrapper is: <m-f2pywrappers.f> subroutine f2pywraptrans (x, y, f2py_x_d0, f2py_x_d1) integer f2py_x_d0 integer f2py_x_d1 real x(f2py_x_d0,f2py_x_d1) real y(shape(x,-1+2),shape(x,-1+1)) interface subroutine trans(x,y) real, intent(in),dimension(:,:) :: x real, intent(out),dimension( size(x,2), size(x,1) ) :: y end subroutine trans end interface call trans(x, y) end which (inappropriately?) translates the fortran SIZE(var,dim) into fortran SHAPE(var, kind). Please let me know if it is poor form for me to follow on with this secondary issue, but it seems like it is related and a straight-forward fix. Thanks again for your previous fix. DJ

2 5

FYI -- numpy.linalg.lstsq as distributed by Ubuntu is crashing on some inputs
by Nathaniel Smith 06 May '11

06 May '11

Probably just another standard "your BLAS is compiled wrong!" bug, but in this case I'm seeing it with the stock versions of ATLAS, numpy, etc. included in the latest Ubuntu release (11.04 Natty Narwhal): https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/778217 So I thought people might like a heads up in case they run into it as well. -- Nathaniel

2 3

ANN: Numpy 1.6.0 release candidate 2
by Ralf Gommers 05 May '11

05 May '11

Hi, I am pleased to announce the availability of the second release candidate of NumPy 1.6.0. Compared to the first release candidate, one segfault on (32-bit Windows + MSVC) and several memory leaks were fixed. If no new problems are reported, the final release will be in one week. Sources and binaries can be found at http://sourceforge.net/projects/numpy/files/NumPy/1.6.0rc2/ For (preliminary) release notes see below. Enjoy, Ralf ========================= NumPy 1.6.0 Release Notes ========================= This release includes several new features as well as numerous bug fixes and improved documentation. It is backward compatible with the 1.5.0 release, and supports Python 2.4 - 2.7 and 3.1 - 3.2. Highlights ========== * Re-introduction of datetime dtype support to deal with dates in arrays. * A new 16-bit floating point type. * A new iterator, which improves performance of many functions. New features ============ New 16-bit floating point type ------------------------------ This release adds support for the IEEE 754-2008 binary16 format, available as the data type ``numpy.half``. Within Python, the type behaves similarly to `float` or `double`, and C extensions can add support for it with the exposed half-float API. New iterator ------------ A new iterator has been added, replacing the functionality of the existing iterator and multi-iterator with a single object and API. This iterator works well with general memory layouts different from C or Fortran contiguous, and handles both standard NumPy and customized broadcasting. The buffering, automatic data type conversion, and optional output parameters, offered by ufuncs but difficult to replicate elsewhere, are now exposed by this iterator. Legendre, Laguerre, Hermite, HermiteE polynomials in ``numpy.polynomial`` ------------------------------------------------------------------------- Extend the number of polynomials available in the polynomial package. In addition, a new ``window`` attribute has been added to the classes in order to specify the range the ``domain`` maps to. This is mostly useful for the Laguerre, Hermite, and HermiteE polynomials whose natural domains are infinite and provides a more intuitive way to get the correct mapping of values without playing unnatural tricks with the domain. Fortran assumed shape array and size function support in ``numpy.f2py`` ----------------------------------------------------------------------- F2py now supports wrapping Fortran 90 routines that use assumed shape arrays. Before such routines could be called from Python but the corresponding Fortran routines received assumed shape arrays as zero length arrays which caused unpredicted results. Thanks to Lorenz Hüdepohl for pointing out the correct way to interface routines with assumed shape arrays. In addition, f2py interprets Fortran expression ``size(array, dim)`` as ``shape(array, dim-1)`` which makes it possible to automatically wrap Fortran routines that use two argument ``size`` function in dimension specifications. Before users were forced to apply this mapping manually. Other new functions ------------------- ``numpy.ravel_multi_index`` : Converts a multi-index tuple into an array of flat indices, applying boundary modes to the indices. ``numpy.einsum`` : Evaluate the Einstein summation convention. Using the Einstein summation convention, many common multi-dimensional array operations can be represented in a simple fashion. This function provides a way compute such summations. ``numpy.count_nonzero`` : Counts the number of non-zero elements in an array. ``numpy.result_type`` and ``numpy.min_scalar_type`` : These functions expose the underlying type promotion used by the ufuncs and other operations to determine the types of outputs. These improve upon the ``numpy.common_type`` and ``numpy.mintypecode`` which provide similar functionality but do not match the ufunc implementation. Changes ======= Changes and improvements in the numpy core ------------------------------------------ ``default error handling`` -------------------------- The default error handling has been change from ``print`` to ``warn`` for all except for ``underflow``, which remains as ``ignore``. ``numpy.distutils`` ------------------- Several new compilers are supported for building Numpy: the Portland Group Fortran compiler on OS X, the PathScale compiler suite and the 64-bit Intel C compiler on Linux. ``numpy.testing`` ----------------- The testing framework gained ``numpy.testing.assert_allclose``, which provides a more convenient way to compare floating point arrays than `assert_almost_equal`, `assert_approx_equal` and `assert_array_almost_equal`. ``C API`` --------- In addition to the APIs for the new iterator and half data type, a number of other additions have been made to the C API. The type promotion mechanism used by ufuncs is exposed via ``PyArray_PromoteTypes``, ``PyArray_ResultType``, and ``PyArray_MinScalarType``. A new enumeration ``NPY_CASTING`` has been added which controls what types of casts are permitted. This is used by the new functions ``PyArray_CanCastArrayTo`` and ``PyArray_CanCastTypeTo``. A more flexible way to handle conversion of arbitrary python objects into arrays is exposed by ``PyArray_GetArrayParamsFromObject``. Deprecated features =================== The "normed" keyword in ``numpy.histogram`` is deprecated. Its functionality will be replaced by the new "density" keyword. Removed features ================ ``numpy.fft`` ------------- The functions `refft`, `refft2`, `refftn`, `irefft`, `irefft2`, `irefftn`, which were aliases for the same functions without the 'e' in the name, were removed. ``numpy.memmap`` ---------------- The `sync()` and `close()` methods of memmap were removed. Use `flush()` and "del memmap" instead. ``numpy.lib`` ------------- The deprecated functions ``numpy.unique1d``, ``numpy.setmember1d``, ``numpy.intersect1d_nu`` and ``numpy.lib.ufunclike.log2`` were removed. ``numpy.ma`` ------------ Several deprecated items were removed from the ``numpy.ma`` module:: * ``numpy.ma.MaskedArray`` "raw_data" method * ``numpy.ma.MaskedArray`` constructor "flag" keyword * ``numpy.ma.make_mask`` "flag" keyword * ``numpy.ma.allclose`` "fill_value" keyword ``numpy.distutils`` ------------------- The ``numpy.get_numpy_include`` function was removed, use ``numpy.get_include`` instead.

13 19

optimizing ndarray.__setitem__
by Christoph Groth 05 May '11

05 May '11

Dear numpy experts, I have noticed that with Numpy 1.5.1 the operation m[::2] += 1.0 takes twice as long as t = m[::2] t += 1.0 where "m" is some large matrix. This is of course because the first snippet is equivalent to t = m[::2] t += 1.0 m[::2] = t I wonder whether it would not be a good idea to optimize ndarray.__setitem__ to not execute an assignment of a slice onto itself. Is there any good reason why this is not being done already? best, Christoph

5 6

[ANN] EuroScipy 2011 - deadline approaching
by Tiziano Zito 04 May '11

04 May '11

===================================== EuroScipy 2011 - Deadline Approaching ===================================== Beware: talk submission deadline is approaching. You can submit your contribution until Sunday May 8. --------------------------------------------- The 4th European meeting on Python in Science --------------------------------------------- **Paris, Ecole Normale Supérieure, August 25-28 2011** We are happy to announce the 4th EuroScipy meeting, in Paris, August 2011. The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and development of the Python language in scientific research. This event strives to bring together both users and developers of scientific tools, as well as academic research and state of the art industry. Main topics =========== - Presentations of scientific tools and libraries using the Python language, including but not limited to: - vector and array manipulation - parallel computing - scientific visualization - scientific data flow and persistence - algorithms implemented or exposed in Python - web applications and portals for science and engineering. - Reports on the use of Python in scientific achievements or ongoing projects. - General-purpose Python tools that can be of special interest to the scientific community. Tutorials ========= There will be two tutorial tracks at the conference, an introductory one, to bring up to speed with the Python language as a scientific tool, and an advanced track, during which experts of the field will lecture on specific advanced topics such as advanced use of numpy, scientific visualization, software engineering... Keynote Speaker: Fernando Perez =============================== We are excited to welcome Fernando Perez (UC Berkeley, Helen Wills Neuroscience Institute, USA) as our keynote speaker. Fernando Perez is the original author of the enhanced interactive python shell IPython and a very active contributor to the Python for Science ecosystem. Important dates =============== Talk submission deadline: Sunday May 8 Program announced: Sunday May 29 Tutorials tracks: Thursday August 25 - Friday August 26 Conference track: Saturday August 27 - Sunday August 28 Call for papers =============== We are soliciting talks that discuss topics related to scientific computing using Python. These include applications, teaching, future development directions, and research. We welcome contributions from the industry as well as the academic world. Indeed, industrial research and development as well academic research face the challenge of mastering IT tools for exploration, modeling and analysis. We look forward to hearing your recent breakthroughs using Python! Submission guidelines ===================== - We solicit talk proposals in the form of a one-page long abstract. - Submissions whose main purpose is to promote a commercial product or service will be refused. - All accepted proposals must be presented at the EuroSciPy conference by at least one author. The one-page long abstracts are for conference planing and selection purposes only. We will later select papers for publication of post-proceedings in a peer-reviewed journal. How to submit an abstract ========================= To submit a talk to the EuroScipy conference follow the instructions here: http://www.euroscipy.org/card/euroscipy2011_call_for_papers Organizers ========== Chairs: - Gaël Varoquaux (INSERM, Unicog team, and INRIA, Parietal team) - Nicolas Chauvat (Logilab) Local organization committee: - Emmanuelle Gouillart (Saint-Gobain Recherche) - Jean-Philippe Chauvat (Logilab) Tutorial chair: - Valentin Haenel (MKP, Technische Universität Berlin) Program committee: - Chair: Tiziano Zito (MKP, Technische Universität Berlin) - Romain Brette (ENS Paris, DEC) - Emmanuelle Gouillart (Saint-Gobain Recherche) - Eric Lebigot (Laboratoire Kastler Brossel, Université Pierre et Marie Curie) - Konrad Hinsen (Soleil Synchrotron, CNRS) - Hans Petter Langtangen (Simula laboratories) - Jarrod Millman (UC Berkeley, Helen Wills NeuroScience institute) - Mike Müller (Python Academy) - Didrik Pinte (Enthought Inc) - Marc Poinot (ONERA) - Christophe Pradal (CIRAD/INRIA, Virtual Plantes team) - Andreas Schreiber (DLR) - Stéfan van der Walt (University of Stellenbosch) Website ======= http://www.euroscipy.org/conference/euroscipy_2011

1 0

general newbie question about applying an arbitrary function to all elements in a numpy array
by Michael Katz 03 May '11

03 May '11

I have a basic question about applying functions to array elements. There is a rambling introduction here and then I get to the ACTUAL QUESTION about 2/3 of the way down. RAMBLING INTRODUCTION I was trying to do a simple mapping of array values to other values. So I had: unmapped_colors = np.array((0,0,1,1,2,0,0,1)) BNA_LAND_FEATURE_CODE = 0 BNA_WATER_FEATURE_CODE = 1 # color_to_int() produces some unsigned int value green = color_to_int( 0.25, 0.5, 0, 0.75 ) blue = color_to_int( 0.0, 0.0, 0.5, 0.75 ) gray = color_to_int( 0.5, 0.5, 0.5, 0.75 ) def map_type_to_color( t ): if ( t == BNA_LAND_FEATURE_CODE ): return green elif ( t == BNA_WATER_FEATURE_CODE ): return blue else: return gray mapped_colors = np.vectorize( map_type_to_color )( unmapped_colors ) I found that by using vectorize I got about a 3x speedup compared to using a python for loop to loop through the array. One small question is I wonder where that speedup comes from; i.e., what vectorize is actually doing for me. Is it just the time for the actual looping logic? That seems like too much speedup. Does it also include a faster access of the array data items? So I was trying to find a "pure numpy" solution for this. I then learned about fancy indexing and boolean indexing, and saw that I could do boolean array version: mapped_colors = np.zeros(unmapped_colors.shape, dtype=np.uint32) + gray mapped_colors[unmapped_colors==BNA_LAND_FEATURE_CODE] = green mapped_colors[unmapped_colors==BNA_WATER_FEATURE_CODE] = blue and in fact I could do "fancy indexing" version: color_array = np.array((green, blue, gray), dtype=np.uint32) colors = color_array[unmapped_colors] The boolean array version is pretty simple, but makes three "passes" over the data. The fancy indexing version is simple and one pass, but it relies on the fact that my constant values happen to be nice to use as array indexes. And in fact to use it in actual code I'd need to do one or more other passes to check unmapped_colors for any indexes < 0 or > 2. ACTUAL QUESTION So, the actual question here is, even though I was able to find a couple solutions for this particular problem, I am wondering in general about applying arbitrary functions to each array element in a "pure numpy" way, ideally using just a single pass. It seems to me like there should be a some way to build up a "numpy compiled" function that you could then apply to all elements in an array. Is that what "universal functions" are about? That's what it sounded like it was about to me at first, but then after looking closer it didn't seem like that. I guess I was hoping vectorize was some magical thing that could compile certain python expressions down into "numpy primitives". It seems like as long as you stuck to a limited set of math and logical operations on arrays, even if those expressions included calls to subroutines that were similarly restricted, there should be an automated way to convert such expressions into the equivalent of a numpy built-in. I guess it's similar to cython, but it wouldn't require a separate file or special compilation. I could just say def capped_sqrt( n ): if ( x > 100 ) return 10 else: return sqrt( n ) f = numpy.compile( lambda(x): 0 if ( x < 10 ) else capped_sqrt( x ) ) numpy.map( f, a ) or something like that, and it would all happen in a single pass within numpy, with no "python code" being run. Is that something that exists? I realize that for any function like this I could build it out of a sequence of individual numpy operations on the whole array, but it seems that in general that requires doing several passes, creating multiple temp arrays, and computing functions for elements where the results will later be thrown out. This might be just because I'm a numpy newbie, but it's not clear to me how to do the example above on an array of size N without computing N square roots, even if the number of elements in my array between 10 and 100 is much smaller than N . Granted, I could set things up so that by the time sqrt was applied it would only be computing, say, sqrt( 0 ) for all those values that were originally < 10 or > 100. But still, it would be nice not to compute unnecessarily at all. And efficiency concerns aside, it just seems unfortunate, language-wise, to always have to think cleverly about some sequence of whole-array transformations instead of just being able to think about the "single pass computation" that is in your head (at least is in my head) in the first place and is after all the most direct and non-redundant way to get the result. Michael

3 6

Vector/matrix with 3200975422129 elements
by Gaston Fiore 03 May '11

03 May '11

Hello, I'm trying to create a vector (or a matrix, could be either) with 3200975422129 elements but I'm not being successful, get the following error: >>> zeros(width * height, dtype=float32) Killed or >>> zeros((1789127,1789127), dtype=float32) Killed I'm assuming that I'm running out of memory. How could I go around this? This is some extra information: -bash-3.2$ python Python 2.7.1 (r271:86832, Apr 25 2011, 11:02:55) [GCC 4.3.3] on linux2 -bash-3.2$ python -c 'import numpy as np; print np.__version__' 1.6.0b2 Thanks a lot, -Gaston

2 2

ANN: Numpy 1.6.0 release candidate 1
by Ralf Gommers 03 May '11

03 May '11

Hi, I am pleased to announce the availability of the first release candidate of NumPy 1.6.0. If no new problems are reported, the final release will be in one week. Sources and binaries can be found at http://sourceforge.net/projects/numpy/files/NumPy/1.6.0rc1/ For (preliminary) release notes see below. Enjoy, Ralf ========================= NumPy 1.6.0 Release Notes ========================= This release includes several new features as well as numerous bug fixes and improved documentation. It is backward compatible with the 1.5.0 release, and supports Python 2.4 - 2.7 and 3.1 - 3.2. Highlights ========== * Re-introduction of datetime dtype support to deal with dates in arrays. * A new 16-bit floating point type. * A new iterator, which improves performance of many functions. New features ============ New 16-bit floating point type ------------------------------ This release adds support for the IEEE 754-2008 binary16 format, available as the data type ``numpy.half``. Within Python, the type behaves similarly to `float` or `double`, and C extensions can add support for it with the exposed half-float API. New iterator ------------ A new iterator has been added, replacing the functionality of the existing iterator and multi-iterator with a single object and API. This iterator works well with general memory layouts different from C or Fortran contiguous, and handles both standard NumPy and customized broadcasting. The buffering, automatic data type conversion, and optional output parameters, offered by ufuncs but difficult to replicate elsewhere, are now exposed by this iterator. Legendre, Laguerre, Hermite, HermiteE polynomials in ``numpy.polynomial`` ------------------------------------------------------------------------- Extend the number of polynomials available in the polynomial package. In addition, a new ``window`` attribute has been added to the classes in order to specify the range the ``domain`` maps to. This is mostly useful for the Laguerre, Hermite, and HermiteE polynomials whose natural domains are infinite and provides a more intuitive way to get the correct mapping of values without playing unnatural tricks with the domain. Fortran assumed shape array and size function support in ``numpy.f2py`` ----------------------------------------------------------------------- F2py now supports wrapping Fortran 90 routines that use assumed shape arrays. Before such routines could be called from Python but the corresponding Fortran routines received assumed shape arrays as zero length arrays which caused unpredicted results. Thanks to Lorenz Hüdepohl for pointing out the correct way to interface routines with assumed shape arrays. In addition, f2py interprets Fortran expression ``size(array, dim)`` as ``shape(array, dim-1)`` which makes it possible to automatically wrap Fortran routines that use two argument ``size`` function in dimension specifications. Before users were forced to apply this mapping manually. Other new functions ------------------- ``numpy.ravel_multi_index`` : Converts a multi-index tuple into an array of flat indices, applying boundary modes to the indices. ``numpy.einsum`` : Evaluate the Einstein summation convention. Using the Einstein summation convention, many common multi-dimensional array operations can be represented in a simple fashion. This function provides a way compute such summations. ``numpy.count_nonzero`` : Counts the number of non-zero elements in an array. ``numpy.result_type`` and ``numpy.min_scalar_type`` : These functions expose the underlying type promotion used by the ufuncs and other operations to determine the types of outputs. These improve upon the ``numpy.common_type`` and ``numpy.mintypecode`` which provide similar functionality but do not match the ufunc implementation. Changes ======= Changes and improvements in the numpy core ------------------------------------------ ``default error handling`` -------------------------- The default error handling has been change from ``print`` to ``warn`` for all except for ``underflow``, which remains as ``ignore``. ``numpy.distutils`` ------------------- Several new compilers are supported for building Numpy: the Portland Group Fortran compiler on OS X, the PathScale compiler suite and the 64-bit Intel C compiler on Linux. ``numpy.testing`` ----------------- The testing framework gained ``numpy.testing.assert_allclose``, which provides a more convenient way to compare floating point arrays than `assert_almost_equal`, `assert_approx_equal` and `assert_array_almost_equal`. ``C API`` --------- In addition to the APIs for the new iterator and half data type, a number of other additions have been made to the C API. The type promotion mechanism used by ufuncs is exposed via ``PyArray_PromoteTypes``, ``PyArray_ResultType``, and ``PyArray_MinScalarType``. A new enumeration ``NPY_CASTING`` has been added which controls what types of casts are permitted. This is used by the new functions ``PyArray_CanCastArrayTo`` and ``PyArray_CanCastTypeTo``. A more flexible way to handle conversion of arbitrary python objects into arrays is exposed by ``PyArray_GetArrayParamsFromObject``. Deprecated features =================== The "normed" keyword in ``numpy.histogram`` is deprecated. Its functionality will be replaced by the new "density" keyword. Removed features ================ ``numpy.fft`` ------------- The functions `refft`, `refft2`, `refftn`, `irefft`, `irefft2`, `irefftn`, which were aliases for the same functions without the 'e' in the name, were removed. ``numpy.memmap`` ---------------- The `sync()` and `close()` methods of memmap were removed. Use `flush()` and "del memmap" instead. ``numpy.lib`` ------------- The deprecated functions ``numpy.unique1d``, ``numpy.setmember1d``, ``numpy.intersect1d_nu`` and ``numpy.lib.ufunclike.log2`` were removed. ``numpy.ma`` ------------ Several deprecated items were removed from the ``numpy.ma`` module:: * ``numpy.ma.MaskedArray`` "raw_data" method * ``numpy.ma.MaskedArray`` constructor "flag" keyword * ``numpy.ma.make_mask`` "flag" keyword * ``numpy.ma.allclose`` "fill_value" keyword ``numpy.distutils`` ------------------- The ``numpy.get_numpy_include`` function was removed, use ``numpy.get_include`` instead.

5 13

Less dimensions than expected with record array
by Alan Gibson 02 May '11

02 May '11

Hello all, This question may seem elementary (mostly because it is), but I can't find documentation anywhere as to why the following are true: >>> import numpy as np >>> data = [(1,2,3),(4,5,6),(7,8,9)] >>> dt = [('a',int),('b',int),('c',int)] >>> normal_array = np.array(data) >>> record_array = np.array(data, dtype=dt) >>> print "ndarray has shape %s but record array has shape %s" % \ ... (normal_array.shape, record_array.shape) ndarray has shape (3, 3) but record array has shape (3,) >>> print "ndarray has %s dimensions but record array has %s dimensions" % \ ... (normal_array.ndim, record_array.ndim) ndarray has 2 dimensions but record array has 1 dimensions This makes seemingly reasonable things, like using apply_along_axis() over a table of data with named columns, impossible: >>> np.apply_along_axis(record_array, 1, lambda x: x) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python2.6/dist-packages/numpy/lib/shape_base.py", line 72, in apply_along_axis % (axis,nd)) ValueError: axis must be less than arr.ndim; axis=1, rank=0. What's the reason for this behavior? Is there a way to make such operations work with record arrays? Thanks, Alan

3 2