Mailman 3 April 2005 - NumPy-Discussion

Questions about ufuncs now.
by Travis Oliphant 06 Apr '05

06 Apr '05

The arrayobject for scipy.base seems to be working. Currently the Numeric3 CVS tree is using the "old-style" ufuncs modified with new code for the newly added types. It should be quite functionable now for the brave at heart. I'm now working on modifying the ufunc object for scipy.base. These are the changes I'm working on: 1) a thread-specific? context that allows "buffer-size" level trapping of errors and retrieving of flags set. Similar to the decimal.context specification, but it uses the floating point sticky bits to implement. 2) implementation of buffers so that type-conversions (and byteswapping and alignment if necessary) never creates temporaries larger than the buffer-size (the buffer-size is user settable). 3) a reworking of the general N-dimensional loop to use array iterators with optimizations applied for contiguous arrays. 4) Alteration of coercion rules so that scalars (i.e. rank-0 arrays) do not dictate coercion rules Also, change so that certain mixed-type operations are computed in larger type for both. Most of this is pretty straightforward. But, I do have one addiitonal question. Do the new array scalars count as "non-coercing" scalars (i.e. like the Python scalars), or do they cause coercion? My preference is that ALL scalars (anything that becomes 0-dimensional arrays internally) cause only "kind-casting" (i.e. int to float, float to complex, etc.) but not "type-casting" -Travis

2 1

Array Metadata
by Scott Gilbert 06 Apr '05

06 Apr '05

