
Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, arrays of heterogeneous records, string arrays, and in-place operation on memory mapped files. ========================================================================= Release Notes for numarray-1.3.3 I. ENHANCEMENTS None. 1.3.3 fixes a fatal problem with embedding numarray and loading it more than once. It also fixes some numarray memory leaks associated with restarting the Python interpreter. II. BUGS FIXED / CLOSED 1233431 Add 'type' to fromfunction() 1230490 Numarray: integer overflow in sum() is not detected 1216688 ufunc's ignoring complex operand 1213675 Problems embedding after 1.1.1 1209946 Mac OS-X --use_lapack 1212975 numarray.fromfunction(...) misbehavior 1209929 config.h and Python-2.2 1235278 Add -lm to numarray link lists See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.2 I. ENHANCEMENTS None. 1.3.2 fixes the problem with gcc4 on Mac OS-X 10.4 Tiger II. BUGS FIXED / CLOSED 1193125 Build failure on Mac OS 10.4 (Tiger) 1195370 numarray1.3.1 setup.py broken See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.1 I. ENHANCEMENTS None. 1.3.1 fixes the problem with gcc-3.4.3 II. BUGS FIXED / CLOSED 1152323 /usr/include/fenv.h:96: error: conflicting types for 'fegete 1185024 numarray-1.2.3 fails to compile with gcc-3.4.3 1187162 Numarray 1.3.0 installation failure See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.0 Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, arrays of heterogeneous records, string arrays, and in-place operation on memory mapped files. I. ENHANCEMENTS 1. Migration of NumArray.__del__ to C (tp_dealloc). Overall performance. 2. Removal of dictionary update from array view creation improves performance of view/slice/subarray creation. This should e.g. improve the performance of wxPython sequence protocol access to Nx2 arrays. Subclasses now need to do a.flags |= numarray.generic._UPDATEDICT to ensure that dictionary based attributes are inherited by views. NumArrays no longer do this by default. 2. Modifications to support scipy.special. 3. Removal of an unnecessary getattr() from ufunc calling sequence. Ufunc performance. II. BUGS FIXED / CLOSED 1179355 average() broken in numarray 1.2.3 1167184 Floating point exception in numarray's dot() 1151892 Bug in matrixmultiply with zero size arrays 1160184 RecArray reversal 1156172 Incorect error message for shape incompatability 1155538 Incorrect error message when multiplying arrays See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. III. CAUTIONS This release should be backward binary compatible with numarray-1.1.1 and 1.2.3. WHERE ----------- Numarray-1.3.0 windows executable installers, source code, and manual is here: http://sourceforge.net/project/showfiles.php?group_id=1369 Numarray is hosted by Source Forge in the same project which hosts Numeric: http://sourceforge.net/projects/numpy/ The web page for Numarray information is at: http://stsdas.stsci.edu/numarray/index.html Trackers for Numarray Bugs, Feature Requests, Support, and Patches are at the Source Forge project for NumPy at: http://sourceforge.net/tracker/?group_id=1369 REQUIREMENTS ------------------------------ numarray-1.3.0 requires Python 2.2.2 or greater. AUTHORS, LICENSE ------------------------------ Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science Institute. We'd like to acknowledge the assitance of Francesc Alted, Paul Dubois, Sebastian Haase, Chuck Harris, Tim Hochberg, Nadav Horesh, Edward C. Jones, Eric Jones, Jochen Kuepper, Travis Oliphant, Pearu Peterson, Peter Verveer, Colin Williams, Rory Yorke, and everyone else who has contributed with comments and feedback. Numarray is made available under a BSD-style License. See LICENSE.txt in the source distribution for details. -- Todd Miller jmiller@stsci.edu

Hi all, i'm using numarrays with audio and video processing with the real-time framework pure data (http://www.puredata.org). I realized that the ufuncs in numarrays are not as fast as possible because they are coded very straightforward. Is there any particular reason why this is the case, like cleanness of code, confidence in the compiler or because the code was automatically generated? I would like to contribute assembly SIMD codelets (SSE and Altivec), i have been successfully using in my projects for quite some time. Is it feasible to submit patches, so that these go into the main numarray distribution, or should i rather implement this as separate ufuncs? best greetings, Thomas

Ok, i'm answering myself partly since no-one else did
I realized that the ufuncs in numarrays are not as fast as possible because they are coded very straightforward. Is there any particular reason why this is the case, like cleanness of code, confidence in the compiler or because the code was automatically generated?
sorry for disregarding the manual in this respect... clearly the codelets are generated
I would like to contribute assembly SIMD codelets (SSE and Altivec), i have been successfully using in my projects for quite some time. Is it feasible to submit patches, so that these go into the main numarray distribution, or should i rather implement this as separate ufuncs?
well then, is it an option to provide hand-written ufunc implementations, circumventing the code generation? Is the function nomenclature stable enough that this would work for a longer time? thanks, Thomas
participants (2)
-
Thomas Grill
-
Todd Miller