Mailman 3 November 2001 - NumPy-Discussion

Heigenvalues is broken
by Alessandro Mirone Nov. 19, 2001

Nov. 19, 2001

Is it a problem of lapack3.0 of of LinearAlgebra.py? ..................... ==> (Eigenvalues should be (0,2)) >>> a=array([[1,0],[0,1]]) >>> b=array([[0,1],[-1,0]]) >>> M=a+b*complex(0,1.0) >>> Heigenvalues(M) array([-2.30277564, 1.30277564]) >>> print M [[ 1.+0.j 0.+1.j] [ 0.-1.j 1.+0.j]] >>>

5 4

Re: Numpy-discussion digest, Vol 1 #345 - 4 msgs
by Joe Harrington Nov. 19, 2001

Nov. 19, 2001

Just to fill in the blanks, here's what IDL does: IDL> a = [[1,2,3,4], $ IDL> [5,6,7,8], $ IDL> [9,10,11,12], $ IDL> [13,14,15,16]] IDL> print,a 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 IDL> print, a[[1,3],[0,3]] 2 16 --jh--

1 0

Re: [Numpy-discussion] Re-implementation of Python Numerical arrays (Numeric) available for download
by Perry Greenfield Nov. 17, 2001

Nov. 17, 2001

From: Pete Shinners <pete(a)shinners.org> > 7) necessary to add other types? > yes. i really want unsigned int16 and unsigned int32. all my operations > are on pixel data, and things can just get messy when i need to treat > packed color values as signed integers. > Unsigned int16 is already supported. UInt32 could be done, but raises some interesting issues with regard to combining with Int32. I don't believe the current implementation prevents you from carrying around unsigned data in Int32 arrays. If you are using them as packed color values, do you ever do any arithmetic operations on them other than to pack and unpack them? > one other thing i'd like there to be a little focus on is adding my own > new ufunc operators. for image manipulation i'd like new ufunc operators > that clamp the results to legal values. i'd be happy to do this myself, > but i don't believe it's possible with the current Numeric. > It will be possible for users to add their own ufuncs. We will eventually document how to do so (and it should be fairly simple to do once we give a few example templates). Perry >

1 0

RE: [Numpy-discussion] Re-implementation of Python Numerical arrays (Numeric) available for download
by Perry Greenfield Nov. 17, 2001

Nov. 17, 2001

> > I think that we also don't like that, and after doing the original, > > somewhat incomplete, implementation using the subarray approach, > > I began to feel that implementing it in C (albiet using a different > > approach for the code generation) was probably easier and more > > elegant than what was done here. So you are very likely to see > > it integrated as a regular numeric type, with a more C-based > > implementation. > > Sounds good. Is development going to take place on the CVS > tree. If so, I > could help out by comitting changes directly. > > > > > > 2) Also, in your C-API, you have a different pointer to the > > > imaginary data. > > > I much prefer the way it is done currently to have complex numbers > > > represented as an 8-byte, or 16-byte chunk of contiguous memory. > > > > Any reason not to allow both? (The pointer to the real can be > interpreted > > as either a pointer to 8-byte or 16-byte quantities). It is true > > that figuring out the imaginary pointer from the real is trivial > > so I suppose it really isn't necessary. > > I guess the way you've structured the ndarray, it is possible. I figured > some operations might be faster, but perhaps not if you have two pointers > running at the same time, anyway. > Well, the C implementation I was thinking of would only use one pointer. The API could supply both if some algorithms would find it useful to just access the imaginary data alone. But as mentioned, I don't think it is important to include, so we could easily get rid of it (and probably should) > > > > > Index Arrays: > > > =========== > > > > > > 1) For what it's worth, my initial reaction to your indexing > scheme is > > > negative. I would prefer that if > > > > > > a = [[1,2,3,4], > > > [5,6,7,8], > > > [9,10,11,12], > > > [13,14,15,16]] > > > > > > then > > > > > > a[[1,3],[0,3]] returns the sub-matrix: > > > > > > [[ 4, 6], > > > [ 12, 14] > > > > > > i.e. the cross-product of [1,3] x [0,3] This is the way MATLAB > > > works. I'm > > > not sure what IDL does. > > > > I'm afraid I don't understand the example. Could you elaborate > > a bit more how this is supposed to work? (Or is it possible > > there is an error? I would understand it if the result were > > [[5, 8],[13,16]] corresponding to the index pairs > > [[(1,0),(1,3)],[(3,0),(3,3)]]) > > > > The idea is to consider indexing with arrays of integers to be a > generalization of slice index notation. Simply interpret the > slice as an > array of integers that would be formed by using the range operator. > > For example, I would like to see > > a[1:5,1:3] be the same thing as a[[1,2,3,4],[1,2]] > > a[1:5,1:3] selects the 2-d subarray consisting of rows 1 to 4 and > columns 1 > to 2 (inclusive starting with the first row being row 0). In > other words, > the indices used to select the elements of a are ordered-pairs > taken from the > cross-product of the index set: > > [1,2,3,4] x [1,2] = [(1,1), (1,2), (2,1), (2,2), (3,1), (3,2), > (4,1), (4,2)] > and these selected elements are structured as a 2-d array of shape (4,2) > > Does this make more sense? Indexing would be a natural extension of this > behavior but allowing sets that can't be necessarily formed from > the range > function. > I understand this (but is the example in the first message consistent with this?). This is certainly a reasonable interpetation. But if this is the way multiple index arrays are interpreted, how does one easily specify scattered points in a multidimensional array? The only other alternative I can think of is to use some of the dimensions of a multidimensional index array as indicies for each of the dimensions. For example, if one wanted to index random points in a 2d array, then supplying an nx2 array would provide a list of n such points. But I see this as a more limiting way to do this (and there are often benefits to being able to keep the indices for different dimensions in separate arrays. But I think doing what you would like to do is straightforward even with the existing implementation. For example, if x is a 2d array we could easily develop a function such that: x[outer_index_product([1,3,4],[1,5])] # with a better function name! The function outer_index_product would return a tuple of two index arrays each with a shape of 3x2. These arrays would not take up more space than the original arrays even though they appear to have a much larger size (the one dimension is replicated by use of a 0 stride size so the data buffer is the same as the original). Would this be acceptable? In the end, all these indexing behaviors can be provided by different functions. So it isn't really a question of which one to have and which not to have. The question is what is supported by the indexing notation? For us, the behavior we have implemented is far more useful for our applications than the one you propose. But perhaps we are in the minority, so I'd be very interested in hearing which indexing interpretation is most useful to the general community. > > Why not: > > > > ravel(a)[[9,10,11]] ? > > sure, that would work, especially if ravel doesn't make a copy of > the data > (which I presume it does not). > Correct. Perry

