![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modeled 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.4.0 I. ENHANCEMENTS 1. Speed improvement for numarray operators. The Python level hook mapping numarray operators onto universal functions has been moved down to C. 2. Speed improvement for string-array comparisons, any(), all(). String correlation is ~10x faster. 3. Better operation with py2exe to help it automatically detect the core numarray extensions to include in an installer. 4. scipy newcore compatible lower case type names (e.g. int32 not Int32) 5. scipy newcore 'dtype' keyword and .dtypechar attribute. II. BUGS FIXED / CLOSED 1323355 Apps fail with import_libnumarray 1315212 Infinite loop converting some scalar strings into a list 1298916 rank-0 tostring() broken 1297948 records.array fails to create empty fields 1286291 import sys missing from array_persist.py 1286168 Generic sequences in ``strings.array()`` 1236392 Outdated web link in announcements 1235219 LinearAlgebraError not imported in linear_algebra 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.3.x WHERE ----------- Numarray-1.4.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://www.stsci.edu/resources/software_hardware/numarray 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.4.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
![](https://secure.gravatar.com/avatar/f2803bd328ec8cb4b31ece47a5933b46.jpg?s=120&d=mm&r=g)
After installing numarray-1.4.0, I get a Segmentation fault when comparing two instances of the same string-array. For example: from numarray.strings import asarray for x in range(1000,1000000,1000): print x raw = ['abcde']*x arr = asarray(raw) arr == arr gives: 1000 2000 3000 4000 5000 6000 Segmentation fault I verified that this works correctly in numarray-1.3.3. Also, the problem can be avoided in 1.4.0 by replacing 'arr == arr' with 'arr = arr.copy()'. Can anyone else reproduce this, or is a problem with my environment? Thanks, John
![](https://secure.gravatar.com/avatar/6a2a454191fa75d4114ed05836a0b924.jpg?s=120&d=mm&r=g)
Hi-
4. scipy newcore compatible lower case type names (e.g. int32 not Int32)
Is this actually true? For example, numarray.Float64 exists as before, but numarray.float64 does not.
5. scipy newcore 'dtype' keyword and .dtypechar attribute.
And more generally, is there any more information on the relationship between numarray and scipy_core? Will numarray be phased out eventually (i.e., should we start moving over to scipy?)? But in any event thanks for the hard work! Andrew
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
Andrew Jaffe wrote:
I added the "string aliases" but didn't create new Python object bindings. So you can currently say something like arange(10, dtype='float32') but cannot yet say: arange(10, dtype=float32) Good catch. I'll add those soon.
I think scipy_core is intended to add the best numarray-like features to Numeric.
Will numarray be phased out eventually (i.e., should we start moving over to scipy?)?
When scipy_core matures enough to replace numarray, numarray will be phased out. If you rely on numarray, it is definitely worth your time to keep an eye on scipy_core and switch when it meets your needs better. Regards, Todd
![](https://secure.gravatar.com/avatar/f2803bd328ec8cb4b31ece47a5933b46.jpg?s=120&d=mm&r=g)
After installing numarray-1.4.0, I get a Segmentation fault when comparing two instances of the same string-array. For example: from numarray.strings import asarray for x in range(1000,1000000,1000): print x raw = ['abcde']*x arr = asarray(raw) arr == arr gives: 1000 2000 3000 4000 5000 6000 Segmentation fault I verified that this works correctly in numarray-1.3.3. Also, the problem can be avoided in 1.4.0 by replacing 'arr == arr' with 'arr = arr.copy()'. Can anyone else reproduce this, or is a problem with my environment? Thanks, John
![](https://secure.gravatar.com/avatar/6a2a454191fa75d4114ed05836a0b924.jpg?s=120&d=mm&r=g)
Hi-
4. scipy newcore compatible lower case type names (e.g. int32 not Int32)
Is this actually true? For example, numarray.Float64 exists as before, but numarray.float64 does not.
5. scipy newcore 'dtype' keyword and .dtypechar attribute.
And more generally, is there any more information on the relationship between numarray and scipy_core? Will numarray be phased out eventually (i.e., should we start moving over to scipy?)? But in any event thanks for the hard work! Andrew
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
Andrew Jaffe wrote:
I added the "string aliases" but didn't create new Python object bindings. So you can currently say something like arange(10, dtype='float32') but cannot yet say: arange(10, dtype=float32) Good catch. I'll add those soon.
I think scipy_core is intended to add the best numarray-like features to Numeric.
Will numarray be phased out eventually (i.e., should we start moving over to scipy?)?
When scipy_core matures enough to replace numarray, numarray will be phased out. If you rely on numarray, it is definitely worth your time to keep an eye on scipy_core and switch when it meets your needs better. Regards, Todd
participants (3)
-
Andrew Jaffe
-
John A Chaves
-
Todd Miller