Mailman 3 July 2004 - NumPy-Discussion

numarray-1.0 Bug Alert
by Todd Miller July 14, 2004

July 14, 2004

Overview There is a bug in numarray's Numeric compatible C-API. The bug has been latent for a long time, since numarray-0.3 was released roughly two years ago. It is serious because it results in wrong answers for a certain extension functions fed a certain class of arrays. What's affected The bug affects affects numarray's add-on packages or third party extension functions which use the Numeric compatibility C-API. Generally, this means C-code that was either ported from Numeric or was written with both Numeric and numarray in mind. This includes the add-on packages numarray.linear_algebra, numarray.fft, numarray.random_array, and numarray.mlab. More recently, it includes the ports of core Numeric functions to numarray.numeric. Because numarray.ma uses numarray.numeric, the bug also affects numarray.ma. Finally, for numarray-1.0 this bug affects the functions numarray.argmin and numarray.argmax; these should be the only two functions in core numarray which are affected. Detailed Bug Description The bug is exposed by calling an extension function (written using the Numeric compatible C-API) with an array that has a non-zero _byteoffset attribute. Arrays with non-zero _byteoffset are typically created as a result of partially indexing higher dimensional arrays or slicing arrays. Partially indexing or slicing an array generally results in a sub-array, a view which often refers to an interior region of the original array buffer. Because numarray's PyArrayObject does not currently include it's ->byteoffset in its ->data pointer as the Numeric compatibility API assumes it does, an extension function sees the base region of the original array rather than the region belonging to the sub-array. Immediate User Workaround A simple user level workaround for people that need to use the affected packages and functions today is one like the following: def make_safe_for_numeric_api(a): a = numarray.asarray(a) if a._byteoffset != 0: return a.copy() else: return a The array inputs to an affected extension function need to be wrapped with calls to make_safe_for_numeric_api(). Since this is intrusive and a real fix should be released in the near future, this approach is not recommended. Long Term Fix The real fix for the bug appears to be to redefine the semantics of numarray's PyArrayObject ->data pointer to include ->byteoffset, altering the C-API. This should make most existing Numeric compatible extension functions work without modification or recompilation, but will necessitate the re-compilation of some extension functions written using the native numarray API approaches (the NA_* functions and macros). This recompilation will be required because key macros will change, most notably NA_OFFSETDATA. This fix is not the only possible one, and other suggestions are welcome, but changing the semantics of ->data appears to be the best way to facilitate numarray/Numeric interoperability. By doing this fix, numarray operates more like Numeric so fewer changes need to be made in the future to perform ports of Numeric code to numarray. Impact of Proposed Fix Regrettably, the proposed fix will break binary compatibility for clients of the numarray-1.0 native C-API. So, extensions built using the numarray native C-API will need to be rebuilt for numarray-1.1. Extensions that have made direct access to PyArrayObject's ->data and require the original offsetless meaning will also need to change code for numarray-1.1. This is something we *really* wanted to avoid... it just isn't going to happen this time. The Plan The current plan is to fix the Numeric compatible API by changing the semantics of ->data and release numarray-1.1 relatively soon, hopefully within 2 weeks. I'm sorry for any inconvenience this has caused numarray users. Regards, Todd Miller

2 2

ANN: Reminder -- SciPy 04 is coming up
by eric jones July 13, 2004

July 13, 2004

Hey folks, Just a reminder that SciPy 04 is coming up. More information is here: http://www.scipy.org/wikis/scipy04 About the Conference and Keynote Speaker --------------------------------------------- The 1st annual *SciPy Conference* will be held this year at Caltech, September 2-3, 2004. As some of you may know, we've experienced great participation in two SciPy "Workshops" (with ~70 attendees in both 2002 and 2003) and this year we're graduating to a "conference." With the prestige of a conference comes the responsibility of a keynote address. This year, Jim Hugunin has answered the call and will be speaking to kickoff the meeting on Thursday September 2nd. Jim is the creator of Numeric Python, Jython, and co-designer of AspectJ. Jim is currently working on IronPython--a fast implementation of Python for .NET and Mono. Presenters ----------- We still have room for a few more standard talks, and there is plenty of room for lightning talks. Because of this, we are extending the abstract deadline until July 23rd. Please send your abstract to abstracts(a)scipy.org. Travis Oliphant is organizing the presentations this year. (Thanks!) Once accepted, papers and/or presentation slides are acceptable and are due by August 20, 2004. Registration ------------- Early registration ($100.00) has been extended to July 23rd. Follow the links off of the main conference site: http://www.scipy.org/wikis/scipy04 After July 23rd, registration will be $150.00. Registration includes breakfast and lunch Thursday & Friday and a very nice dinner Thursday night. Please register as soon as possible as it will help us in planning for food, room sizes, etc. Sprints -------- As of now, we really haven't had much of a call for coding sprints for the 3 days prior to SciPy 04. Below is the original announcement about sprints. If you would like to suggest a topic and see if others are interested, please send a message to the list. Otherwise, we'll forgo the sprints session this year. We're also planning three days of informal "Coding Sprints" prior to the conference -- August 30 to September 1, 2004. Conference registration is not required to participate in the sprints. Please email the list, however, if you plan to attend. Topics for these sprints will be determined via the mailing lists as well, so please submit any suggestions for topics to the scipy-user list: list signup: http://www.scipy.org/mailinglists/ list address: scipy-user(a)scipy.org thanks, eric