I got back late last night, and there were lots of things I wanted to comment on. I've put parts of several threads into this one message since they're all dealing with the same general topic: Perry Greenfield wrote: > > I'm not sure how the support for large data sets should be handled. > I generally think that it will be very awkward to handle these > until Python does as well. Speaking of which... > I agree that it's going to be difficult to have general support for large PyBufferProcs objects until the Python core is made 64 bit clean. But specific support can be added for buffer types that are known in advance. For instance, the bytes object PEP proposes an alternate way to get a 64 bit length, and similar support could easily be added to Numarray.memory, mmap.mmap, and whatever else on a case by case basis. So you could get a 64 bit pointer from some types of buffers before the rest of Python becomes 64 bit clean. If the ndarray consumer (wxWindows for instance) doesn't recognize the particular implementation, it has to stick with the limitations of the standard PyBufferProcs and assume a 32 bit length would suffice. Travis Oliphant wrote: > > I prefer __array_data__ (it's a common name for Numeric and > numarray, It can be interpreted as a sequence object if desired). > So long as everyone agrees it doesn't matter what name it is. Sounds like __array_data__ works for everyone. > > I also like __array_typestr__ or __array_typechar__ better as a name. > A name is a name as far as I'm concerned. The name __array_typestr__ works for me. The name __array_typechar__ implies a single character, and that won't be true. > > Don't like 'D' for long double. Complex floats is already > using it. I'm not sure I like the idea of moving to two > character typecodes at this point because it indicates more > internal changes to Numeric3 (otherwise we have two typecharacter > standards which is not a good thing). What is wrong with 'g' > and 'G' for long double and complex long double respectively. > Nothing in this array protocol should *require* internal changes to either Numeric3 or Numarray. I suspect Numarray is going to keep it's type hierarchy, and Numeric3 can use single character codes for it's representation if it wants. However, both Numeric3 and Numarray might (probably would) have to translate their internal array type specifiers into the agreed upon "type code string" when reporting out this attribute. The important qualities __array_typestr__ should have are: 1) Everyone should agree on the interpretation. It needs to be documented somewhere. Third party libraries should get the same __array_typestr__ from Numarray as they do from Numeric3. 2) It should be sufficiently general in it's capabilities to describe a wide category of array types. Simple things should be simple, and harder things should be possible. An ndarray of double should have a simple common well recognized value for __array_typestr__. An ndarray of a multi-field structs should be representable too. > > > > > __array_complicated__ > > > > I don't see the utility here I guess, If it can't be described by a > shape/strides combination then how can it participate in the protocol? > I'm not married to this one. I don't know if Numarray or Numeric3 will ever do such a thing, but I can imagine more complicated schemes of arranging the data than offset/shape/strides are capable of representing. So this is forward compatibility with "Numarric4" :-). Pretty hypothetical, but imagine that typically Numarric4 can represent it's data with offset/shape/strides, but for more advanced operations that falls apart. I could bore you with a detailed example... The idea is that if array consumers like wxPython were aware that more complicated implementations can occur in the future, they can gracefully bow out and raise an exception instead of incorrectly interpreting the data. If you need it later, you can't easily add it after the fact. Take it or leave it I guess - it's possibly a YAGNI. > > After more thought, I think here we need to also allow the > "c-type" independent way of describing an array (i.e. numarray > introduced 'c4' for a complex-valued 4 byte itemsize array). > So, perhaps __array_ctypestr_ and __array_typestr__ should be > two ways to get the information (or overload the __array_typestr__ > interface and reequire consumers to accept either style). > I don't understand what you are proposing here. Why would you want to represent the same information two different ways? Perry Greenfield wrote: > > I think we need to think about what the typecharacter is supposed > to represent. Is it the value as the user will see it or to indicate > what the internal representation is? These are two different things. > I think __array_typestr__ should accurately represent the internal representation. It is not intended for typical end users. The whole of the __array_*metadata*__ stuff is intended for third party libraries like wxPython or PIL to be able to grab a pointer to the data, calculate offsets, and cast it to the appropriate type without writing lots of special case code to handle the differences between Numeric, Numarray, Numeric3, and whatever else. > > Then again, I'm not sure how this info is exposed to the user; if it > is appropriately handled by intermediate code it may not matter. For > example, if this corresponds to what the user will see for the type, > I think it is bad. Most of the time they don't care what the internal > representation is, they just want to know if it is Int16 or whatever; > with the two combined, they have to test for both variants. > Typical users would call whatever attribute or method you prefer (.type() or .typecode() for instance), and the type representation could be classes or typecodes or whatever you think is best. The __array_typestr__ attribute is not for typical users (unless they start to care about the details under the hood). It's for libraries that need to know what's going on in a generic fashion. You don't have to store this attribute as separate data, it can be a property style attribute that calculates it's value dynamically from your own internal representation. Francesc Altet wrote: > > Considering that heterogenous data is to be suported as well, and > there is some tradition of assigning names to the different fields, > I wonder if it would not be good to add something like: > > __array_names__ (optional comma-separated names for record fields) > I really like this idea. Although I agree with David M. Cooke that it should be a tuple of names. Unless there is a use case I'm not considering, it would be preferrable if the names were restricted to valid Python identifiers. Travis Oliphant wrote: > > After more thought, I think using the struct-like typecharacters > is not a good idea for the array protocol. I think that the > character codes used by the numarray record array: kind_character > + byte_width is better. Commas can separate heterogeneous data. > The problem is that if the data buffer originally came from a > different machine or saved with a different compiler (e.g. a mmap'ed > file), then the struct-like typecodes only tell you the c-type that > machine thought the data was. It does not tell you how to interpret > the data on this machine. > The struct module has a portable set of typecodes. They call it "standard", but it's the same thing. The struct module let's you specify either standard or native. For instance, the typecode for "standard long" ("=l") is always 4 bytes while a "native long" ("@l") is likely to be 4 or 8 bytes depending on the platform. The __array_typestr__ codes should require the "standard" sizes. There is a table at the bottom of the documentation that goes into detail: http://docs.python.org/lib/module-struct.html The only problem with the struct module is that it's missing a few types... (long double, PyObject, unicode, bit). > > I also think that rather than attach < or > to the start of the > string it would be easier to have another protocol for endianness. > Perhaps something like: > > __array_endian__ (optional Python integer with the value 1 in it). > If it is not 1, then a byteswap must be necessary. > This has the problem you were just describing. Specifying "byteswapped" like this only tells you if the data was reversed on the machine it came from. It doesn't tell you what is correct for the current machine. Assuming you represented little endian as 0 and big endian as 1, you could always figure out whether to byteswap like this: byteswap = data_endian ^ host_endian Do you want to have an __array_endian__ where 0 indicates "little endian", 1 indicates "big endian", and the default is whatever the current host machine uses? I think this would work for a lot of cases. A limitation of this approach is that it can't adequately represent struct/record arrays where some fields are big endian and others are little endian. > > Bool -- "b%d" % sizeof(bool) > Signed Integer -- "i%d" % sizeof(<some int>) > Unsigned Integer -- "u%d" % sizeof(<some uint>) > Float -- "f%d" % sizeof(<some float>) > Complex -- "c%d" % sizeof(<some complex>) > Object -- "O%d" % sizeof(PyObject *) > --- this would only be useful on shared memory > String -- "S%d" % itemsize > Unicode -- "U%d" % itemsize > Void -- "V%d" % itemsize > The above is a nice start at reinventing the struct module typecodes. If you and Perry agree to it, that would be great. A few additions though: I think you're proposing that "struct" or "record" arrays would be a concatenation of the above strings. If so, you'll need an indicator for padding bytes. (You probably know this, but structs in C frequently have wasted bytes inserted by the compiler to make sure data is aligned on the machine addressable boundaries.) I also assume that you intend the ("c%d" % itemsize) to always represent complex floating point numbers. That leaves my favorite example of complex short integer data with no way to be represented... I guess I could get by with "i2i2". How about not having a complex type explicitly, but representing complex data as something like: __array_typestr__ = "f4f4 __array_names__ = ("real", "imag") Just a thought... I do like it though. I think that both Numarray and Numeric3 are planning on storing booleans in a full byte. A typecode for tightly packed bits wouldn't go unused however... > > 1) How do you support > 2Gb memory mapped arrays on 32 bit systems > and other large-object arrays only a part of which are in memory at > any given time > Doing this well is a lot like implementing mmap in user space. I think this is a modification to the buffer protocol, not the array protocol. It would add a bit of complexity if you want to deal with it, but it is doable. Instead of just grabbing a pointer to the whole thing, you need to ask the object to "page in" ranges of the data and give you a pointer that is only valid in that range. Then when you're done with the pointer, you need to explicitly tell the object so that it can write back if necessary and release the memory for other requests. Do you think Numeric3 or Numarray would support this? I think it would be very cool functionality to have. > > (there is an equivalent problem for > 8 Eb (exabytes) on 64 bit > systems, an Exabyte is 2^60 bytes or a giga-giga-byte). > I think it will be at least 10-20 years before we could realisticly exceed a 64 bit address space. Probably a lot longer. That's a billion times more RAM than any machine I've ever worked on, and it's a million times more bytes than any RAID set I've worked with. Are there any super computers approaching this level? Even at Moore's law rates, I'm not worried about that one just yet. > > But, I've been thinking about the array protocol and thinking that > it would be a good thing if this became universal. One of the ways > to make it universal is by having something that follows it in the > Python core. > > So, what if we proposed for the Python core not something like > Numeric3 (which would still exist in scipy.base and be everybody's > favorite array :-) ), but a very minimal array object (scaled back > even from Numeric) that followed the array protocol and had some > C-API associated with it. > > This minimal array object would support 5 basic types ('bool', > 'integer', 'float', 'complex', 'Object'). (Maybe a void type > could be defined and a void "scalar" introduced (which would be > the bytes object)). These types correspond to scalars already > available in Python and so the whole 0-dim array Python scalar > arguments could be ignored. > I really like this idea. It could easily be implemented in C or Python script. Since half it's purpose is for documentation, the Python script implementation might make more sense. Additionally, a module that understood the defaults and did the right thing with the metadata attributes would be useful: def get_ndims(a): return len(a.__array_shape__) def get_offset(a): if hasattr(a, "__array_offset__"): return a.__array_offset__ return 0 def get_strides(a): if hasattr(a, "__array_strides__"): return a.array_strides # build the default strides from the shape def is_c_contiguous(a): shape = a.__array_shape__ strides = get_strides(a) # determine if the strides indicate it is contiguous def is_fortran_contiguous(a): # similar to is_c_contiguous etc... Thes functions could be useful for third party libraries to work with *any* of the array packages. > > An alternative would be to "add" multidimensionality to the array > object already part of Python, fix it's reallocating with an exposed > buffer problem, and add the array protocol. > I'd recommend not breaking backward compatibility on the array.array object, but adding the __array_*metadata*__ attributes wouldn't hurt anything. (The __array_shape__ would always be a tuple of length one, but that's allowed...). Magnus Lie Hetland wrote: > > Wohoo! Niiice :) > > (Okay, a bit "me too"-ish, but I just wanted to contribute some > enthusiasm ;) > I completely agree! :-) Cheers, -Scott

