![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
I have just uploaded numarray-0.6 to Source Forge. http://sourceforge.net/project/showfiles.php?group_id=1369 This is the first release with numarray repackaged as a Python package. I. ENHANCEMENTS 1. Repackaging numarray has been modified from a collection of Python modules into a Python package. See Doc/Repackaging in the source distribution for more details. 2. Median Filter Function See numarray.image.combine.median for a function which computes the median pixels in a stack of images. 3. Thread Safety Work Modifications to ufunc caching and IEEE error handling enable numarray to work in multi-threaded programs. II. BUGS FIXED 733534 Broadcasts of non-array sequences fails 733535 NA_typeNoToTypeObject sometimes fails 736674 PyArray_ContiguousFromObject() fails for some scalars 737041 Build failure on Cygwin 1.3.22 (very current install). 750320 CharArray.raw() is broken 750326 building RPMS fails 754836 Missing Src/_convmodule.c during setup 756050 chararray multi-d copy fails for recarray 772519 memory.new_memory() 64-bit scanning bug III. CAUTIONS 1. Due to the distribution repackaging, numarray-0.6 will not install correctly on top of an existing numarray installation. Before installing numarray-0.6 remove your old version of numarray. -- Todd Miller jmiller@stsci.edu STSCI / ESS / SSB
![](https://secure.gravatar.com/avatar/6c9110e0401b013d2324fbd6257dc80d.jpg?s=120&d=mm&r=g)
Hi, I've detected a problem during installation. It seems like if safethread module is out of the final package: inspiron:~/PyTables/pytables-0.6$ python2.3 Python 2.3b2 (#1, Jul 7 2003, 18:07:41) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
However, I have copied it after a previous CVS version, and that seems enough:
-- Francesc Alted
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Congratulations ! And thanks for the nice work -- I'm going upgrade tomorrow... And this time even the new documentation is already online ;-) [It's just somewhat sad that google still points to the 'numarray has moved!' page] Question: In an email from May-20th (actually regarding rel.0.5) Todd wrote: "However, there is a new API function which I added in response to your last post: NA_NewAllFromBuffer() which enables you to create arrays in C from existing buffer objects rather than just C arrays." The 0.6 documentation doesn't mention that function - for now I probably have to read the source, right ? BTW - We are already using a self-made version of that - allowing us to access the CCD images that get acquired from our Microspcope (mostly C++ code) as a 16-bit unsigned int numarray - in real time! --- It's just great, and people love it. Thanks, Sebastian Haase On 19 Jul 2003 06:51:53 -0400 Todd Miller <jmiller@stsci.edu> wrote:
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Sun, 2003-07-20 at 16:12, Sebastian Haase wrote:
Congratulations !
Thanks!
And thanks for the nice work -- I'm going upgrade tomorrow...
Great.
Yes. The signature is: PyArrayObject * NA_NewAllFromBuffer (int ndim, maybelong *shape, NumarrayType type, PyObject *bufferObject, maybelong byteoffset, maybelong bytestride, int byteorder, int aligned, int writeable) Please try it out.
Excellent. That's good to hear!
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Seems to work right away. But now I get this:
Sorry to frighten you... :-( I am just experimenting with from __future__ import division Apparently taking that line out again fixes the problem. I am actually not sure what the "proposed policy" is on that future division thing; I just thought I could simplify some explanation to non-Python people if 1/3 is not 0. Probably numarray has more important things to worry about - but maybe you can put it on the list.. Thanks for your work. Sebastian
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
----- Original Message ----- From: "Sebastian Haase" <haase@msg.ucsf.edu> To: "Todd Miller" <jmiller@stsci.edu> Cc: "numpy-discussion" <numpy-discussion@lists.sourceforge.net> Sent: Monday, July 28, 2003 5:02 PM Subject: Re: [Numpy-discussion] ANNOUNCE: numarray-0.6
We have't added support for future division yet.
Apparently taking that line out again fixes the problem.
I am actually not sure what the "proposed policy" is on that future
thing; I just thought I could simplify some explanation to non-Python
Good. division people
if 1/3 is not 0.
I believe we're going to support future division eventually. I'm not sure how soon.
Probably numarray has more important things to worry about - but maybe you can put it on the list..
It's on "the list".
Thanks for your work.
You're welcome. I hope you find it useful.
Sebastian
![](https://secure.gravatar.com/avatar/05e73d24d898a94bd87036088bbdb344.jpg?s=120&d=mm&r=g)
Todd Miller wrote:
GREAT. And what is even more great - I see that the version adapted to Python 2.3 is there. In some private exchange I read "of course we will upgrade, but 2.3 is beta, let's wait when it stabilizes". I sincerely think that all essential goodies (and numarray is one of them) should evolve in parallel with the kernel. Personally I wouldn't touch new versions of Python without having those additional goodies, since I wouldn't know what to do with it. Just playing with Guido's tutorial, or what? Thank you. Jerzy Karczmarczuk Caen, France
![](https://secure.gravatar.com/avatar/6c9110e0401b013d2324fbd6257dc80d.jpg?s=120&d=mm&r=g)
Hi, I've detected a problem during installation. It seems like if safethread module is out of the final package: inspiron:~/PyTables/pytables-0.6$ python2.3 Python 2.3b2 (#1, Jul 7 2003, 18:07:41) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
However, I have copied it after a previous CVS version, and that seems enough:
-- Francesc Alted
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Congratulations ! And thanks for the nice work -- I'm going upgrade tomorrow... And this time even the new documentation is already online ;-) [It's just somewhat sad that google still points to the 'numarray has moved!' page] Question: In an email from May-20th (actually regarding rel.0.5) Todd wrote: "However, there is a new API function which I added in response to your last post: NA_NewAllFromBuffer() which enables you to create arrays in C from existing buffer objects rather than just C arrays." The 0.6 documentation doesn't mention that function - for now I probably have to read the source, right ? BTW - We are already using a self-made version of that - allowing us to access the CCD images that get acquired from our Microspcope (mostly C++ code) as a 16-bit unsigned int numarray - in real time! --- It's just great, and people love it. Thanks, Sebastian Haase On 19 Jul 2003 06:51:53 -0400 Todd Miller <jmiller@stsci.edu> wrote:
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Sun, 2003-07-20 at 16:12, Sebastian Haase wrote:
Congratulations !
Thanks!
And thanks for the nice work -- I'm going upgrade tomorrow...
Great.
Yes. The signature is: PyArrayObject * NA_NewAllFromBuffer (int ndim, maybelong *shape, NumarrayType type, PyObject *bufferObject, maybelong byteoffset, maybelong bytestride, int byteorder, int aligned, int writeable) Please try it out.
Excellent. That's good to hear!
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Seems to work right away. But now I get this:
Sorry to frighten you... :-( I am just experimenting with from __future__ import division Apparently taking that line out again fixes the problem. I am actually not sure what the "proposed policy" is on that future division thing; I just thought I could simplify some explanation to non-Python people if 1/3 is not 0. Probably numarray has more important things to worry about - but maybe you can put it on the list.. Thanks for your work. Sebastian
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
----- Original Message ----- From: "Sebastian Haase" <haase@msg.ucsf.edu> To: "Todd Miller" <jmiller@stsci.edu> Cc: "numpy-discussion" <numpy-discussion@lists.sourceforge.net> Sent: Monday, July 28, 2003 5:02 PM Subject: Re: [Numpy-discussion] ANNOUNCE: numarray-0.6
We have't added support for future division yet.
Apparently taking that line out again fixes the problem.
I am actually not sure what the "proposed policy" is on that future
thing; I just thought I could simplify some explanation to non-Python
Good. division people
if 1/3 is not 0.
I believe we're going to support future division eventually. I'm not sure how soon.
Probably numarray has more important things to worry about - but maybe you can put it on the list..
It's on "the list".
Thanks for your work.
You're welcome. I hope you find it useful.
Sebastian
![](https://secure.gravatar.com/avatar/05e73d24d898a94bd87036088bbdb344.jpg?s=120&d=mm&r=g)
Todd Miller wrote:
GREAT. And what is even more great - I see that the version adapted to Python 2.3 is there. In some private exchange I read "of course we will upgrade, but 2.3 is beta, let's wait when it stabilizes". I sincerely think that all essential goodies (and numarray is one of them) should evolve in parallel with the kernel. Personally I wouldn't touch new versions of Python without having those additional goodies, since I wouldn't know what to do with it. Just playing with Guido's tutorial, or what? Thank you. Jerzy Karczmarczuk Caen, France
participants (4)
-
Francesc Alted
-
Jerzy Karczmarczuk
-
Sebastian Haase
-
Todd Miller