1 0

Re: [Numpy-discussion] differencing numarray arrays.
by Mike Zingale July 13, 2004

July 13, 2004

thanks, all these responses helped. I guess I was still a little unclear with the slicing abilities in numarray. Mike On Tue, 13 Jul 2004, Paul Dubois wrote: > Two of the responses to your question, while correct, might have seemed > mysterious to a beginner. > > a[1:] - a[:-1] > > is actually shorthand for: > > a[1:, :] - a[:-1, :] > > Or to be even more explicit: > > n = 8 > a[1:n, 0:n] - a[0:(n-1), 0:n] > > If you had wanted the difference in the second index, you have to use > the more explicit forms. > > >

2 1

differencing numarray arrays.
by Mike Zingale July 13, 2004

July 13, 2004

Hi, I am trying to efficiently compute a difference of two 2-d flux arrays, as arises quite commonly in finite-difference/finite-volume methods. Ex: a = arange(64) a.shape = (8,8) I want to do create a new array, b, of shape such that b[i,j] = a[i,j] - a[i-1,j] for 1 <= i < 8 0 <= i < 8 I can obviously do this through loops, but this is quite slow. In IDL, which is often compared to numarray/python, this is simple to do with the shift() function, but I cannot find an efficient way to do it with numarray arrays. I tried defining a list i = range(8) im1[1:9] = im1[1:9] - 1 and indexing with im1, but this does not work. Any suggestions? For large array, this simple differencing in python is very expensive when using loops. Thanks, Mike ------------------------------------------------------------------------------ Michael Zingale UCO/Lick Observatory UCSC Santa Cruz, CA 95064 phone: (831) 459-5246 fax: (831) 459-5265 e-mail: zingale(a)ucolick.org web: http://www.ucolick.org/~zingale ``Don't worry head, the computer will do our thinking now'' -- Homer

3 2

PyTables 0.8.1 released
by Francesc Alted July 13, 2004

July 13, 2004