3 2

RE: [Numpy-discussion] Numeric 24.0
by S�bastien de Menten 06 Apr '05

06 Apr '05

Hi Travis, Could you look at bug [ 635104 ] segfault unpickling Numeric 'O' array [ 567796 ] unpickling of 'O' arrays causes segfault (duplicate of previous one) I proposed a (rather simple) solution that I put in the comment of bug [ 635104 ]. But apparently, nobody is looking at those bugs... > >I'd like to release a Numeric 24.0 to get the array interface out there. >There are also some other bug fixes in Numeric 24.0 > >Here is the list so far from Numeric 23.7 > >[Greenfield] Changed so a[0,0] and a[0][0] returns same type when a is 2-d >of Int16 This is quite disturbing. In fact for all types that are not exactly equivalent to python type, indexing a multidimensional array (rank > 1) return arrays even if the final shape is (). So type(zeros((5,2,4), Int8 )[0,0,0]) => <type 'array'> type(zeros((5,2,4), Int32 )[0,0,0]) => <type 'array'> type(zeros((5,2), Float32 )[0,0]) => <type 'array'> But type(zeros((5,2,4), Int )[0,0,0]) => <type 'int'> type(zeros((5,2,4), Float64)[0,0,0]) => <type 'float'> type(zeros((5,2,4), Float)[0,0,0]) => <type 'float'> type(zeros((5,2,4), PyObject)[0,0,0]) => <type 'int'> Notice too the weird difference betweeb Int <> Int32 and Float == Float64. However, when indexing a onedimensional array (rank == 1), then we get back scalar for indexing operations on all types. So, when you say "return the same type", do you think scalar or array (it smells like a recent discussion on Numeric3 ...) ? >[unreported] Added array interface >[unreported] Allow Long Integers to be used in slices >[1123145] Handle mu==0.0 appropiately in ranlib/ignpoi. >[unreported] Return error info in ranlib instead of printing it to stderr >[1151892] dot() would quit python with zero-sized arrays when using > dotblas. The BLAS routines *gemv and *gemm need LDA >= 1. >[unreported] Fixed empty for Object arrays > >Version 23.8 March 2005 >[Cooke] Fixed more 64-bit issues (patch 117603) >[unreported] Changed arrayfnsmodule back to PyArray_INT where the code > typecasts to (int *). Changed CanCastSafely to check > if sizeof(long) == sizeof(int) > > >I'll wait a little bit to allow last minute bug fixes to go in, but I'd >realy like to see this release get out there. For users of Numeric >23.7 >try >Numeric.empty((10,20),'O') if you want to see an *interesting* bug that is >fixed in CVS. > >-Travis > >