1 0

FW: [Numpy-discussion] Re-implementation of Python Numerical arrays (Numeric) available for download
by Perry Greenfield Nov. 17, 2001

Nov. 17, 2001

-----Original Message----- > > What I've seen looks great. You've all done some good work here. > Thanks, you were origin of some of the ideas used. > Of course, I do have some feedback. I haven't looked at > everything, these > points have just caught my eye. > > Complex Types: > ============== > > 1) I don't like the idea of complex types being a separate subclass of > ndarray. This makes them "different." Unless this "difference" can be > completely hidden (which I doubt), I would prefer complex types > to be on the > same level as other numeric types. > I think that we also don't like that, and after doing the original, somewhat incomplete, implementation using the subclassed approach, I began to feel that implementing it in C (albeit using a different approach for the code generation) was probably easier and more elegant than what was done here. So you are very likely to see it integrated as a regular numeric type, with a more C-based implementation. > 2) Also, in your C-API, you have a different pointer to the > imaginary data. > I much prefer the way it is done currently to have complex numbers > represented as an 8-byte, or 16-byte chunk of contiguous memory. > Any reason not to allow both? (The pointer to the real can be interpreted as either a pointer to 8-byte or 16-byte quantities). It is true that figuring out the imaginary pointer from the real is trivial so I suppose it really isn't necessary. > > Index Arrays: > =========== > > 1) For what it's worth, my initial reaction to your indexing scheme is > negative. I would prefer that if > > a = [[1,2,3,4], > [5,6,7,8], > [9,10,11,12], > [13,14,15,16]] > > then > > a[[1,3],[0,3]] returns the sub-matrix: > > [[ 4, 6], > [ 12, 14] > > i.e. the cross-product of [1,3] x [0,3] This is the way MATLAB > works. I'm > not sure what IDL does. > I'm afraid I don't understand the example. Could you elaborate a bit more how this is supposed to work? (Or is it possible there is an error? I would understand it if the result were [[5, 8],[13,16]] corresponding to the index pairs [[(1,0),(1,3)],[(3,0),(3,3)]]) > If I understand your scheme, right now, then I would have to > append an extra > dimension to my indexing arrays to get this behavior, right? > > 2) I would like to be able to index the array in a flattenned > sense as well > (is that possible?) in other words, it would be nice if > a[flat(9,10,11)] or > something got me the elements 9,10,11 in a one-dimensional > interpretation of > the array. > Why not: ravel(a)[[9,10,11]] ? > 3) Why can't you combine slice notation and indexing? Just interpret the > slice as index array that would be created from using tha range > operator on > the same start, stop, and step objects. Is this the plan? > I think that allowing slicing could be possible. But things were getting pretty complex as they were, and we wanted to see if there was agreement on how it was being done so far. It could be extended to handle slices, if there was a well defined interpretation. (I think there may be at least two possible interpretations considered). As for the above, sure, but of course the slice would have to be shape consistent with the other index arrays (under the current scheme). > That's all for now. I don't mean to be critical, I'm really > impressed with > what works so far. These are just some concerns I have right now. > > -Travis Oliphant > Thanks Travis, we're looking for constructive feedback, positive or negative. Perry

