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.4.1 II. BUGS FIXED / CLOSED 1339713 segfault when comparing string-array to self ========================================================================= 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
Hi Todd, I've just installed numarray 1.4.1 and pass my tests over it. Everything goes well, except some small detail: Python 2.4.2 (#2, Sep 29 2005, 00:23:59) [GCC 4.0.2 (Debian 4.0.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import Numeric import numarray Numeric.__version__ '24.0b2' numarray.__version__ '1.4.1' na=numarray.array([ 51.], type=numarray.Float64) Numeric.array(na, typecode='d') Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: expected a writeable buffer object
This worked in 1.3.x and before. I hope that this is not the intended behaviour. Thanks, --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
Francesc Altet wrote:
Hi Todd,
I've just installed numarray 1.4.1 and pass my tests over it. Everything goes well, except some small detail:
Python 2.4.2 (#2, Sep 29 2005, 00:23:59) [GCC 4.0.2 (Debian 4.0.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import Numeric import numarray Numeric.__version__
'24.0b2'
numarray.__version__
'1.4.1'
na=numarray.array([ 51.], type=numarray.Float64) Numeric.array(na, typecode='d')
Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: expected a writeable buffer object
This worked in 1.3.x and before.
I hope that this is not the intended behaviour.
This looks like a coordinated change in both numarray and Numeric. (Travis?) I updated to Numeric-24.0 and all was well. It appears the __array_data__ protocol improved to know about readonly-ness. In order to support the readonly behavior in numarray, I think the change must be made in lockstep. We could however back out support for readonly while Numeric-24.0 becomes more pervasive. Regards, Todd
A Divendres 28 Octubre 2005 19:58, Todd Miller va escriure:
This looks like a coordinated change in both numarray and Numeric. (Travis?) I updated to Numeric-24.0 and all was well.
Ops, I was not aware that Numeric-24.0 was out. Anyway, I've tried to compile it, but I did not succeed with my Debian system: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.4 -c Src/lapack_litemodule.c -o build/temp.linux-i686-2.4/Src/lapack_litemodule.o gcc -pthread -shared build/temp.linux-i686-2.4/Src/lapack_litemodule.o -L/usr/lib/atlas -llapack -lcblas -lf77blas -latlas -lg2c -o build/lib.linux-i686-2.4/lapack_lite.so /usr/bin/ld: cannot find -llapack collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 The installation for Numeric usually worked on my system. Perhaps it is now assumed that lapack should be a pre-requisite?
It appears the __array_data__ protocol improved to know about readonly-ness. In order to support the readonly behavior in numarray, I think the change must be made in lockstep. We could however back out support for readonly while Numeric-24.0 becomes more pervasive.
Yes, please, backward compatibility with pre-Numeric 24.0 would be a nice thing to have. Regards, --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
Francesc Altet wrote:
/usr/bin/ld: cannot find -llapack collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1
The installation for Numeric usually worked on my system. Perhaps it is now assumed that lapack should be a pre-requisite?
This has been a problem for a remarkably long time! I thought it had been fixed. It's not really a big deal, it's only a matter of what the defaults are in customize.py. The comments in there should be enough to figure it out. The default really should be to use the built-in lapack-lite. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
A Divendres 28 Octubre 2005 20:37, Chris Barker va escriure:
This has been a problem for a remarkably long time! I thought it had been fixed. It's not really a big deal, it's only a matter of what the defaults are in customize.py. The comments in there should be enough to figure it out.
Yup, it worked. Thanks. Anyway, I think that the sensible default would be to not suppose that neither BLAS, LAPACK, ATALS are installed and update the README to give instructuctions on how to adapt Numeric to your system. Cheers, --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
Francesc Altet wrote:
A Divendres 28 Octubre 2005 20:37, Chris Barker va escriure:
This has been a problem for a remarkably long time! I thought it had been fixed. It's not really a big deal, it's only a matter of what the defaults are in customize.py. The comments in there should be enough to figure it out.
Yup, it worked. Thanks.
Anyway, I think that the sensible default would be to not suppose that neither BLAS, LAPACK, ATALS are installed and update the README to give instructuctions on how to adapt Numeric to your system.
Yes, that was always the plan. I just forgot to reset customize.py to the original before making a tar ball. I've fixed the problem now. The new tar ball does uses default lapack_lite. (I'm sure I'll upset somebody because the tar ball changed slightly with no version number increase --- but I don't want to make a new release --- the other files should be fine). -Travis
Todd Miller wrote:
Francesc Altet wrote:
Hi Todd,
I've just installed numarray 1.4.1 and pass my tests over it. Everything goes well, except some small detail:
Python 2.4.2 (#2, Sep 29 2005, 00:23:59) [GCC 4.0.2 (Debian 4.0.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import Numeric import numarray Numeric.__version__
'24.0b2'
numarray.__version__
'1.4.1'
na=numarray.array([ 51.], type=numarray.Float64) Numeric.array(na, typecode='d')
Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: expected a writeable buffer object
This looks like a coordinated change in both numarray and Numeric. (Travis?) I updated to Numeric-24.0 and all was well.
It appears the __array_data__ protocol improved to know about readonly-ness. In order to support the readonly behavior in numarray, I think the change must be made in lockstep. We could however back out support for readonly while Numeric-24.0 becomes more pervasive.
Yes, basically the __array_data__ protocol was essentially pointless before because it just returned a buffer object which 1) did nothing more than the object itself supporting the buffer protocol and 2) could not handle strided (discontiguous) arrays. The new array protocol handles the situation much better and allows discontiguous arrays to be shared. However, it does create some backward compatibility issues. But, because Numeric 24.0b2 was a *beta* release I don't see this as a real problem. Get the final release of Numeric, which will handle the array protocol correctly (note it will also handle the old __array_data__ format as well). Todd, I was not sure how to change numarray so it would consume the new protocol correctly. So, I'm not sure how numarray interprets the __array_data__ attribute. -Travis
Travis Oliphant wrote:
Todd Miller wrote:
Francesc Altet wrote:
Hi Todd,
I've just installed numarray 1.4.1 and pass my tests over it. Everything goes well, except some small detail:
Python 2.4.2 (#2, Sep 29 2005, 00:23:59) [GCC 4.0.2 (Debian 4.0.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import Numeric import numarray Numeric.__version__
'24.0b2'
numarray.__version__
'1.4.1'
na=numarray.array([ 51.], type=numarray.Float64) Numeric.array(na, typecode='d')
Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: expected a writeable buffer object
This looks like a coordinated change in both numarray and Numeric. (Travis?) I updated to Numeric-24.0 and all was well.
It appears the __array_data__ protocol improved to know about readonly-ness. In order to support the readonly behavior in numarray, I think the change must be made in lockstep. We could however back out support for readonly while Numeric-24.0 becomes more pervasive.
Yes, basically the __array_data__ protocol was essentially pointless before because it just returned a buffer object which
1) did nothing more than the object itself supporting the buffer protocol and 2) could not handle strided (discontiguous) arrays.
The new array protocol handles the situation much better and allows discontiguous arrays to be shared.
However, it does create some backward compatibility issues. But, because Numeric 24.0b2 was a *beta* release I don't see this as a real problem.
Yeah, that sounds ok... I was thinking the array interface was a release or two older.
Get the final release of Numeric, which will handle the array protocol correctly (note it will also handle the old __array_data__ format as well).
Todd, I was not sure how to change numarray so it would consume the new protocol correctly.
I think numarray's multiple factory functions in numarray, strings, and records all need to be beefed up to look for it.
So, I'm not sure how numarray interprets the __array_data__ attribute.
I don't know if it does right now. Just to be clear, what Francesc was talking about is *supplying* the array buffer from numarray as apparently defined in the __get_array_data__ method. If 24b was the first time the array interface ever worked it sounds ok to leave your changes in and force an upgrade to 24 if a user uses that feature. Francesc? Todd
Todd Miller wrote:
I don't know if it does right now. Just to be clear, what Francesc was talking about is *supplying* the array buffer from numarray as apparently defined in the __get_array_data__ method. If 24b was the first time the array interface ever worked it sounds ok to leave your changes in and force an upgrade to 24 if a user uses that feature. Francesc?
Right, he was talking about just supplying the array data information from numarray. And, yes, Numeric 24b was the first time the array interface ever worked. -Travis
El dv 28 de 10 del 2005 a les 14:52 -0600, en/na Travis Oliphant va escriure:
Todd Miller wrote: I don't know if it does right now. Just to be clear, what Francesc was talking about is *supplying* the array buffer from numarray as apparently defined in the __get_array_data__ method. If 24b was the first time the array interface ever worked it sounds ok to leave your changes in and force an upgrade to 24 if a user uses that feature. Francesc? Right, he was talking about just supplying the array data information from numarray.
And, yes, Numeric 24b was the first time the array interface ever worked.
Yes, I think that if Numeric 24b was the first implementing the array interface, then there is no need to touch nothing in numarray. As you said, I should make Numeric 24.0 a requisite for running our software. Thanks for clarificating the issue, --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
participants (4)
-
Chris Barker -
Francesc Altet -
Todd Miller -
Travis Oliphant