4 3

RE: [Rpy] [Fwd: Re: [Numpy-discussion] Possible example applicati on of the array interface]
by Warnes, Gregory R 06 Apr '05

06 Apr '05

Hi All, It is possible to establish conversion functions so that R dataframe, lists, and vector objects are better translated into python equivalents. I've made several aborted stabs at this, but my time has been extremely limited. The basic task is to create a functionally equivalent python class [The tricky bit here is that R list and vector objects have both order and names. It is possible to emulate this in python by creating a base object that maintains a dictionary of names in along side the data vector/matrix data.] See the example in the rpu documentation at http://rpy.sourceforge.net/rpy/doc/manual_html/DataFrame-class.html#DataFram e%20class. This shouldn't be very hard if someone can dedicate a bit of time to it. -Greg (Current RPy maintainer) > -----Original Message----- > From: rpy-list-admin(a)lists.sourceforge.net > [mailto:rpy-list-admin@lists.sourceforge.net]On Behalf Of Tim Churches > Sent: Wednesday, April 06, 2005 4:22 PM > To: rpy-list(a)lists.sourceforge.net > Subject: [Rpy] [Fwd: Re: [Numpy-discussion] Possible example > application > of the array interface] > > > The following discussion occured on the Numeric Python mailing list. > Others may wish to enjoin the conversation. > > Tim C > > -------- Original Message -------- > Subject: Re: [Numpy-discussion] Possible example application of the > array interface > Date: Thu, 7 Apr 2005 03:10:08 +1000 (EST) > From: Michael Sorich <mike_lists(a)yahoo.com.au> > To: numpy-discussion(a)lists.sourceforge.net > > I think that this is a great idea! While I have a > strong preference for python, I generally use R for > statistical analyses due to the large number of mature > libraries available. There are also some aspects of > the R data types (eg data-frames and column/row names > for 2D arrays) that are really nice for spreadsheet > like data. I hope that scipy.base record arrays will > be as easily manipulated as data-frames are. > > While RPy works well for small simple problems, there > are data conversion limitations between R and Python. > If one could efficiently convert between the major R > data types and python scipy.base data types without > loss of data, it would become possible to do most of > the data manipulation in python and freely mix in R > functions when required. This may encourage the use of > python for the development of statistical routines. > > >From my meager understanding of RPy: > > R vectors are converted to python lists. It may make > more sense to convert them to an array (either stdlib > or scipy.base version) - without copying data if > possible. > > R arrays and matrices are converted to Numeric arrays. > Eg > > In [8]: r.array([1,2,3,4,5,6],dim=[2,3]) > Out[8]: > array([[1, 3, 5], > [2, 4, 6]]) > > However, column and row names (or dimnames for arrays > with >2 dimensions) are lost in R->Py conversion. I do > not know whether these conversions require copying of > the data. > > R data-frames are currently converted to python > dictionaries and I don’t think that there is any > simple way to convert a python object to an R data > frame. This is the biggest limitation of rpy in my > opinion. > > In [16]: > r.data_frame(col1=[1,2,3,4],col2=['one','two','three','four']) > Out[16]: {'col2': ['one', 'two', 'three', 'four'], > 'col1': [1, 2, 3, 4]} > > If it were possible to convert between an R data-frame > and a scipy.base record array without copying or > losing data, RPy would become more useful. > > I wish I understood C, scipy.base and R well enough to > give this a go. However, this is Way over my head! > > Mike > > --- Magnus Lie Hetland <magnus(a)hetland.org> wrote: > > I was just thinking about some experimental designs, > > and whether I > > could, perhaps, do the statistics in Python. I > > remembered having used > > RPy [1] briefly at some time (there may be other > > similar bindings out > > there -- I don't remember) and started thinking > > about whether I could, > > perhaps, combine it with numpy in some way. My first > > thought was to > > reimplement the relevant statistical functions; then > > I thought about > > how to convert data back and forth -- but then it > > occurred to me that > > R also uses arrays extensively, and that it could, > > perhaps, be > > possible to expose those (through something like > > RPy) through the > > array interface/protocol! > > > > This would be (IMO) a good example of the benefits > > of the array > > protocol; it's not a matter of "getting yet another > > array module". RPy > > is an external library/language with *lots* of > > features that might be > > useful to numpy users, many of which aren't likely > > to be implemented > > in Python for quite a while, I'd guess (unless, > > perhaps, someone > > writes a translator from R, which I'm sure is > > doable). > > > > I don't know enough (at least yet ;) about the > > implementation of RPy > > and the R library to say for sure whether this would > > even be possible, > > but it does seem like it could be really useful... > > > > [1] rpy.sf.net > > > > -- > > Magnus Lie Hetland Fall seven > > times, stand up eight > > http://hetland.org > > [Japanese proverb] > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=click > _______________________________________________ > rpy-list mailing list > rpy-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rpy-list > > LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.

1 0

Re: [Numpy-discussion] Numeric 24.0
by Travis Oliphant 06 Apr '05

06 Apr '05

Michiel Jan Laurens de Hoon wrote: > Travis Oliphant wrote: > >> Again, scipy.base should *replace* Numerical Python for all users > > > Sorry, I give up. I have been very happy with Numerical Python so far > and the new Numerical Python just looks too much like SciPy to me. > It's even called scipy.base. In practical terms, what I've noticed is > that what used to work with Numerical Python no longer works with > Numeric3. For example: It's apparent you have negative pre-conceptions about scipy (even though scipy has always just built on top of Numeric so I'm not sure what your difficulties have been). This is unfortunate. scipy.base is going to be a lot more like Numeric than scipy was. So, I think you can relax. > > >>> from ndarray import * > >>> argmax > Traceback (most recent call last): > File "<stdin>", line 1, in ? > NameError: name 'argmax' is not defined This is only because the conversion hasn't completely taken place (I'm not importing the numeric.py module in __init__ yet because it hasn't been adjusted). Remember ndarray is just a place-holder while development happens, so of course quite a few things aren't there yet. I've been swamped so far. from ndarray import * won't even be the name to use. The package won't be called ndarray. This is all just for temporary development purposes. All of what you belive should work will still continue to work. So, relax..... > >>> > > From what I understand from the discussion, "from Numeric import *" > will still work, but it will be deprecated, which means that I will > have to change my code at some point. Not to mention the other > packages (LinearAlgebra, RandomArray, etc.). It's just too much trouble. Deprecated means new documentation won't teach that approach, that's pretty much it. The approach will still be supported for quite a while so people can switch when and if they want. I don't see "the trouble" at all. > Anyway, I am about to change jobs (I will be moving to Columbia > University soon), so I have decided to take some time off the > Numerical Python project and see where we stand in a few months time. > Hopefully, the situation will have cleared up by then. Sounds like an exciting move. Perhaps I can meet you in person if I'm in New York or if you are every in Utah. I sincerely hope you will find the new scipy.base to your liking. I can promise you that your concerns are near the top of my list. It's too bad you can't help us get there more quickly. -Travis

1 0

Re: [Numpy-discussion] metadata and metabehavior for arrays (for scipy.base or Numeric3)
by S�bastien de Menten 06 Apr '05

06 Apr '05

>> >>Maybe this one could be implemented using record array with a record like >>(data, mask). However, it would be cumbersome to use. E.g. >>a.field("data")[:] = cos( a.field("data")[:] ) instead of a[:] = cos(a[:]) >>with the current MA module > >Assuming "data" is the name of a field in a record array "a", why not have >a.data to represent a view (or copy, depending on the convention adopted) >of a column in a or a.data.Cos to provide the cosines of the values in the >data column? > >"Cos" is used in place of "cos" to distinguish the method from the >function. The former requires no parentheses. > Well, I think the whole point is to be able to use "without changes" any library that manipulate arrays with "augmented arrays": same code for all arrays independently of them being "naked" or "augmented". The "without changes" and "any library" should be taken with a pinch of salt as operation that are accepted for any array will not necessarily mean something for some "augmented arrays". On a side note, I rather prefer to keep mathematical notation instead of OO notation ( cos as function vs method )

1 0

Re: [Numpy-discussion] The array interface published
by Scott Gilbert 05 Apr '05

05 Apr '05

--- Magnus Lie Hetland <magnus(a)hetland.org> wrote: > > Do we really have to break backward compatibility in order to add more > dimensions to the array module? > You're right. The Python array module could change in a backwards compatible way. Possibly using keyword arguments to specify parameters that have never been there before. We could probably make sense out of array.insert(), array.append(), array.extend(), array.pop(), and array.reverse() by giving those an "axis" keyword. Even array.remove() could be made to work for more dimensions, but it probably wouldn't get used often. Maybe some of these would just raise an exception for ndims > 1. Then we'd have to add some additional typecodes for complex and a few others. Under the hood, it would basically be a complete reimplementation, but maybe that is the way to go... It does keep the number of array modules down. I wonder which way would meet less resistance in getting accepted in the core. I think creating a new ndarray object would be less risk of breaking existing applications. > > There may be some issues with, e.g., typecode, but still... > The .typecode attribute could return the same values it always has. The .__array_typestr__ attribute would return the new style values. That's confusing, but probably unavoidable. It would be nice if there was only one set of typecodes for all of Python, but I think we're stuck with many (array module typecores, struct module typecodes, array protocol typecodes). Cheers, -Scott

3 2

errors=31 in scipy.test() with latest cvs versions of scipy and Numerical
by Nils Wagner 05 Apr '05

05 Apr '05

Hi all, Using Numeric 24.0 >>> scipy.__version__ '0.3.3_303.4599' scipy.test() results in ====================================================================== ERROR: check_simple_todense (scipy.io.mmio.test_mmio.test_mmio_coordinate) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/io/tests/test_mmio.py", line 152, in check_simple_todense b = mmread(fn).todense() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 254, in todense csc = self.tocsc() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 1437, in tocsc return csc_matrix(a, (rowa, ptra), M=self.shape[0], N=self.shape[1]) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_add (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_elmul (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_getelement (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_matmat (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_matvec (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_setelement (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_tocoo (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_tocsc (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_tocsr (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_todense (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_constructor1 (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_constructor2 (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_constructor3 (scipy.sparse.Sparse.test_Sparse.test_csc) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_add (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_elmul (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_getelement (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_matmat (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_matvec (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_setelement (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_tocoo (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_tocsc (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_tocsr (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_todense (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_constructor1 (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_constructor2 (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_constructor3 (scipy.sparse.Sparse.test_Sparse.test_csr) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 30, in setUp self.datsp = self.spmatrix(self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 712, in __init__ ocsc = csc_matrix(transpose(s)) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_elmul (scipy.sparse.Sparse.test_Sparse.test_dok) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 60, in check_elmul c = a ** b File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 186, in __pow__ return csc ** other File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 485, in __pow__ return csc_matrix(c,(rowc,ptrc),M=M,N=N) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_matmat (scipy.sparse.Sparse.test_Sparse.test_dok) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 71, in check_matmat assert_array_almost_equal((asp*bsp).todense(),dot(asp.todense(),bsp.todense())) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 1184, in __mul__ return self.matmat(other) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 239, in matmat res = csc.matmat(other) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 568, in matmat return csc_matrix(c, (rowc, ptrc), M=M, N=N) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_tocoo (scipy.sparse.Sparse.test_Sparse.test_dok) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 75, in check_tocoo assert_array_almost_equal(a.todense(),self.dat) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 254, in todense csc = self.tocsc() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 1437, in tocsc return csc_matrix(a, (rowa, ptra), M=self.shape[0], N=self.shape[1]) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ====================================================================== ERROR: check_mult (scipy.sparse.Sparse.test_Sparse.test_dok) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/scipy/sparse/tests/test_Sparse.py", line 155, in check_mult D = A*A.T File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 1184, in __mul__ return self.matmat(other) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 239, in matmat res = csc.matmat(other) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 568, in matmat return csc_matrix(c, (rowc, ptrc), M=M, N=N) File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 357, in __init__ self._check() File "/usr/lib/python2.3/site-packages/scipy/sparse/Sparse.py", line 375, in _check if (nnz>0) and (max(self.rowind[:nnz]) >= M): IndexError: invalid slice ---------------------------------------------------------------------- Ran 1173 tests in 3.113s FAILED (errors=31) <unittest.TextTestRunner object at 0x40f6a1ac> >>>

2 1

Possible example application of the array interface
by Magnus Lie Hetland 05 Apr '05

05 Apr '05

I was just thinking about some experimental designs, and whether I could, perhaps, do the statistics in Python. I remembered having used RPy [1] briefly at some time (there may be other similar bindings out there -- I don't remember) and started thinking about whether I could, perhaps, combine it with numpy in some way. My first thought was to reimplement the relevant statistical functions; then I thought about how to convert data back and forth -- but then it occurred to me that R also uses arrays extensively, and that it could, perhaps, be possible to expose those (through something like RPy) through the array interface/protocol! This would be (IMO) a good example of the benefits of the array protocol; it's not a matter of "getting yet another array module". RPy is an external library/language with *lots* of features that might be useful to numpy users, many of which aren't likely to be implemented in Python for quite a while, I'd guess (unless, perhaps, someone writes a translator from R, which I'm sure is doable). I don't know enough (at least yet ;) about the implementation of RPy and the R library to say for sure whether this would even be possible, but it does seem like it could be really useful... [1] rpy.sf.net -- Magnus Lie Hetland Fall seven times, stand up eight http://hetland.org [Japanese proverb]

1 0

AttributeError: _NumErrorMode instance has no attribute 'dividebyzero'
by Werner F. Bruhin 05 Apr '05

05 Apr '05

If I use "Numeric.Error.setMode(all='Raise')" I get the above AttributeError. I found this on 1.1.1 but just downloaded "numarray-1.2.3.win32-py2.4.exe" and I still find the same problem. I use numarray with wx.lib.plot.py to generate some simple charts. I would like to catch the exceptions and display an appropriate message to the user. Is the above the right approach or am I going about this the wrong way round? Any hints are appreciated. Werner

1 0