1 0

Numeric Python EM Project may need mirror
by Rob Nov. 17, 2001

Nov. 17, 2001

Hi all, I just got an email from @home yesterday, saying that all customers should back up their web pages, email, etc etc. I know they are in bankruptcy, but this email sounded ominous. I'm wondering if there is some kindly soul who would want to mirror this site. I'd really love to have this site on Starship Python, but haven't had any responses to emails to them. I'm continuously working on more code for the site so I'd hate to see it go down, even if temporarily. Sincerely, Rob. -- The Numeric Python EM Project www.members.home.net/europax

1 0

Numpy, BLAS, LAPACK, f2py
by Nils Wagner Nov. 15, 2001

Nov. 15, 2001

Hi, I have installed f2py on my system for wrapping existing FORTRAN 77 codes to Python. Then I have gone through the following steps An example for using a TLS (total least squares routine) http://www.netlib.org/vanhuffel/ 2) Get dtsl.f with dependencies 3) Run f2py dtsl.f -m foo -h foo.pyf only: dtsl \ \ \ \________ just wrap dtsl function \ \ \______ create signature file \ \____ python module name \_____ Fortran 77 code 4) Edit foo.pyf to your specific needs (optional) 5) Run f2py foo.pyf \_____________ this will create Python C/API module foomodule.c 6) Run make -f Makefile-foo \_____________ this will build the module 7) In python: Python 2.1.1 (#1, Sep 24 2001, 05:28:47) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import foo Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: ./foomodule.so: undefined symbol: dcopy_ >>> Any suggestions to solve this problem ? Nils There are prebuilt libraries of LAPACK and BLAS in /usr/lib -rw-r--r-- 1 root root 657706 Sep 24 01:00 libblas.a lrwxrwxrwx 1 root root 12 Okt 22 19:27 libblas.so -> libblas.so.2 lrwxrwxrwx 1 root root 16 Okt 22 19:27 libblas.so.2 -> libblas.so.2.2.0 -rwxr-xr-x 1 root root 559600 Sep 24 01:01 libblas.so.2.2.0 -rw-r--r-- 1 root root 5763150 Sep 24 01:00 liblapack.a lrwxrwxrwx 1 root root 14 Okt 22 19:27 liblapack.so -> liblapack.so.3 lrwxrwxrwx 1 root root 18 Okt 22 19:27 liblapack.so.3 -> liblapack.so.3.0.0 -rwxr-xr-x 1 root root 4826626 Sep 24 01:01 liblapack.so.3.0.0

2 1

Total least squares problem
by Nils Wagner Nov. 14, 2001

Nov. 14, 2001

Hi, How do I solve a Total Least Squares problem in Numpy ? A small example would be appreciated. The TLS problem assumes an overdetermined set of linear equations AX = B, where both the data matrix A as well as the observation matrix B are inaccurate: Nils Reference: R.D.Fierro, G.H. Golub, P.C. Hansen, D.P.O'Leary, Regularization by truncated total least squares, SIAM J. Sci. Comput. Vol.18(4) 1997 pp. 1223-1241

3 4

Small Bug in multiarray.c
by barnard＠stat.harvard.edu Nov. 13, 2001

Nov. 13, 2001

When attempting to compile the CVS version of Numpy using MSVC 6 under Windows 2000 I found a small error in multiarray.c: the doc string for arange contains newlines. The offending code begins one line # 1168. Simple removing the newlines from the string fixes the error. John ******************************** * John Barnard, Ph.D. * Senior Research Statistician * deCODE genetics * 1000 Winter Str., Suite 3100 * Waltham, MA 02451 * Phone (Direct) : (781) 290-5771 Ext. 27 * Phone (General) : (781) 466-8833 * Fax : (781) 466-8686 * Email: j.barnard(a)decode.com ********************************

1 0

Building Numeric with Intel KML and mingw32
by Krishnaswami, Neel Nov. 12, 2001

Nov. 12, 2001

Hello, I'm trying to rebuild Numeric with the Intel Kernel Math Libraries. I've gotten Numeric building normally with the default BLAS libraries, but I'm not sure what I need to put into the libraries_dir_list and libraries_list variables in the setup.py file. I have the directories mkl\ia32\bin (contains the DLLs), mkl\ia32\lib (contains the lib*.a files), and mkl\include (contains the *.h files). Can anyone tells me what goes where? -- Neel Krishnaswami neelk(a)cswcasa.com

1 0