PyTables is a hierarchical database package designed to efficiently manage very large amounts of data. PyTables is built on top of the HDF5 library and the numarray package. It features an object-oriented interface that, combined with natural naming and C-code generated from Pyrex sources, makes it a fast, yet extremely easy-to-use tool for interactively saving and retrieving different kinds of datasets. It also provides flexible indexed access on disk to anywhere in the data. The primary purpose of this release is to incorporate updates to related to the newly released numarray 1.0. I've taken the opportunity to backport some improvements added in PyTables 0.9 (in alpha stage) as well as to fix the known problems Improvements: - The logic for computing the buffer sizes has been revamped. As a consequence, the performance of writing/reading tables with large record sizes has improved by a factor of ten or more, now exceeding 70 MB/s for writing and 130 MB/s for reading (using compression). - The maximum record size for tables has been raised to 512 KB (before it was 8 KB, due to some internal limitations) - Documentation has been improved in many minor details. As a result of a fix in the underlying documentation system (tbook), chapters start now at odd pages, instead of even. So those of you who want to print to double side probably will have better luck now when aligning pages ;). Another one is that HTML documentation has improved its look as well. Bug Fixes: - Indexing of Arrays with list or tuple flavors (#968131) When retrieving single elements from an array with 'List' or 'Tuple' flavors, an error occurred. This has been corrected and now you can retrieve fileh.root.array[2] without problems for 'List' or 'Tuple' flavored (E, VL)Arrays. - Iterators on Arrays with list or tuple flavors fail (#968132) When using iterators with Array objects with 'List' or 'Tuple' flavors, an error occurred. This has been corrected. - Last Index (-1) of Arrays doesn't work (#968149) When accessing to the last element in an Array using the notation -1, an empty list (or tuple or array) is returned instead of the proper value. This happened in general with all negative indices. Fixed. - Table.read(flavor="List") should return pure lists (#972534) However, it used to return a pointer to numarray.records.Record instances, as in: >>> fileh.root.table.read(1,2,flavor="List") [<numarray.records.Record instance at 0x4128352c>] >>> fileh.root.table.read(1,3,flavor="List") [<numarray.records.Record instance at 0x4128396c>, <numarray.records.Record instance at 0x41283a8c>] Now the next records are returned: >>> fileh.root.table.read(1,2, flavor=List) [(' ', 1, 1.0)] >>> fileh.root.table.read(1,3, flavor=List) [(' ', 1, 1.0), (' ', 2, 2.0)] In addition, when reading a single row of a table, a numarray.records.Record pointer was returned: >>> fileh.root.table[1] <numarray.records.Record instance at 0x4128398c> Now, it returns a tuple: >>> fileh.root.table[1] (' ', 1, 1.0) Which I think is more consistent, and more Pythonic. - Copy of leaves fails... (#973370) Attempting to copy leaves (Table or Array with different flavors) on top of themselves caused an internal error in PyTables. This has been corrected by silently avoiding the copy and returning the original Leaf as a result. Minor changes: - When assigning a value to a non-existing field in a table row, now a KeyError is raised, instead of the AttributeError that was issued before. I think this is more consistent with the type of error. - Tests have been improved so as to pass the whole suite when compiled in 64 bit mode on a Linux/PowerPC machine (namely a dual-G5 Powermac running a 64-bit, 2.6.4 Linux kernel and the preview YDL distribution for G5, with 64-bit GCC toolchain). Thanks to Ciro Cattuto for testing and reporting the modifications that were needed. Where PyTables can be applied? ------------------------------ PyTables is not designed to work as a relational database competitor, but rather as a teammate. If you want to work with large datasets of multidimensional data (for example, for multidimensional analysis), or just provide a categorized structure for some portions of your cluttered RDBS, then give PyTables a try. It works well for storing data from data acquisition systems (DAS), simulation software, network data monitoring systems (for example, traffic measurements of IP packets on routers), very large XML files, or for creating a centralized repository for system logs, to name only a few possible uses. What is a table? ---------------- A table is defined as a collection of records whose values are stored in fixed-length fields. All records have the same structure and all values in each field have the same data type. The terms "fixed-length" and "strict data types" seem to be quite a strange requirement for a language like Python that supports dynamic data types, but they serve a useful function if the goal is to save very large quantities of data (such as is generated by many scientific applications, for example) in an efficient manner that reduces demand on CPU time and I/O resources. What is HDF5? ------------- For those people who know nothing about HDF5, it is a general purpose library and file format for storing scientific data made at NCSA. HDF5 can store two primary objects: datasets and groups. A dataset is essentially a multidimensional array of data elements, and a group is a structure for organizing objects in an HDF5 file. Using these two basic constructs, one can create and store almost any kind of scientific data structure, such as images, arrays of vectors, and structured and unstructured grids. You can also mix and match them in HDF5 files according to your needs. Platforms --------- I'm using Linux (Intel 32-bit) as the main development platform, but PyTables should be easy to compile/install on many other UNIX machines. This package has also passed all the tests on a UltraSparc platform with Solaris 7 and Solaris 8. It also compiles and passes all the tests on a SGI Origin2000 with MIPS R12000 processors, with the MIPSPro compiler and running IRIX 6.5. It also runs fine on Linux 64-bit platforms, like an AMD Opteron running SuSe Linux Enterprise Server or PowerPC G5 with Linux 2.6.x in 64bit mode. It has also been tested in MacOSX platforms (10.2 but should also work on newer versions). Regarding Windows platforms, PyTables has been tested with Windows 2000 and Windows XP (using the Microsoft Visual C compiler), but it should also work with other flavors as well. An example? ----------- For online code examples, have a look at http://pytables.sourceforge.net/html/tut/tutorial1-1.html and, for newly introduced Variable Length Arrays: http://pytables.sourceforge.net/html/tut/vlarray2.html Web site -------- Go to the PyTables web site for more details: http://pytables.sourceforge.net/ Share your experience --------------------- Let me know of any bugs, suggestions, gripes, kudos, etc. you may have. Enjoy! -- Francesc Alted

1 0

Re: [Numpy-discussion] How to read data from text files fast?
by Chris Barker July 9, 2004

July 9, 2004

Bruce, Thanks for your feedback. Bruce Southey wrote: > While I am not really following your thread, I just wanted to comment that the > Python Cookbook (at least the printed version) has some ways to count lines in a > file - assuming that the number of lines provides the size. The number of lines does not necessarily provide the size. In the general case, it doesn't at all. My whole goal here is the general case: being able to read a bunch of numbers out of any format of text file. This can be used as part of a parser for many file formats. If I was shooting for just one format, this would be easier, but not general purpose. Now that I have this, I can write a number of file format parsers in python with improved performance and easier syntax. Under Unix (but not > windows), I am aiming for a portable solution. > Alternatively if sufficient memory is available, storing the file in memory > (during the counting of elements) should always be faster than reading it a > second time from the hard disk. The primary reason to scan the file ahead of time to count the elements is to save the memory of duplicate copies of data. The other reason is to make memory management easier, but since I've already solved that problem, I'm done. thanks, -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(a)noaa.gov

1 0

Numpy compiling error... Help!
by Thomas Karlsson July 9, 2004

July 9, 2004

Hi I'm trying to compile/install numpy on a RH9 machine. When doing so I run into problems. I give the command: python setup.py install and get a long answer, with this error at the end: gcc -shared build/temp.linux-i686-2.2/lapack_litemodule.o -L/usr/lib/atlas -llapack -lcblas -lf77blas -latlas -lg2c -o build/lib.linux-i686-2.2/lapack_lite.so /usr/bin/ld: cannot find -llapack collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 Does anyone know what I've done wrong? I've spent alot of time on this and really needs help now... Regards Thomas _________________________________________________________________ Hitta rätt på nätet med MSN Sök http://search.msn.se/

1 0

Re: [Numpy-discussion] How to read data from text files fast?
by Chris Barker July 8, 2004

July 8, 2004

Todd Miller wrote: > I looked this over to see how hard it would be to port to numarray. At > first glance, it looks easy. I didn't really read it closely enough to > pick up bugs, but what I saw looks good. One thing I did notice was a > calloc of temporary data space. That seemed like a possible waste: can't > you just preallocate the array and read your data directly into it? The short answer is that I'm not very smart! The longer answer is that this is because at first I misunderstood what PyArray_FromDimsAndData was for. For ScanFileN, I'll re-do it as you suggest. For ScanFile, it is unknown at the beginning how big the final array is, and I did scheme that would allocate the memory as it went, in reasonable sized chunks. However, this does require a full copy, which is a problem. Since posting, I thought of a MUCH easier scheme: scan the file, without storing the data, to see how many numbers there are. rewind the file allocate the Array Read the data. This requires scanning the file twice, which would cost, but would be easier, and prevent an unnecessary copy of the data. I hope I"ll get a change to try it out and see what the performance is like. IN the meantime, anyone else have any thoughts? By the way, does it matter whether I use malloc or calloc? I can't really tell the difference from K&R. > This is > probably a very minor speed issue, but might be a significant storage issue > as people are starting to max out 32-bit systems. yup. This is all pointless if it's not a lot of data, after all. -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(a)noaa.gov

1 1

"buffer not aligned on 8 byte boundary" errors when running numarray.testall.test()
by Wendy Langer July 8, 2004

July 8, 2004

Hi there all :) I am having trouble with my installation of numarray. :( I am a python newbie and a numarray extreme-newbie, so it could be that I don't yet have the first clue what I am doing. ;) Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)] on win32 numarray 1.0 The Python I am using is the one that comes with the "Enthought" version (www.enthought.com), a distro specifically designed to be useful for scientists, so it comes with numerical stuff and scipy and chaco and things like that preinstalled. I used the windows binary installer. However it came with Numeric and not numarray, so I installed numarray "by hand". This seemed to go ok, and it seems that there is no problem having both Numeric and numarray in the same installation, since they have (obviously) different names (still getting used to this whole modules and namespaces &c &c) At the bottom of this email I have pasted an example of what it was I was trying to do, and the error messages that the interpreter gave me - but before anyone bothers reading them in any detail, the essential error seems to be as follows: error: multiply_Float64_scalar_vector: buffer not aligned on 8 byte boundary. I have no idea what this means, but I do recall that when I ran the numarray.testall.test() procedure after first completing my installation a couple of days ago, it reported a *lot* of problems, many of which sounded quite similar to this. I hoped for the best and thought that perhaps I had "run the test wrong"(!) since numarray seemed to be working ok, and I had investigated many of the examples in chapters 3 and 4 of the user manual withour any obvious problems (chapter 3 = "high level overview" and chapter 4 = "array basics") I decided at the time to leave well enough alone until I actually came across odd or mysterious behaviour ...however that time has come all-too-soon... The procedure I am using to run the test is as described on page 11 of the excellent user's manual (release 0.8 at http://www.pfdubois.com/numpy/numarray.pdf): --------------------------------------------- Testing your Installation Once you have installed numarray, test it with: C:\numarray> python Python 2.2.2 (#18, Dec 30 2002, 02:26:03) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import numarray.testall as testall >>> testall.test() numeric: (0, 1115) records: (0, 48) strings: (0, 166) objects: (0, 72) memmap: (0, 75) Each line in the above output indicates that 0 of X tests failed. X grows steadily with each release, so the numbers shown above may not be current. ------------------------------------------------------------------------ Anyway, when I ran this, instead of the nice, comforting output above, I got about a million(!) errors and then a final count of 320 failures. This number is not always constant - I recall the first time I ran it it was 209. [I just ran it again and this time it was 324...it all has a rather disturbing air of semi-randomness...] So below is the (heavily snipped) output from the testall.test() run, and below that is the code where I first noticed a possibly similar error, and below *that* is the output of that code, with the highly suspicous error.... Any suggestions greatly appreciated! I can give you more info about the setup on my computer and so on if you need :) wendy langer ====================================================================== <output when I ran numarray.testall.test() > ==================================== IDLE 1.0.2 ==== No Subprocess ==== >>> import numarray.testall as testall >>> testall.test() ***************************************************************** Failure in example: x+y from line #50 of first pass Exception raised: Traceback (most recent call last): File "C:\PYTHON23\lib\doctest.py", line 442, in _run_examples_inner compileflags, 1) in globs File "<string>", line 1, in ? File "C:\PYTHON23\Lib\site-packages\numarray\numarraycore.py", line 733, in __add__ return ufunc.add(self, operand) error: Int32asFloat64: buffer not aligned on 8 byte boundary. ***************************************************************** Failure in example: x[:] = 0.1 from line #72 of first pass Exception raised: Traceback (most recent call last): File "C:\PYTHON23\lib\doctest.py", line 442, in _run_examples_inner compileflags, 1) in globs File "<string>", line 1, in ? error: Float64asBool: buffer not aligned on 8 byte boundary. ***************************************************************** Failure in example: y from line #74 of first pass Expected: array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) Got: array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.]) ***************************************************************** Failure in example: x + z from line #141 of first pass Exception raised: Traceback (most recent call last): File "C:\PYTHON23\lib\doctest.py", line 442, in _run_examples_inner compileflags, 1) in globs File "<string>", line 1, in ? File "C:\PYTHON23\Lib\site-packages\numarray\numarraycore.py", line 733, in __add__ return ufunc.add(self, operand) error: Int32asFloat64: buffer not aligned on 8 byte boundary. ***************************************************************** <BIG SNIP!!!!!!!!!!!!> <snip a lot more errors> ***************************************************************** Failure in example: a2dma = average(a2dm, axis=1) from line #812 of numarray.ma.dtest Exception raised: Traceback (most recent call last): File "C:\PYTHON23\lib\doctest.py", line 442, in _run_examples_inner compileflags, 1) in globs File "<string>", line 1, in ? File "C:\PYTHON23\Lib\site-packages\numarray\ma\MA.py", line 1686, in average w = Numeric.choose(mask, (1.0, 0.0)) File "C:\PYTHON23\Lib\site-packages\numarray\ufunc.py", line 1666, in choose return _choose(selector, population, outarr, clipmode) File "C:\PYTHON23\Lib\site-packages\numarray\ufunc.py", line 1573, in __call__ result = self._doit(computation_mode, woutarr, cfunc, ufargs, 0) File "C:\PYTHON23\Lib\site-packages\numarray\ufunc.py", line 1558, in _doit blockingparameters) error: choose8bytes: buffer not aligned on 8 byte boundary. ***************************************************************** Failure in example: alltest(a2dma, [1.5, 4.0]) from line #813 of numarray.ma.dtest Exception raised: Traceback (most recent call last): File "C:\PYTHON23\lib\doctest.py", line 442, in _run_examples_inner compileflags, 1) in globs File "<string>", line 1, in ? NameError: name 'a2dma' is not defined ***************************************************************** 1 items had failures: 320 of 671 in numarray.ma.dtest ***Test Failed*** 320 failures. numarray.ma: (320, 671) </output when I ran numarray.testall.test() > ========================================================================= <my code> ======================== import numarray class anXmatrix: def __init__(self, stepsize = 3): self.stepsize = stepsize self.populate_matrix() def describe(self): print "I am a ", self.__class__ print "my stepsize is", self.stepsize print "my matrix is: \n" print self.matrix def populate_matrix(self): def xvalues(i,j): return self.stepsize*j mx = numarray.fromfunction(xvalues, (4,4)) self.matrix = mx if __name__ == '__main__': print " " print "Making anXmatrix..." r = anXmatrix(stepsize = 5) r.describe() r = anXmatrix(stepsize = 0.02) r.describe() </my code> ============================================================================ ======== <output from interpreter when I run my code> Making anXmatrix... I am a __main__.anXmatrix my stepsize is 5 my matrix is: [[ 0 5 10 15] [ 0 5 10 15] [ 0 5 10 15] [ 0 5 10 15]] Traceback (most recent call last): File "C:\Python23\Lib\site-packages\WendyStuff\wendycode\propagatorstuff\core_obj ects\domain_objects.py", line 97, in ? r = anXmatrix(stepsize = 0.02) File "C:\Python23\Lib\site-packages\WendyStuff\wendycode\propagatorstuff\core_obj ects\domain_objects.py", line 72, in __init__ self.populate_matrix() File "C:\Python23\Lib\site-packages\WendyStuff\wendycode\propagatorstuff\core_obj ects\domain_objects.py", line 86, in populate_matrix mx = numarray.fromfunction(xvalues, (4,4)) File "C:\PYTHON23\Lib\site-packages\numarray\generic.py", line 1094, in fromfunction return apply(function, tuple(indices(dimensions))) File "C:\Python23\Lib\site-packages\WendyStuff\wendycode\propagatorstuff\core_obj ects\domain_objects.py", line 84, in xvalues return self.stepsize*j File "C:\PYTHON23\Lib\site-packages\numarray\numarraycore.py", line 772, in __rmul__ r = ufunc.multiply(operand, self) error: multiply_Float64_scalar_vector: buffer not aligned on 8 byte boundary. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </output from interpreter when I run my code> ============================================================================ ======== "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." Albert Einstein

2 1

optional arguments to the array constructor
by Philip Austin July 7, 2004

July 7, 2004

(for numpy v1.0 on Mandrake 10 i686) As noted on p. 25 the array constructor takes up to 5 optional arguments array(sequence=None, type=None, shape=None, copy=1, savespace=0,typecode=None) (and raises an exception if both type and typecode are set). Is there any way to make an alias (copy=0) of an array without passing keyword values? That is, specifying the copy keyword alone works: test=N.array((1., 3), "Float64", shape=(2,), copy=1, savespace=0) a=N.array(test, copy=0) a[1]=999 print test >>> [ 1. 999.] But when intervening keywords are specified copy won't toggle: test=N.array((1., 3)) a=N.array(sequence=test, type="Float64", shape=(2,), copy=0) a[1]=999. print test >>> [ 1. 3.] Which is also the behaviour I see when I drop the keywords: test=N.array((1., 3)) a=N.array(test, "Float64", (2,), 0) a[1]=999. print test >>> [ 1. 3.] an additional puzzle is that adding the savespace parameter raises the following exception: >>> a=N.array(test, "Float64", (2,), 0,0) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 312, in array type = getTypeObject(sequence, type, typecode) File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 256, in getTypeObject rtype = _typeFromTypeAndTypecode(type, typecode) File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 243, in _typeFromTypeAndTypecode raise ValueError("Can't define both 'type' and 'typecode' for an array.") ValueError: Can't define both 'type' and 'typecode' for an array. Thanks for any insights -- Phil

2 5