From acannon@geog.ubc.ca Thu Aug 1 22:36:05 1996 From: acannon@geog.ubc.ca (Alex Cannon) Date: Thu, 1 Aug 1996 14:36:05 -0700 (PDT) Subject: [PYTHON MATRIX-SIG] Gist plots with Tk? Message-ID: This may seem off-topic, but I couldn't decide whether this should go in matrix-sig (because of the gist tie in) or the GUI list (because of Tk). Anyhow, is it possible to get Tk and the gist module to coexist? As an example, I've modified the simple 'hello world' tkinter script to plot a line with gist. Running the script and clicking on the 'Plot' button causes the gist window to popup, but the plot doesn't finish until after quitting the Tk mainloop() (when running with -i). Is there a way to do this properly? Alex -- from Tkinter import * from gist import * class Test(Frame): def plot(self): plg([0, 1]) def createWidgets(self): self.QUIT = Button(self, {'text': 'Quit', 'fg': 'red', 'command': self.quit}) self.QUIT.pack({'side': 'left', 'fill': 'both'}) self.gist_test = Button(self, {'text': 'Plot', 'command': self.plot}) self.gist_test.pack({'side': 'left'}) def __init__(self, master=None): Frame.__init__(self, master) Pack.config(self) self.createWidgets() test = Test() test.mainloop() ------------------------------------------------------------ Alex Cannon (acannon@geog.ubc.ca) Geography 240C Atmospheric Science Programme Tel: (604) 822-2269 University of British Columbia, B.C. Fax: (604) 822-6150 ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From caves@yorvic.york.ac.uk Fri Aug 2 18:53:51 1996 From: caves@yorvic.york.ac.uk (Leo Caves) Date: Fri, 2 Aug 1996 18:53:51 +0100 Subject: [PYTHON MATRIX-SIG] "linking" variables to python Message-ID: <9608021853.ZM1030@pingu> Hi! context: extending python with a legacy FORTRAN app. and have used the PyArray_FromDimsAndData() function to link FORTRAN common block arrays to python array objects. is working beautifully... Q: how to do the same with scalar variables ? eg. INTEGER N in FORTRAN declaration to python object (say) n I am trying to avoid acessing as array of length 1. Also, I would like to ask what the current opinions on the perennial array indexing question are. i.e. indexed from 0 (in python) vs. 1 in FORTRAN. My point here is that I have a whole load of integer arrays in FORTRAN which serve as indices into other arrays. Therefore these would have to be remapped to point to the correct place in the python array. Thanks, Leo Caves ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jjh@goldilocks.lcs.mit.edu Fri Aug 9 23:21:09 1996 From: jjh@goldilocks.lcs.mit.edu (Jim Hugunin) Date: Fri, 9 Aug 1996 18:21:09 -0400 Subject: [PYTHON MATRIX-SIG] Release 1.0alpha1 now available Message-ID: <01BB861F.8A1BDA90@ling-ling.lcs.mit.edu> The first alpha release of the final 1.0 version of the Numeric = Extensions is now available. This release contains ZERO patches to the = python core. To use it you must have python1.4b2 installed on your = computer (much thanks to Guido for adding all of the needed = functionality to this release!). If you are working under Windows NT (or 95) there is a binary release = available that includes all needed files. The 1.0 number here means that I'm finally happy with the basic = functionality and design of the system and don't intend to make many = more changes. This version unfortunately changes many details from the = previous version and will break most existing code. I don't want to = ever do that again (not to you or to myself). There is an ugly, but = fairly complete piece of documentation in html for all of the functions = provided, as well as a very simple example module to help illustrate the = use of the C API. The alpha release means that this is not at all well tested. I'm = counting on you folks to track down the bugs now, and when that seems = under control, I'll send it out to the main list as a Beta release = (ideally coinciding with the first official release of python1.4). You = should expect a very rapid release schedule at this point as I = desperately want this out soon! Please beat hard on this and let me know where it breaks! For Unix users: Untar this wherever you want, and follow the instructions in INSTALL. Please try and build the dynamically loadable version, and let me know = about your success on different systems. I'd really like to include = binaries in the next alpha release (in preparation for the beta = release). ftp://ftp.sls.lcs.mit.edu/pub/jjh/NumPy-1.0a1.tar.gz There is also an fftmodule in this release. If you don't have fftpack = on your system, you can grab ftp://ftp.sls.lcs.mit.edu/pub/jjh/rfft-1.2.tar.gz=20 which is very easy to compile on almost all unix systems. This is = stolen from the rlab source code distribution site. For Windows 95/NT Unzip this into wherever you have your binary version of python = installed. This should be into a directory that already has a = py140-b1.dll in it. That will be replaced by the beta 2 version of that = library contained in the zip file. ftp://ftp.sls.lcs.mit.edu/pub/jjh/Win32-NumPy-1.0a1.zip Enjoy - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jjh@goldilocks.lcs.mit.edu Fri Aug 9 23:33:21 1996 From: jjh@goldilocks.lcs.mit.edu (Jim Hugunin) Date: Fri, 9 Aug 1996 18:33:21 -0400 Subject: [PYTHON MATRIX-SIG] Standard Numerical Library Message-ID: <01BB8621.3E6D8BF0@ling-ling.lcs.mit.edu> I'm getting tired of explaining to people why the Numeric Extensions = don't contain matrix inversion or fft operators. I intend to fix this = by providing a standard library with the 1.0 release of the system. The = primitive fftmodule in the current alpha1 release is my start on this. Here are my plans for this library, please comment: 1) Based on LAPACK and FFTPACK FORTRAN libraries, but only using the = subset available with the RLab distribution. This is a very nice = version of these libraries in C, and on every system I have available = they've compiled with "./configure; make" without a hitch (like some = scripting languages I know). They also seem to compile fairly easily = under NT. I'd distribute these packages as well for people without the = "real" libraries on their machines. 2) Implementing a bare minimum of functionality, in a simple, clean, = unsophisticated way. ie. fft( (0,0,1,1) ) will just work. No need to setup work areas, etc. 3) Implementing the "basic" functions 1D FFT Matrix Inversion Matrix Eigenvalues Matrix Determinant Any requests? I'm back - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Sat Aug 10 10:42:55 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 10 Aug 1996 12:42:55 +0300 Subject: [PYTHON MATRIX-SIG] Standard Numerical Library In-Reply-To: Jim Hugunin's message of Fri, 9 Aug 1996 18:33:21 -0400 References: <01BB8621.3E6D8BF0@ling-ling.lcs.mit.edu> Message-ID: Jim Hugunin writes: > 3) Implementing the "basic" functions > > 1D FFT > Matrix Inversion > Matrix Eigenvalues > Matrix Determinant > Any requests? SVD is a must. Pseudoinverse would be nice and trivial after SVD. Is there a function returning the index of a minimum or a maximum? This would be nice in some ANN applications, although I don't know whether it is generally useful enough to be a standard part of the language. -- Janne Sinkkonen ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Sat Aug 10 14:46:47 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Sat, 10 Aug 1996 15:46:47 +0200 Subject: [PYTHON MATRIX-SIG] Release 1.0alpha1 now available In-Reply-To: <01BB861F.8A1BDA90@ling-ling.lcs.mit.edu> (message from Jim Hugunin on Fri, 9 Aug 1996 18:21:09 -0400) Message-ID: <9608101346.AA03384@acds21> The first alpha release of the final 1.0 version of the Numeric = Extensions is now available. This release contains ZERO patches to the = Great news! That makes me eager to get back to work ;-) Unfortunately I won't have good enough net access until the end of next week (right now I have an awfully slow link at 7 cents a minute, but it works from my laptop...) Please beat hard on this and let me know where it breaks! Sounds like fun! I'm getting tired of explaining to people why the Numeric Extensions = don't contain matrix inversion or fft operators. I intend to fix this = by providing a standard library with the 1.0 release of the system. The = primitive fftmodule in the current alpha1 release is my start on this. Good idea. But we should make sure that this standard library is a subset of some "full" liraries, even if these will not be ready immediately. I don't want two incompatible matrix inversion functions! 1) Based on LAPACK and FFTPACK FORTRAN libraries, but only using the = subset available with the RLab distribution. This is a very nice = I don't know this subset. Is it fully compatible with the current versions of the full libraries? 2) Implementing a bare minimum of functionality, in a simple, clean, = unsophisticated way. ie. fft( (0,0,1,1) ) will just work. No need to setup work areas, etc. That should be the default for any numeric library! 3) Implementing the "basic" functions 1D FFT Matrix Inversion Matrix Eigenvalues Matrix Determinant I predict a lot of discussion about what is "basic". My only addition to your list would be solution of linear equations (inversion is a terribly inefficient way to do that). I would also like to have different algorithms where appropriate, a fast one for standard problems and a foolproof one for people who don't know what they are doing (i.e. SVD for matrix inversion etc.) As soon as I am back in business, I will update my LAPACK interface for the new version. I don't pretend that it is the last word on linear algebra libraries (some problems, like application to different types of matrices (symmetric etc.) have been completely ignored until now), but it has worked quite well for me in the past, and I have a couple of application algorithms that use it. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Sat Aug 10 19:15:35 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Sat, 10 Aug 1996 19:15:35 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Standard Numerical Library In-Reply-To: Message-ID: On 10 Aug 1996, Janne Sinkkonen wrote: > Is there a function returning the index of a minimum or a > maximum? This would be nice in some ANN applications, although I don't > know whether it is generally useful enough to be a standard part of > the language. > I find functions like max(), min(), and sort() (fun() for short) more limited than the corresponding argfun(), simply because the former could always be writen as take(a,argfun(a)). Unfortunately, the indices argument of take() used to have to be one-dimensional, so the above would not work for a two dimensional array. Has this changed in the new release? A version of take() such that: take(a,argsort(a,axis),axis) = sort(a,axis) for arrays of arbitrary shape would be very, very useful. Ideally, it should also follow the same rules as +, *, etc when "a" or "indices" have dimensions of length one. Even if implementing this functionality is not a priority at this stage, making axis in take() default to -1 would allow for it to be implemented later without breaking any code in the future. I guess I should try to write a new version of take() in Python first, and then see if others could use this functionality. Carlos Fonseca ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Carlos Fonseca Sat Aug 10 18:46:51 1996 From: Carlos Fonseca (Carlos Fonseca) Date: Sat, 10 Aug 1996 18:46:51 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Standard Numerical Library In-Reply-To: <01BB8621.3E6D8BF0@ling-ling.lcs.mit.edu> Message-ID: On Fri, 9 Aug 1996, Jim Hugunin wrote: > Here are my plans for this library, please comment: > > 1) Based on LAPACK and FFTPACK FORTRAN libraries, but only using the > subset available with the RLab distribution. This is a very nice > version of these libraries in C ... > ... I'd distribute these packages as well for people without the > "real" libraries on their machines. Would it still be possible to use the "real" libraries? It would be nice to link dynamically with these... > 2) Implementing a bare minimum of functionality, in a simple, clean, > unsophisticated way. > > ie. fft( (0,0,1,1) ) will just work. No need to setup work areas, etc. Will 1D functions like the fft (and also 2D functions) work transparently on arbitrary multidimensional arrays, along user-specified axes? This should be easier to implement efficiently in C than later in Python. In genetic algorithms it is almost always necessary to evaluate cost functions at a number of points at a time, which adds one dimension to array containing the decision variables. In control engineering, these could easily be matrices. Sometimes, the population is structured, which adds another dimension. Having multidimensional arrays is a great way of eliminating for-loops in the Python code and/or unnecessary reshaping of the arrays prior to the computation. This also raises the question of which axis/axes these functions should use by default. I find it counter-intuitive that most functions (but not all!) default to axis=0 whereas addition, multiplication, etc., match the last dimensions of arrays of different depths. Personally, I would prefer axis=-1 by default (but there may be a reason against this), or axis=(-2,-1) for 2D functions (matrix inversion, etc). > 3) Implementing the "basic" functions > > 1D FFT > Matrix Inversion > Matrix Eigenvalues ... and corresponding eigenvectors. I've seen at least one numerical package which did not return them :-( > Matrix Determinant > Any requests? * SVD (already mentioned) * (Generalised) Cholesky decomposition of symmetric matrices would be very useful to anybody dealing with covariance matrices (and I believe it is in LINPACK, don't know about LAPACK). * Least-squares solution of over/under-determined systems of linear equations a la A\b in Matlab. I hope the above comments are useful... I am looking forward to trying out the new release. Thanks! Carlos Fonseca ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Sat Aug 10 22:41:01 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Aug 1996 00:41:01 +0300 Subject: [PYTHON MATRIX-SIG] Standard Numerical Library In-Reply-To: Carlos Fonseca's message of Sat, 10 Aug 1996 19:15:35 +0100 (BST) References: Message-ID: Carlos Fonseca writes: > I find functions like max(), min(), and sort() (fun() for short) more > limited than the corresponding argfun(), simply because the former could > always be writen as take(a,argfun(a)). I agree... it is complex to compute the index from the value, the other way it's much easier. argsort() solves my problem, at least less suboptimally than some other hacks. In 1.0 alpha1 there seems to be some kind of type conversion missing from argsort(), however: >>> argsort([5,4,2,3]) 2 3 1 0 >>> argsort([5.0,4,2,3]) 6.36598737e-314 4.94065646e-324 0.00000000e+000 0.00000000e+000 -- Janne ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Sun Aug 11 13:54:23 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Sun, 11 Aug 1996 14:54:23 +0200 Subject: [PYTHON MATRIX-SIG] Standard Numerical Library In-Reply-To: (message from Carlos Fonseca on Sat, 10 Aug 1996 18:46:51 +0100 (BST)) Message-ID: <9608111254.AA03871@acds21> Will 1D functions like the fft (and also 2D functions) work transparently on arbitrary multidimensional arrays, along user-specified axes? This should be easier to implement efficiently in C than later in Python. That reminds me of the long discussion about function ranks a few months ago. Basically, all functions that act on an array of fixed rank (1 for 1D FFT, 2 for matrix inversion, etc.) should loop over the remainining indices of higher-rank arrays. This approach has proven to be very useful in J. This also raises the question of which axis/axes these functions should use by default. I find it counter-intuitive that most functions (but not all!) default to axis=0 whereas addition, multiplication, etc., match the last dimensions of arrays of different depths. Personally, I would prefer axis=-1 by default (but there may be a reason against this), or axis=(-2,-1) for 2D functions (matrix inversion, etc). Again the J-style rank approach provides a single rule for sorting out such things in a very nice way... * (Generalised) Cholesky decomposition of symmetric matrices would be very useful to anybody dealing with covariance matrices (and I believe it is in LINPACK, don't know about LAPACK). It's also in LAPACK (everything that is in LINPACK is also in LAPACK, which was designed as a replacement for LINPACK and EISPACK). * Least-squares solution of over/under-determined systems of linear equations a la A\b in Matlab. I agree that all teh features you mentiones are essential for serious linear algebra work, but I am not sure if they are essential for a *minimal* standard library. I need pseudoinverses almost daily, but I also know that many people have never heard of them... Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Sun Aug 11 16:09:23 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Aug 1996 18:09:23 +0300 Subject: [PYTHON MATRIX-SIG] Bugs in 1.0alpha1 In-Reply-To: Jim Hugunin's message of Fri, 9 Aug 1996 18:21:09 -0400 References: <01BB861F.8A1BDA90@ling-ling.lcs.mit.edu> Message-ID: I think the following may be bugs: arange(5,3,2) produces a core dump. This seems to come down to (for example) zeros((-5,)) producing a core dump. minimum.reduceAt() produces a core dump. array() doesn't take a copy. Should it? (doc.html says it should) >>> a=array([1,2,3,4,5]) >>> b=array(a) >>> a[0]=0 >>> b 0 2 3 4 5 diagonal() gives odd results: >>> d 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 >>> diagonal(d) 1 2 3 4 5 sort() and argsort() do not accept two arguments. -- Janne ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Sun Aug 11 16:10:58 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Aug 1996 18:10:58 +0300 Subject: [PYTHON MATRIX-SIG] Ranf.py for 1.0alpha1 Message-ID: ... after one or two trivial fixes: import URNG import Numeric # x=CreateGenerator(seed) creates an random number generator stream # seed < 0 ==> Use the default initial seed value. # seed = 0 ==> Set a "random" value for the seed from the system clock. # seed > 0 ==> Set seed directly (32 bits only). # x.ranf() samples from that stream. # x.sample(n) returns a vector from that stream. # # ranf() returns a stream of random numbers # random_sample(n) returns a vector of length n filled with random numbers # random_matrix(n,m,...) returns an arbitrarily shaped matrix filled with # random numbers. CreateGenerator = URNG.CreateGenerator standard_generator = CreateGenerator(-1) def ranf(): "ranf() = a random number from the standard generator." return standard_generator.ranf() def random_sample(*n): """random_sample(n) = array of n random numbers; random_sample(n1, n2, ...)= random array of shape (n1, n2, ..)""" if not n: return standard_generator.sample(1) m = 1 for i in n: m = m * i return Numeric.reshape(standard_generator.sample(m), n) -- Janne Sinkkonen ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Sun Aug 11 16:20:28 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Aug 1996 18:20:28 +0300 Subject: [PYTHON MATRIX-SIG] MLab.py for 1.0alpha1 In-Reply-To: Jim Hugunin's message of Fri, 9 Aug 1996 18:21:09 -0400 References: <01BB861F.8A1BDA90@ling-ling.lcs.mit.edu> Message-ID: Here is a (hopefully mostly) working MLab.py for 1.0beta1. I have tried to test it with 1D and 2D arrays, but not with higher dimensional arrays. max() and min() are changed to mmax() and mmin() because of name collision with the builtin functions (are mmax() and mmin() really needed?) diag() could be more effective, but I left it as it is because the diagonal() of Numeric.py does not seem to work right now. """Matlab(tm) compatibility functions. This will hopefully become a complete set of the basic functions available in matlab. The syntax is kept as close to the matlab syntax as possible. One fundamental change is that the first index in matlab varies the fastest (as in FORTRAN). That means that it will usually perform reductions over columns, whereas with this object the most natural reductions are over rows. It's perfectly possible to make this work the way it does in matlab if that's desired. """ # ChangeLog: # Sun Aug 11 18:12:20 EET DST 1996: # Hacked for 1.0alpha1 by from Numeric import * # Elementary Matrices # zeros is from matrixmodule in C # ones is from Numeric.py ## This should be replaced by Paul Dubois' URNG very soon now. import Ranf def rand(*args): """rand(d1,...,dn, typecode='d') returns a matrix of the given dimensions which is initialized to random number in the range [0,1). """ return Ranf.random_sample(args) def eye(N, M=None, k=0, typecode=None): """eye(N, M=N, k=0, typecode=None) returns a N-by-M matrix where the k-th diagonal is all ones, and everything else is zeros. """ if M == None: M = N if type(M) == type('d'): typecode = M M = N m = equal(subtract.outer(arange(N), arange(M)),-k) if (typecode == None): return m else: return m.asType(typecode) def tri(N, M=None, k=0, typecode=None): if M == None: M = N if type(M) == type('d'): typecode = M M = N m = greaterEqual(subtract.outer(arange(N), arange(M)),-k) if (typecode == None): return m else: return m.asType(typecode) # Matrix manipulation def diag(v, k=0): s = v.shape if len(s)==1: n = s[0]+abs(k) if k > 0: v = concatenate((zeros((k,)),v)) elif k < 0: v = concatenate((v,zeros((-k,)))) return multiply(eye(n, k=k), v) elif len(s)==2: v = add.reduce(eye(s[0], s[1], k=k)*v) i0=max(0,k) i1=min(k+s[0],s[1]) if i0>i1: return array([]) else: return v[i0:i1] def fliplr(m): return m[:, ::-1] def flipud(m): return m[::-1] # reshape(x, m, n) is not used, instead use reshape(x, (m, n)) def rot90(m, k=1): k = k % 4 if k == 0: return m elif k == 1: return fliplr(transpose(m)) elif k == 2: return fliplr(flipud(m)) elif k == 3: return transpose(fliplr(m)) def tril(m, k=0): return tri(m.shape[0], m.shape[1], k=k, typecode=m.typecode())*m def triu(m, k=0): return (1-tri(m.shape[0], m.shape[1], k-1, m.typecode()))*m # Data analysis # Basic operations def mmax(m): return maximum.reduce(m) def mmin(m): return minimum.reduce(m) # Actually from BASIS, but it fits in so naturally here... def ptp(m): return max(m)-min(m) def mean(m): return add.reduce(m)/len(m) # sort is done in C but is done row-wise rather than column-wise def msort(m): return transpose(sort(transpose(m))) def median(m): return msort(m)[m.shape[0]/2] def std(m): mu = mean(m) return sqrt(add.reduce(pow(m-mu,2)))/sqrt(len(m)-1) def sum(m): return add.reduce(m) def cumsum(m): return add.accumulate(m) def prod(m): return multiply.reduce(m) def cumprod(m): return multiply.accumulate(m) def trapz(y, x=None): """Integrate f using the trapezoidal rule, where y is f(x). """ if x == None: d = 1 else: d = diff(x) return sum(d * (y[1:]+y[0:-1])/2) def diff(x, n=1): """Discrete difference approximation to the derivative """ if n > 1: return diff(x[1:]-x[:-1], n-1) else: return x[1:]-x[:-1] def corrcoef(x, y=None): """The correlation coefficients """ if y==None: y=x c = cov(x, y) return c/sqrt(multiply.outer(diag(cov(x)),diag(cov(y)))) def cov(a,b=None): if b == None: b=a ma = mean(a) mb = mean(b) sum_cov = 0.0 for ai,bi in map(lambda i,j: (i,j), a,b): sum_cov = sum_cov+multiply.outer(ai,bi) return (sum_cov-len(a)*multiply.outer(ma,mb))/(len(a)-1) ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jjh@goldilocks.lcs.mit.edu Sun Aug 11 18:16:05 1996 From: jjh@goldilocks.lcs.mit.edu (Jim Hugunin) Date: Sun, 11 Aug 1996 13:16:05 -0400 Subject: [PYTHON MATRIX-SIG] Default axis Message-ID: <01BB8787.412159A0@ling-ling.lcs.mit.edu> Several people how now brought up the issue of the default axis in the = various functions in NumPy. The inconsistency of this definition is = really a problem. I think that it's really important to have a = consistent default axis, and I propose that the default axis be made -1 = (or -2 for things that expect 2d arrays). This works fairly well for me = in almost all cases (even though this is the opposite of the current = behavior for things like add.reduce). On machines with certain cache = architectures (and with contiguous arrays) this even makes sense as the = most computationally efficient choice. My only problem with this is the concatenation function which I = personally think should only be implemented along axis 0, though I've = been convinced this is too limiting. Having this default to a different = axis than 0 really bothers me, but I suppose I'll get over it. Comments are welcome - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jjh@goldilocks.lcs.mit.edu Sun Aug 11 19:57:57 1996 From: jjh@goldilocks.lcs.mit.edu (Jim Hugunin) Date: Sun, 11 Aug 1996 14:57:57 -0400 Subject: [PYTHON MATRIX-SIG] Win32 Distribution is Broken Message-ID: <01BB8795.7C7B41B0@ling-ling.lcs.mit.edu> I just tried to install the Win32 binary distribution on my home = machine, and its definately broken. I'm removing the zip file from my = ftp site for now. I need to learn a little bit more about PythonWin and Setup programs = under Win32 in order to do this right. Hope for a working distribution = in alpha2. Note: The two basic problems are 8.3 filenames and properly updating = pythonwin to 1.4b2 from 1.4b1. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Sun Aug 11 21:59:32 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Aug 1996 23:59:32 +0300 Subject: [PYTHON MATRIX-SIG] Release 1.0alpha1 now available In-Reply-To: Konrad Hinsen's message of Sat, 10 Aug 1996 15:46:47 +0200 References: <9608101346.AA03384@acds21> Message-ID: Konrad Hinsen writes: > As soon as I am back in business, I will update my LAPACK interface > for the new version. I don't pretend that it is the last word on > linear algebra libraries (some problems, like application to different > types of matrices (symmetric etc.) have been completely ignored > until now), but it has worked quite well for me in the past, and I have > a couple of application algorithms that use it. Well, I need your LAPACK interface right now... see below. :) By the way, dot(a,b) of the package Numeric now seems to reduce over the same axis for both a and b. While this seems sensible and efficient, especially if the axis is -1, the behaviour looks strange for a newcomer who maybe expects to find a matrix multiplication function. Should there be a function behaving like the ordinary matrix multiplication for 2D arrays, say dot2(), so that dot(a,b) would be equal to dot2(a,transpose(b)) (for 2D arrays)? On the other hand, this kind of behaviour does not mean anything sensible for N-dimensional arrays, or does it? # This module contains high-level Python interfaces to the # LAPACK library. # # Written by Konrad Hinsen # last revision: 1996-3-13 # # Modified 1996-3-19 by Doug Heisterkamp # Change type of pivots from "i" to "l" in solveLinearEquations # # Modified 1996-8-11 by Janne Sinkkonen # Made compatible with NumPy 1.0alpha1. A bug in eigenvalues() # (triggered by complex arguments) corrected. dot() is now # _dot2() and unitMatrix() is _unitMatrix(). # import Numeric,umath import Numeric import copy transpose=Numeric.transpose zeros=Numeric.zeros cp=copy.copy # Error object LinAlgError = 'LinAlgError' # Helper routines _lapack_type = {'f': 0, 'd': 1, 'F': 2, 'D': 3} _lapack_letter = ['s', 'd', 'c', 'z'] _array_kind = {'i':0, 'l': 0, 'f': 0, 'd': 0, 'F': 1, 'D': 1} _array_precision = {'i': 1, 'l': 1, 'f': 0, 'd': 1, 'F': 0, 'D': 1} _array_type = [['f', 'd'], ['F', 'D']] def _commonType(*arrays): kind = 0 precision = 0 for a in arrays: t = a.typecode() kind = max(kind, _array_kind[t]) precision = max(precision, _array_precision[t]) return _array_type[kind][precision] def _castCopyAndTranspose(type, *arrays): cast_arrays = () for a in arrays: if a.typecode() == type: cast_arrays = cast_arrays + (cp(transpose(a)),) else: cast_arrays = cast_arrays + (transpose(a).asType(type),) if len(cast_arrays) == 1: return cast_arrays[0] else: return cast_arrays def _findLapackRoutine(name, type): name = _lapack_letter[_lapack_type[type]] + name module = 'lapack_' + name[:3] exec 'import ' + module module = eval(module) return getattr(module, name) def _assertRank2(*arrays): for a in arrays: if len(a.shape) != 2: raise LinAlgError, 'Array must be two-dimensional' def _assertSquareness(*arrays): for a in arrays: if max(a.shape) != min(a.shape): raise LinAlgError, 'Array must be square' # unit matrix def _unitMatrix(n): i = Numeric.arange(n) return Numeric.equal(i[:,Numeric.NewAxis], i) # A dot function behaving like matrix multiplication (for 2D arrays) def _dot2(a1, a2): return(Numeric.dot(a1,transpose(a2))) # Singular value decomposition def singularValueDecomposition(a): _assertRank2(a) n = a.shape[1] m = a.shape[0] t =_commonType(a) real_t = _array_type[0][_array_precision[t]] lapack_routine = _findLapackRoutine('gesvd', t) a = _castCopyAndTranspose(t, a) s = zeros((min(n,m),), real_t) u = zeros((m,m,), t) vt =zeros((n,n,), t) lwork = 10*max(m,n) # minimum value: max(3*min(m,n)+max(m,n),5*min(m,n)-4) work = zeros((lwork,), t) if _array_kind[t] == 1: # Complex routines take different arguments rwork = zeros((max(3*min(m,n),5*min(m,n)-4),), real_t) results = lapack_routine('A', 'A', m, n, a, m, s, u, m, vt, n, work, lwork, rwork, 0) else: results = lapack_routine('A', 'A', m, n, a, m, s, u, m, vt, n, work, lwork, 0) if results['info'] > 0: raise LinAlgError, 'SVD did not converge' return cp(transpose(u)), s, cp(transpose(vt)) # Generalized inverse def generalizedInverse(a): u, s, vt = singularValueDecomposition(a) m = u.shape[0] n = vt.shape[0] cutoff = 1.e-10*Numeric.maximum.reduce(s) sm = zeros((n,m,),s.typecode()) for i in range(min(n,m)): if s[i] > cutoff: sm[i,i] = 1./s[i] return _dot2(_dot2(transpose(vt), sm), transpose(u)) # Linear equations def solveLinearEquations(a, b): one_eq = len(b.shape) == 1 if one_eq: b = b[:, Numeric.NewAxis] _assertRank2(a, b) _assertSquareness(a) n_eq = a.shape[0] n_rhs = b.shape[1] if n_eq != b.shape[0]: raise LinAlgError, 'Incompatible dimensions' t =_commonType(a, b) lapack_routine = _findLapackRoutine('gesv', t) a, b = _castCopyAndTranspose(t, a, b) pivots = zeros((n_eq,), 'l') results = lapack_routine(n_eq, n_rhs, a, n_eq, pivots, b, n_eq, 0) if results['info'] > 0: raise LinAlgError, 'Singular matrix' if one_eq: return cp(Numeric.ravel(b)) else: return cp(transpose(b)) # Matrix inversion def inverse(a): return solveLinearEquations(a, _unitMatrix(a.shape[0])) # Eigenvalues def eigenvalues(a): _assertRank2(a) _assertSquareness(a) t =_commonType(a) real_t = _array_type[0][_array_precision[t]] lapack_routine = _findLapackRoutine('geev', t) a = _castCopyAndTranspose(t, a) n = a.shape[0] dummy = Numeric.zeros((1,), t) lwork = max(1,6*n) # minimum value: max(1,3*n) real, max(1,2*n) complex work = Numeric.zeros((lwork,), t) if _array_kind[t] == 1: # Complex routines take different arguments w = Numeric.zeros((n,), t) rwork = Numeric.zeros((n,),real_t) results = lapack_routine('N', 'N', n, a, n, w, dummy, 1, dummy, 1, work, lwork, rwork, 0) else: wr = Numeric.zeros((n,), t) wi = Numeric.zeros((n,), t) results = lapack_routine('N', 'N', n, a, n, wr, wi, dummy, 1, dummy, 1, work, lwork, 0) if Numeric.logicalAnd.reduce(Numeric.equal(wi, 0.)): w = wr else: w = wr+1j*wi if results['info'] > 0: raise LinAlgError, 'Eigenvalues did not converge' return w ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From da@maigret.cog.brown.edu Sun Aug 11 22:09:53 1996 From: da@maigret.cog.brown.edu (David Ascher) Date: Sun, 11 Aug 1996 17:09:53 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] fromFunction... Message-ID: <199608112109.RAA11928@maigret> In 1.0a1, fromFunction is absent. I miss it. =) Now, the last we talked about this, there were still some issues that had to be hacked out, and Konrad pseudo-volunteered, but since then he took a vacation, a job, moved, and is now somewhat netisolated. Does anyone else feel up to the task? Or Konrad, are you still interested/able? My requirements are fairly simple. I want to do things like def f(x, y): return sin(x) + cos(y) # (1) a = fromFunction((200,200), f) as efficiently as possible. Maybe there are much better ways than what I just wrote, but it sure was simple. If someone can show me how to do the above without fromFunction, that'd be nice too. I do think that the general notion is very useful, and I'd like to see it survive. One problem with the 0.36 version of fromFunction is that def f(x,y): return x # (2) a = fromFunction((200,200), f) returns something which is of shape (200,1), not (200,200), which is what I'd expected. Surprisingly (to the naive user at least), def f(x,y): return x + 0*y # (3) a = fromFunction((200,200), f) returns just what I expected (2) would above. Cheers -david ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Carlos Fonseca Sun Aug 11 22:59:53 1996 From: Carlos Fonseca (Carlos Fonseca) Date: Sun, 11 Aug 1996 22:59:53 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Bugs in 1.0alpha1 In-Reply-To: Message-ID: On 11 Aug 1996, Janne Sinkkonen wrote: > I think the following may be bugs: > > arange(5,3,2) produces a core dump. This seems to come down to (for > example) zeros((-5,)) producing a core dump. In addition to this: >>> a=arange(0) >>> a -1 >>> a.shape Traceback (innermost last): File "", line 1, in ? AttributeError: attribute-less object Version 0.36 produced some sort of empty array here. Actually, this raises the question of the dimensions of empty arrays: >>> b 0 1 2 3 4 5 6 7 8 9 >>> b[1:1] EmptyArray >>> b[1:1,:] Traceback (innermost last): File "", line 1, in ? IndexError: invalid slice The Octave documentation mentions a paper (something like "An empty exercise", sorry, I don't have it with me at the moment) where empty arrays are discussed. Also, Octave follows this paper in how it handles empty arrays. I haven't run into difficulties with this, but expressions like b[1:1,:] and b[2:1,:] should work. > array() doesn't take a copy. Should it? (doc.html says it should) > >>> a=array([1,2,3,4,5]) > >>> b=array(a) > >>> a[0]=0 > >>> b > 0 2 3 4 5 I had wondered about this, too. It also happens with b=ravel(a), if a is 1d, and may happen with other funtions, too. This may save space and time in some special cases, but it certainly isn't safe... At least, it should be spelled out loud in the final docs. Another possibility is an optional argument (something like b=ravel(a,alwayscopy=0/1)), but I don't know whether I like this or not. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jbaddor@phy.ulaval.ca Mon Aug 12 13:40:00 1996 From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR) Date: Mon, 12 Aug 1996 08:40:00 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] histogram Message-ID: Hi ! Does something already exit to calculate the histogram of a big array ? Thanks for information. Jean-Bernard ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jbaddor@phy.ulaval.ca Mon Aug 12 13:55:18 1996 From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR) Date: Mon, 12 Aug 1996 08:55:18 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] Standard Numerical Library In-Reply-To: <01BB8621.3E6D8BF0@ling-ling.lcs.mit.edu> Message-ID: On Fri, 9 Aug 1996, Jim Hugunin wrote: (...) > 3) Implementing the "basic" functions > > 1D FFT Would it be possible to have 2D FFT (for images analysis) ? > Matrix Inversion > Matrix Eigenvalues > Matrix Determinant > Any requests? > > I'm back - Jim > > ========MATRIX-SIG - SIG on Matrix Math for Python > > send messages to: matrix-sig@python.org > administrivia to: matrix-sig-request@python.org > ======== ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@oasis.unl.edu Mon Aug 12 16:09:46 1996 From: drh@oasis.unl.edu (Doug Heisterkamp) Date: Mon, 12 Aug 1996 10:09:46 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] Standard Numerical Library In-Reply-To: <01BB8621.3E6D8BF0@ling-ling.lcs.mit.edu> from "Jim Hugunin" at Aug 9, 96 06:33:21 pm Message-ID: <199608121509.KAA02824@oasis.unl.edu> > > 1D FFT and 2D FFT > Matrix Inversion > Matrix Eigenvalues and Eigenvectors > Matrix Determinant > Any requests? > SVD, solving systems of linear equations, least squares. Doug Heisterkamp drh@oasis.unl.edu ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Mon Aug 12 18:24:28 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Mon, 12 Aug 1996 13:24:28 -0400 Subject: [PYTHON MATRIX-SIG] Histogram? Message-ID: <320F68CC.6E95@mit.edu> This is not quite optimal (O(N lg N) instead of O(N)), but it is adequate for my needs: def histogram(a, bins): """Calculates the histogram of the values in the 1d array a. bins is an array of the edges of the bins, there is one less bin than items in this array. Items that lie exactly on a bin edge have a 50/50 chance of appearing in either bin.""" n = binarysearch(sort(a), bins) n = concatenate( [n, [len(a)]] ) return n[1:]-n[:-1] Something like this will wind up in the standard library. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Mon Aug 12 18:19:34 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Mon, 12 Aug 1996 13:19:34 -0400 Subject: [PYTHON MATRIX-SIG] Bugs in 1.0alpha1 References: Message-ID: <320F67A6.7CAA@mit.edu> Carlos Fonseca wrote: > > On 11 Aug 1996, Janne Sinkkonen wrote: > > > I think the following may be bugs: I appreciate the desire to be kind, but any time you can produce a core dump with NumPy, you're entitled to say, I found the following TERRIBLE BUG! Though I'd prefer it if you sent these really obvious bugs straight to me... > > arange(5,3,2) produces a core dump. This seems to come down to (for > > example) zeros((-5,)) producing a core dump. > ... > Version 0.36 produced some sort of empty array here. Actually, this > raises the question of the dimensions of empty arrays: ... > empty arrays. I haven't run into difficulties with this, but expressions > like b[1:1,:] and b[2:1,:] should work. Empty arrays are now much cleaned up. The reported bugs have been fixed for alpha2 (sometime this week). Note however, b[2:1, :] will not work on an array of shape (2,3). The reason this doesn't work should be pretty clear. For fun with empty arrays, try: sum([[],[],[]], -1) > > array() doesn't take a copy. Should it? (doc.html says it should) It should and it does in alpha2. > I had wondered about this, too. It also happens with b=ravel(a), if a is > 1d, and may happen with other funtions, too. This may save space and time > in some special cases, but it certainly isn't safe... At least, it should > be spelled out loud in the final docs. Another possibility is an optional > argument (something like b=ravel(a,alwayscopy=0/1)), but I don't know > whether I like this or not. I really don't like the idea of that optional argument, whether or not these functions: reshape, ravel, and transpose should always return a copy of their input array is a good question. I'll think about this, and will definately put a note in the docs if I decide to leave their behavior unchanged. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Mon Aug 12 19:58:15 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Mon, 12 Aug 1996 20:58:15 +0200 Subject: [PYTHON MATRIX-SIG] histogram In-Reply-To: (message from Jean-Bernard ADDOR on Mon, 12 Aug 1996 08:40:00 -0400 (EDT)) Message-ID: <9608121858.AA06035@acds21> Does something already exit to calculate the histogram of a big array ? I have something like that as part of my WHAM package (which is a rather specialized package for the evaluation of PMFs ; and if you don't know what that is you don't need to know :-) Works fine. I'll see if I can extract some general histogram code, but don't expect anything this week... Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Mon Aug 12 20:18:07 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Mon, 12 Aug 1996 21:18:07 +0200 Subject: [PYTHON MATRIX-SIG] First impressions from the docs Message-ID: <9608121918.AA06110@acds21> I couldn't resist downloading the new Numerical Python packageeven though I don't have the Python 1.4 source code yet. So I'lljust comment on what I read in the documentation for now: In general, the current function set is a big step forward. I expectthat I can now replace most awkward constructions in my applicationcode by something more concise and more efficient. More on that whenI am finished... I would like to see more flexibility in the constructor if it iscalled with a non-sequence first argument. It should try to dosomething meaningful whenever possible. If presented with a file,for example, it should assume a text file with numbers and doits best to turn it into an array (this is very important forreading data produced by other programs). And for argumentsthat have no type/class with special meaning, it should calla method toArray() if it exists.I do realize that reading from a file intelligently is a non-trivialproblem, and therefore the best solution is probably to provide afunction hook similar to the one for array printing. Thatgives everyone ample opportunity to play with array reading code.I have a function (in Python) that reads 1D and 2D arrays wellenough for me, but it is not very efficient. That could be astarting point for a more sophisticated version. I wonder what exactly resize() does. First, I don't understand whyit is less efficient than reshape(); if the size remains the same, itshould perform exactly the same operation. But I really wonder what"strange" things can happen if I am not "careful". As long as theshape argument makes sense (i.e. contains no negative numbers) theresult should be well defined. The function diagonal() is a typical example of a function thatwould benefit from J-style function ranks. As it is defined now,it assumes that higher-rank arrays are to be treated as arraysof 2D subarrays (i.e. function rank 2). This is a useful function,but a "true" higher-rank diagonal (the list of elements for whichall indices are equal), corresponding to function rank infinity,is also useful. The same applies to trace(). The axis defaults for sort() and argsort() should be 0. There are two methods that I would like to see as functions: shape()and asType(). Both occur commonly in numerical algorithms, wheretheir argument might be a rank-0 array (i.e. a scalar).(Alternatively the two methods could be added to the Pythonscalar types, but I am not sure if Guido would approve such achange.) I still think that in the general spirit of Python, the defaultmath module used by Numeric should be umath, not fast_umath.For someone who doesn't know all the details, it is betterto be slow than to be wrong. More when I have the code running... Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jbaddor@phy.ulaval.ca Mon Aug 12 19:51:59 1996 From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR) Date: Mon, 12 Aug 1996 14:51:59 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] Histogram? In-Reply-To: <320F68CC.6E95@mit.edu> Message-ID: Thanks for your help. Are binarysearch and concatenate in the new matrix module 1.0alpha1 ? Jean-Bernard On Mon, 12 Aug 1996, Jim Hugunin wrote: > This is not quite optimal (O(N lg N) instead of O(N)), but it is > adequate for my needs: > > def histogram(a, bins): > """Calculates the histogram of the values in the 1d array a. > bins is an array of the edges of the bins, there is one less > bin than items in this array. Items that lie exactly on a bin > edge have a 50/50 chance of appearing in either bin.""" > n = binarysearch(sort(a), bins) > n = concatenate( [n, [len(a)]] ) > return n[1:]-n[:-1] > > Something like this will wind up in the standard library. > > -Jim > > ================= > MATRIX-SIG - SIG on Matrix Math for Python > > send messages to: matrix-sig@python.org > administrivia to: matrix-sig-request@python.org > ================= > ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Mon Aug 12 20:31:26 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Mon, 12 Aug 1996 21:31:26 +0200 Subject: [PYTHON MATRIX-SIG] fromFunction... In-Reply-To: <199608112109.RAA11928@maigret> (da@maigret.cog.brown.edu) Message-ID: <9608121931.AA06170@acds21> In 1.0a1, fromFunction is absent. I miss it. =) Now, the last we talked about this, there were still some issues that had to be hacked out, and Konrad pseudo-volunteered, but since then he took a vacation, a job, moved, and is now somewhat netisolated. Does anyone else feel up to the task? Or Konrad, are you still interested/able? Interested yes, but not yet able, and it might take a while. Next week I'll take up my new job in France, and I might be a bit busy for a while... as efficiently as possible. Maybe there are much better ways than what I just wrote, but it sure was simple. If someone can show me how to do the above without fromFunction, that'd be nice too. I Well, the old fromFunction was a rather simple Python function, which you might just grab from the old Numeric.py. I don't like its limitations, but if it works for you, use it! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Mon Aug 12 20:47:55 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Mon, 12 Aug 1996 20:47:55 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Empty matrix implementation references Message-ID: I mentioned these in a previous message, so here they are: The relevant Octave documentation page is on the www: http://www.che.wisc.edu/cgi-bin/info2www?(octave)Empty%20Matrices The papers cited are Carl de Boor, `An Empty Exercise', SIGNUM, Volume 25, pages 2-6, 1990 C. N. Nett and W. M. Haddad, `A System-Theoretic Appropriate Realization of the Empty Matrix Concept', IEEE Transactions on Automatic Control, Volume 38, Number 5, May 1993. >From the URL above: > Briefly, given a scalar `s', and an M by N matrix `M(mxn)', and > an M by N empty matrix `[](mxn)' (with either one or both > dimensions equal to zero), the following are true: > > s * [](mxn) = [](mxn) * s = [](mxn) > > [](mxn) + [](mxn) = [](mxn) > > [](0xm) * M(mxn) = [](0xn) > > M(mxn) * [](nx0) = [](mx0) > > [](mx0) * [](0xn) = 0(mxn) This covers 2d arrays only, but it should be possible to extend it to n-dimensional arrays, n>=1, by adding missing dimensions to arrays as usual. For example, if a.shape=(0,n), it should probably behave as if a.shape=(1,1,0,n), when involved in an operation with a (possibly empty) 4-d array. This doesn't seem to conflict with the present handling of 0-d arrays (scalars), either. It would be nice if all functions and operators in the standard distribution could handle empty matrices as a special case, and do the right thing (whatever that may be in each case). Again, the aim would be to eliminate having to test for empty matrices explicitly in python code. Empty matrices do occur reasonably often in state-space descriptions of systems. Whether this is important enough at this stage is another matter... Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Carlos Fonseca Mon Aug 12 20:36:38 1996 From: Carlos Fonseca (Carlos Fonseca) Date: Mon, 12 Aug 1996 20:36:38 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Default axis In-Reply-To: <01BB8787.412159A0@ling-ling.lcs.mit.edu> Message-ID: On Sun, 11 Aug 1996, Jim Hugunin wrote: > ... > My only problem with this is the concatenation function which I > personally think should only be implemented along axis 0, though I've > been convinced this is too limiting. Having this default to a different Being able to cleanly concatenate arrays along other axes would indeed be useful. Otherwise, we'll end up transposing the concatenation of transposed arrays sooner or later. > Having this default to a different axis than 0 really bothers me, but > I suppose I'll get over it. > > Comments are welcome - Jim Concatenation does seem to be a special case, and there may a reason to make it the exception. For example, >>> a 0 1 2 3 4 5 6 7 8 9 10 11 >>> b 0 1 2 3 Since these arrays are aligned in the usual sense (a+b would work), one would expect concatenate((a,b)) to work by default. This means axis=0. What do others think? Actually, the above would not work in the present implementation if b.shape=(4,), but one would have to write concatenate((a,b[NewAxis,:])). Should it be so or should the new axis be prepended automatically? Along the same lines, shouldn't axes with a single element be "broadcast" as for addition? Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Mon Aug 12 20:37:25 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Mon, 12 Aug 1996 21:37:25 +0200 Subject: [PYTHON MATRIX-SIG] Default axis In-Reply-To: <01BB8787.412159A0@ling-ling.lcs.mit.edu> (message from Jim Hugunin on Sun, 11 Aug 1996 13:16:05 -0400) Message-ID: <9608121937.AA06206@acds21> Several people how now brought up the issue of the default axis in the = various functions in NumPy. The inconsistency of this definition is = really a problem. I think that it's really important to have a = consistent default axis, and I propose that the default axis be made -1 = (or -2 for things that expect 2d arrays). This works fairly well for me = The matter is really a bit more complicated. Basically, the problem occurs for arrays whose indices should logically be divided into two sections: a "superarray" with elements that are subarrays (in J these are called frames and cells, respectively). There are operations that act on the superarray, like reduction, and the best default axis for those is 0. Other operations act on cells (e.g. 1D FFT), and their default axis should be -1. (In J the first type of function would have infinite default rank, and the second one would have default rank 1). The distinction makes sense in practice and I am inclilned to keep it. Nobody will be happy with a setup in which you almost always have to specify an axis explicitly due to a bad default value. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@oasis.unl.edu Mon Aug 12 23:03:25 1996 From: drh@oasis.unl.edu (Doug Heisterkamp) Date: Mon, 12 Aug 1996 17:03:25 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] identity? and asarray? Message-ID: <199608122203.RAA00661@oasis.unl.edu> Hi, The function identity(n) does not return an n by n identity matrix. If the current definition is changed from: def identity(n): return resize([1]+n*[n], (n,n)) to def identity(n): return resize([1]+n*[0], (n,n)) then it does what I think the function means. The asarray(a,t) function is not returning a new matrix of type t. To do so, change from: def asarray(a, typecode=None): if type(a) == arraytype and (typecode == None or typecode == a.typecode()): return a elif typecode == None: return array(a) else: return a to def asarray(a, typecode=None): if type(a) == arraytype and (typecode == None or typecode == a.typecode()): return a elif typecode == None: return array(a) else: return array(a,typecode) When should a.asType(t) be use instead of asarray(a,t)? Is asType faster, always give a new copy, and/or safe? Doug Heisterkamp drh@oasis.unl.edu ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Tue Aug 13 08:57:39 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Tue, 13 Aug 1996 09:57:39 +0200 Subject: [PYTHON MATRIX-SIG] Empty matrix implementation references In-Reply-To: (message from Carlos Fonseca on Mon, 12 Aug 1996 20:47:55 +0100 (BST)) Message-ID: <9608130757.AA07268@acds21> n-dimensional arrays, n>=1, by adding missing dimensions to arrays as usual. For example, if a.shape=(0,n), it should probably behave as if a.shape=(1,1,0,n), when involved in an operation with a (possibly empty) 4-d array. This doesn't seem to conflict with the present handling of 0-d arrays (scalars), either. Any good book on APL2 contains a detailed discussion on empty arrays in complicated cases. Empty arrays are not just a curiosity, but an essential part of APL-style programming. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 13 14:51:25 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 13 Aug 1996 09:51:25 -0400 Subject: [PYTHON MATRIX-SIG] Empty matrix implementation references References: <9608130757.AA07268@acds21> Message-ID: <3210885D.4221@mit.edu> Konrad Hinsen wrote: > > n-dimensional arrays, n>=1, by adding missing dimensions to arrays as > usual. For example, if a.shape=(0,n), it should probably behave as if > a.shape=(1,1,0,n), when involved in an operation with a (possibly > empty) 4-d array. This doesn't seem to conflict with the present > handling of 0-d arrays (scalars), either. > > Any good book on APL2 contains a detailed discussion on empty arrays > in complicated cases. Empty arrays are not just a curiosity, but an essential > part of APL-style programming. Let me repeat here. I think empty arrays are very important, and unlike the 0.36 release, this new release really does handle empty arrays. Please do continue to point out specific problems, but I think I have the basic design well under control. If you find this isn't true, I'd like to see some examples of code that doesn't work as expected. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@oasis.unl.edu Tue Aug 13 14:47:54 1996 From: drh@oasis.unl.edu (Doug Heisterkamp) Date: Tue, 13 Aug 1996 08:47:54 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] Eigenvectors Message-ID: <199608131347.IAA01538@oasis.unl.edu> Hi, Here's an eigenvector function to add to the updated LinAlg.py module that Janne Sinkkonen posted a few days ago. If anyone has other LAPACK access functions and wishes to share them, email them to me and I'll merge them in with LinAlg.py. Doug Heisterkamp drh@oasis.unl.edu # Eigenvectors def eigenvectors(a): """eigenvectors(a) returns u,v where u is the eigenvalues and v is a matrix of eigenvectors with vector v[i] corresponds to eigenvalue u[i]. The eigenvectors are the rows of the matrix v. Satisfies the equation dot(a,v[i]) = u[i]*v[i] """ _assertRank2(a) _assertSquareness(a) t =_commonType(a) real_t = _array_type[0][_array_precision[t]] lapack_routine = _findLapackRoutine('geev', t) a = _castCopyAndTranspose(t, a) n = a.shape[0] dummy = Numeric.zeros((1,), t) lwork = max(1,8*n) # minimum value: max(1,3*n) real, max(1,2*n) complex work = Numeric.zeros((lwork,), t) if _array_kind[t] == 1: # Complex routines take different arguments w = Numeric.zeros((n,), t) rwork = Numeric.zeros((n,),real_t) v = Numeric.zeros((n,n), t) results = lapack_routine('N', 'V', n, a, n, w, dummy, 1, v, n, work, lwork, rwork, 0) else: wr = Numeric.zeros((n,), t) wi = Numeric.zeros((n,), t) vr = Numeric.zeros((n,n), t) results = lapack_routine('N', 'V', n, a, n, wr, wi, dummy, 1, vr, n, work, lwork, 0) if Numeric.logicalAnd.reduce(Numeric.equal(wi, 0.)): w = wr v = vr else: w = wr+1j*wi v = Numeric.array(vr,Numeric.Complex()) ind = Numeric.nonzero( Numeric.equal( Numeric.equal(wi,0.0) # true for real e-vals ,0) # true for complex e-vals ) # indices of complex e-vals for i in range(len(ind)/2): print "processing i=",i v[ind[2*i]] = vr[ind[2*i]] + 1j*vr[ind[2*i+1]] v[ind[2*i+1]] = vr[ind[2*i]] - 1j*vr[ind[2*i+1]] print "New v = ",v if results['info'] > 0: raise LinAlgError, 'Eigenvalues did not converge' return w,v ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@oasis.unl.edu Tue Aug 13 15:35:25 1996 From: drh@oasis.unl.edu (Doug Heisterkamp) Date: Tue, 13 Aug 1996 09:35:25 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] RE: Eigenvalues Message-ID: <199608131435.JAA01619@oasis.unl.edu> I should know better then to mail anything out before my second cup of coffee. The previous mailing with the eigenvector function has some print statements left over from debugging. Just remove them. ... for i in range(len(ind)/2): ------> print "processing i=",i v[ind[2*i]] = vr[ind[2*i]] + 1j*vr[ind[2*i+1]] v[ind[2*i+1]] = vr[ind[2*i]] - 1j*vr[ind[2*i+1]] ------> print "New v = ",v if results['info'] > 0: ... Doug Heisterkamp drh@oasis.unl.edu ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 13 16:04:16 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 13 Aug 1996 11:04:16 -0400 Subject: [PYTHON MATRIX-SIG] Histogram? References: Message-ID: <32109970.3BE4@mit.edu> Jean-Bernard ADDOR wrote: > > Thanks for your help. > > Are binarysearch and concatenate in the new matrix module 1.0alpha1 ? > > Jean-Bernard Yes, and even in doc.html - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 13 16:12:33 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 13 Aug 1996 11:12:33 -0400 Subject: [PYTHON MATRIX-SIG] First impressions from the docs References: Message-ID: <32109B61.26E9@mit.edu> Konrad Hinsen wrote: ... > In general, the current function set is a big step forward. I > expectthat I can now replace most awkward constructions in my > applicationcode by something more concise and more efficient. More on > that whenI am finished... Well of course you think its a big step forward, I did almost everything you asked for... ;) > I would like to see more flexibility in the constructor if it iscalled > with a non-sequence first argument. It should try to dosomething > meaningful whenever possible. If presented with a file,for example, it > should assume a text file with numbers and doits best to turn it into > an array (this is very important forreading data produced by other > programs). And for argumentsthat have no type/class with special > meaning, it should calla method toArray() if it exists.I do realize > that reading from a file intelligently is a non-trivialproblem, and > therefore the best solution is probably to provide afunction hook > similar to the one for array printing. Thatgives everyone ample > opportunity to play with array reading code.I have a function (in > Python) that reads 1D and 2D arrays wellenough for me, but it is not > very efficient. That could be astarting point for a more sophisticated > version. I completely disagree with this. I think that reading an array from a text file should probably be a function that comes with the standard distribution, but I see NO good reason to overload the array creation operator with this. There is support for something like a toArray method, I'll have to remember what this is and add it to ths docs. I'd be happy to add your fromFile function to Numeric if you want to send it to me. > I wonder what exactly resize() does. First, I don't understand whyit > is less efficient than reshape(); if the size remains the same, > itshould perform exactly the same operation. But I really wonder > what"strange" things can happen if I am not "careful". As long as > theshape argument makes sense (i.e. contains no negative numbers) > theresult should be well defined. If the size remains the same, resize is exactly as efficient as reshape. All of my warnings are there because I think many people will find resize a slightly unusual concept. I think it needs some sort of dangerous bend signs around it so that novice users won't be confused. If I think I'm just applying a reshape function, but I make a mistake in my matrix size, I personally want to see an exception. resize will instead give me a very different array from what I expected. That's the strange thing that can happen. > The function diagonal() is a typical example of a function thatwould > benefit from J-style function ranks. As it is defined now,it assumes > that higher-rank arrays are to be treated as arraysof 2D subarrays > (i.e. function rank 2). This is a useful function,but a "true" > higher-rank diagonal (the list of elements for whichall indices are > equal), corresponding to function rank infinity,is also useful. The > same applies to trace(). I agree with this, but I've decided to keep ranks out of the 1.0 release as a general rule. I'm more concerned at the moment with getting something coherent out the door. > The axis defaults for sort() and argsort() should be 0. Default axes...this merits a new thread... > There are two methods that I would like to see as functions: > shape()and asType(). Both occur commonly in numerical algorithms, > wheretheir argument might be a rank-0 array (i.e. a > scalar).(Alternatively the two methods could be added to the > Pythonscalar types, but I am not sure if Guido would approve such > achange.) I'll add shape, I find I need it all the time too, its really nice to be able to get the shape of a list or a tuple. > I still think that in the general spirit of Python, the defaultmath > module used by Numeric should be umath, not fast_umath.For someone who > doesn't know all the details, it is betterto be slow than to be wrong. This also needs its own thread as there are several issues here. > More when I have the code running... Glad to see that you're back with us too - Jim > Konrad. ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 13 16:18:38 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 13 Aug 1996 11:18:38 -0400 Subject: [PYTHON MATRIX-SIG] Comments on building dynamic libraries Message-ID: <32109CCE.608C@mit.edu> Just a comment to those out there trying to build NumPy as a dynamic library. First, thanks for checking this out! Second, due to a bug in 1.4b2, dynamic modules cannot be loaded from the current directory. This will be fixed in 1.4b3, but until then you need to make sure that your dynamic modules are in your PYTHON_PATH and that you are in a different directory from where the modules exist. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 13 16:28:31 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 13 Aug 1996 11:28:31 -0400 Subject: [PYTHON MATRIX-SIG] Default axis References: Message-ID: <32109F1F.5852@mit.edu> Konrad Hinsen wrote: > > Several people how now brought up the issue of the default axis in the = > various functions in NumPy. The inconsistency of this definition is = > really a problem. I think that it's really important to have a = > consistent default axis, and I propose that the default axis be made -1 = > (or -2 for things that expect 2d arrays). This works fairly well for me = > > The matter is really a bit more complicated. Basically, the problem > occurs for arrays whose indices should logically be divided into > two sections: a "superarray" with elements that are subarrays (in J these > are called frames and cells, respectively). There are operations > that act on the superarray, like reduction, and the best default axis > for those is 0. Other operations act on cells (e.g. 1D FFT), and their > default axis should be -1. (In J the first type of function would have > infinite default rank, and the second one would have default rank 1). > The distinction makes sense in practice and I am inclilned to keep it. > Nobody will be happy with a setup in which you almost always have to > specify an axis explicitly due to a bad default value. > > Konrad. I find myself almost always typing add.reduce(a, -1). What I mean by this function is to do the reduction along all of the vectors in my matrix. Why is it unreasonable to assume that functions like add.reduce act on the cells of the array? As far as sort is concerned, this function only makes sense to me as operating on 1d arrays (where scalars are the elements to be sorted) if you want to sort anything else then you need to define a python comparison function, and at that point you might as well just write the whole thing as python code. Since sort naturally applies only to 1d arrays, I think its default axis should be -1. Now concatenate is another story entirely, and my current thoughts there are to leave axis=0 as its default. This will be the one exception to the axis=-1 rule. I also disagree that concatenate should broadcast its arguments. should concatenate([[1,2,3],[4,5,6]], 0) -> [[1,2,3],[4,5,6],[0,0,0]]? I certainly hope not! on the other hand, to steal from another post: Carlos Fonseca wrote: > >>> a > 0 1 2 3 > 4 5 6 7 > 8 9 10 11 > >>> b > 0 1 2 3 > > Since these arrays are aligned in the usual sense (a+b would work), > one would expect concatenate((a,b)) to work by default. This means > axis=0. What do others think? > > Actually, the above would not work in the present implementation if > b.shape=(4,), but one would have to write concatenate((a,b[NewAxis,:])). What you have to write in the current implementation is concatenate( (a, [b]) ). This to me is not too much work to make sure that the user understands what s/he's doing, and this is perfectly in line with the notion of concatentation found in the rest of python. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From acannon@geog.ubc.ca Tue Aug 13 18:51:35 1996 From: acannon@geog.ubc.ca (Alex Cannon) Date: Tue, 13 Aug 1996 10:51:35 -0700 (PDT) Subject: [PYTHON MATRIX-SIG] Gist under 1.4b2/NumPy 1.0a1 In-Reply-To: <32109B61.26E9@mit.edu> Message-ID: Having gotten the new extension installed and running, and before I try more installation, does anyone know whether the Gist module is still functional under NumPy 1.0a1? Alex ------------------------------------------------------------ Alex Cannon (acannon@geog.ubc.ca) Geography 240C Atmospheric Science Programme Tel: (604) 822-2269 University of British Columbia, B.C. Fax: (604) 822-6150 ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Tue Aug 13 19:17:51 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Tue, 13 Aug 1996 13:17:51 -0500 Subject: [PYTHON MATRIX-SIG] little buggies Message-ID: <199608131816.OAA16768@python.org> Hi, Here some problems I found when playing around with the new version of numerical python. Sorry if they've allready been noted. 1) divmod crashes the interpreter when invoked with array arguments. >>> a 1 1 1 1 1 >>> b 2 2 2 2 2 >>> print divmod(a,b) Segmentation fault 2) Choose faults also for bad indices. >>> choose((0,1,2),(a,b)) Segmentation fault 3) Where insists that condition be 0,1 instead of 0, nonzero : is this right? -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 13 21:18:39 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 13 Aug 1996 16:18:39 -0400 Subject: [PYTHON MATRIX-SIG] alpha2 and default axes Message-ID: <3210E31F.6522@mit.edu> Thanks to all for your bug reports. There were actually less than I expected, I hope this is a comment on the quality of the code, and not the quantity of the testing. I want to get a new release out this week with all these little bug fixes, but I'd prefer to address one major issue before then. What to do about default axes? I'd really like some more feedback from you people out there as to what the default axes for the various NumPy functions should be. The basic functions I see here are: ufunc.reduce, ufunc.accumulate, sort, argsort, argmax, ... fft take, choose, repeat, compress concatenate My current plan is to make the default argument for everything -1, except use 0 for concatenate. So far the only other proposal is from Konrad and it suggests using 0 as the default argument for everything except fft. I disagree with this, but could easily see keeping 0 as the default argument for take, choose, repeat, and compress. More opinions would be helpful - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Tue Aug 13 22:22:36 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 14 Aug 1996 00:22:36 +0300 Subject: [PYTHON MATRIX-SIG] default axes In-Reply-To: Jim Hugunin's message of Tue, 13 Aug 1996 16:18:39 -0400 References: <3210E31F.6522@mit.edu> Message-ID: Jim Hugunin writes: > ufunc.reduce, ufunc.accumulate, sort, argsort, argmax, ... > fft For ufunc.add.reduce(), sort() & Co., and fft(), -1 seems the most natural choice for me. > take, choose, repeat, compress About take(), I don't really know. Maybe 0. choose()... does it have a default axis? repeat() is like concatenate(), the default axis should be 0. compress()... no idea. trace() and diagonal()... should they operate on the diagonal between -1 and -2, especially if reduce and the others will use the default axis -1. If the default conceptualization is that there is an N-1-dimensional array of vectors, for trace() it would seem natural to think that the array is an N-2-dimensional array of matrices. Likewise, dot() should reduce -1. -- Janne Sinkkonen ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Wed Aug 14 00:41:20 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Tue, 13 Aug 1996 18:41:20 -0500 Subject: [PYTHON MATRIX-SIG] Re: Strange behaviour with make. In-Reply-To: <32109B61.26E9@mit.edu> (message from Jim Hugunin on Tue, 13 Aug 1996 11:12:33 -0400) Message-ID: <199608132339.TAA17773@python.org> I though I'd mention this to see if anyone else had this problem: When I first tried to make the Numeric, make Makefile -f Makefile.pre.in sent my machine into infinite loop. I mucked around a bit and got it to work. However, when I tried to recreate it I got stumped. Once I unpacked it fresh and it looped again. When I copied the Makefile.pre.in from the working version of NumPy over, it worked. "AH HA! I just need to dof a diff and I'll know the problem." So I did a diff against the original and there was NO DIFFERENCE. So I unpacked NumPy again into another directory and this time it worked. And it worked several more times. So now I'm stumped. Did anyone else see this? On a different note: zeros is sort of uninformative if you give it a number instead of a tuple (an easy mistake...). >>> from Numeric import * >>> zeros(5) Traceback (innermost last): File "", line 1, in ? AttributeError: __len__ >>> zeros((5)) Traceback (innermost last): File "", line 1, in ? AttributeError: __len__ >>> zeros((5,)) 0 0 0 0 0 -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jbaddor@phy.ulaval.ca Wed Aug 14 01:39:56 1996 From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR) Date: Tue, 13 Aug 1996 20:39:56 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] strange behaviour In-Reply-To: <199608132339.TAA17773@python.org> Message-ID: >>> max(arange(5),3) 0 1 2 3 4 >>> min(arange(5),3) 3 Jean-Bernard ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Wed Aug 14 14:41:22 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Wed, 14 Aug 1996 08:41:22 -0500 Subject: [PYTHON MATRIX-SIG] Re: Strange behaviour with make. In-Reply-To: <199608132339.TAA17773@python.org> (tim@lassi.ece.uiuc.edu) Message-ID: <199608141342.JAA18977@python.org> >I though I'd mention this to see if anyone else had this problem: > >When I first tried to make the Numeric, >make Makefile -f Makefile.pre.in >sent my machine into infinite loop. Never mind, I figured it out. (I'm using a laptop running linux, and the clock stops whenever I shut the case. So, the date creeps back until I resynchronize it with the system clock. In this case, the NumPy files were newer than the current time on my machine. The reason I could no longer recreate the looping is that my system time caught up with the file creation time....) -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jbaddor@phy.ulaval.ca Wed Aug 14 15:01:08 1996 From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR) Date: Wed, 14 Aug 1996 10:01:08 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] NumPy.html Message-ID: To add more explanation about the definition of shape could be usefull. I hope that in the future some examples could be added. (Firstly, I didn't understood that for 1D (n,) is needed.) Jean-Bernard ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 14 15:12:51 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 14 Aug 1996 10:12:51 -0400 Subject: [PYTHON MATRIX-SIG] Re: zeros with single integer References: <9608132339.AA11679@MIT.EDU> Message-ID: <3211DEE3.7D2F@mit.edu> tim@lassi.ece.uiuc.edu wrote: > On a different note: zeros is sort of uninformative if you give it a > number instead of a tuple (an easy mistake...). > >>> from Numeric import * > >>> zeros(5) I find this so common that zeros will now accept a single integer instead of a 1 dimensional tuple. This makes the error message completely go away. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Wed Aug 14 16:24:22 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Wed, 14 Aug 1996 17:24:22 +0200 Subject: [PYTHON MATRIX-SIG] First impressions from the docs In-Reply-To: <32109B61.26E9@mit.edu> (message from Jim Hugunin on Tue, 13 Aug 1996 11:12:33 -0400) Message-ID: <9608141524.AA11022@acds21> > should assume a text file with numbers and doits best to turn it into > an array (this is very important forreading data produced by other > programs). And for argumentsthat have no type/class with special > meaning, it should calla method toArray() if it exists.I do realize I completely disagree with this. I think that reading an array from a text file should probably be a function that comes with the standard distribution, but I see NO good reason to overload the array creation operator with this. There is support for something like a toArray Consistency. If there can be a toArray() method for all objects, there should be one for file objects too. Since it isn't possible to add methods to C types, hard-coding this feature into the array module is the next best thing IMO. If the size remains the same, resize is exactly as efficient as reshape. All of my warnings are there because I think many people will find resize a slightly unusual concept. I think it needs some sort of Well, it's in APL and in all languages derived from it, and it is one of the most fequently used functions to form special matrices. In fact, it would make sense to point out in the documentation that resize() is exactly what APL calls "reshape". In APL, reshaping with a new size is definitely more common than reshaping with the same total size. dangerous bend signs around it so that novice users won't be confused. All it takes is an explanation of the difference... Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 14 16:30:36 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 14 Aug 1996 11:30:36 -0400 Subject: [PYTHON MATRIX-SIG] naming conventions Message-ID: <3211F11C.5F70@mit.edu> I'm cleaning up the naming conventions in preparation for the alpha2 release. Basically there was a mixture of names like: fromstring and arrayRange Following the conventions of the python standard library, all of these have been converted to: arrayrange, astype, tolist, ... I think this is the path of minimal confusion. The functions that I'm not so happy with are the comparision functions (for which I've never had great names anyway). I decided to add an underscore to these names, which I think is also in the python naming tradition, but is different from the other "two word" names. I now have: equal, not_equal, greater_equal, ... and: logical_and, boolean_and, ... Also, I've decided to change the names of the precision functions (previously Float, Integer, and Complex) complexcode(32) floatcode(32) intcode(16) ... These names are clearly much more consistent than the previous ones, however, I still can see room for improvement. As usual, comments are encouraged - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From mclay@eeel.nist.gov Wed Aug 14 12:26:19 1996 From: mclay@eeel.nist.gov (Michael McLay) Date: Wed, 14 Aug 1996 11:26:19 GMT Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: <3211F11C.5F70@mit.edu> References: <3211F11C.5F70@mit.edu> Message-ID: <199608141126.LAA04342@fermi.eeel.nist.gov> Jim Hugunin writes: > Also, I've decided to change the names of the precision functions > (previously Float, Integer, and Complex) > > complexcode(32) > floatcode(32) > intcode(16) Thank you for making this change. The inclusion of the actual size will make it clear that the same size numbers will be used on all machines and it eliminates the need to remember the size names that are abstract. I am curious why the new notation looks like a function call. There should be a fairly short list of names needed. Could it be done as a constant like complexcode32 complexcode64? That would be easier to type. Also, isn't the code workd redundant? How about shortening the names to something like: Float -> float32 double -> float64 Integer -> int32 Long -> int64 Michael ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Wed Aug 14 17:43:03 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Wed, 14 Aug 1996 11:43:03 -0500 Subject: [PYTHON MATRIX-SIG] In place ufuncs. In-Reply-To: <3211F11C.5F70@mit.edu> (message from Jim Hugunin on Wed, 14 Aug 1996 11:30:36 -0400) Message-ID: <199608141641.MAA00539@python.org> What do people think of this? Is there any possibility of having in-place ufuncs (analagous to *=, +=, etc.). This seems like it might be both faster and save some space where its usefull. Something like unfunc.inplace(a,b). Usefull? Usefull? Hard? Trivial? -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 14 17:54:15 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 14 Aug 1996 12:54:15 -0400 Subject: [PYTHON MATRIX-SIG] In place ufuncs. References: <199608141641.MAA00539@python.org> Message-ID: <321204B7.1273@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > What do people think of this? > > Is there any possibility of having in-place ufuncs (analagous to *=, > +=, etc.). This seems like it might be both faster and save some space > where its usefull. Something like unfunc.inplace(a,b). > > Usefull? Usefull? Hard? Trivial? Trivial (you can have them now), but I refuse to document it because to me it looks really ugly. When python supports *=, etc. I'll be sure that array objects support that properly (all that will take is somebody contributing a clean set of patches to Guido). If you really want inplace functions, try this: >>> a = arange(3) >>> add(a, 10, a) 10 11 12 >>> a 10 11 12 -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jbaddor@phy.ulaval.ca Wed Aug 14 17:23:01 1996 From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR) Date: Wed, 14 Aug 1996 12:23:01 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: <3211F11C.5F70@mit.edu> Message-ID: On Wed, 14 Aug 1996, Jim Hugunin wrote: > > complexcode(32) > floatcode(32) > intcode(16) > ... > What about floatcode(16), I have arrays of more than 1 000 000 elements, I need to save memory. Jean-Bernard ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 14 18:00:58 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 14 Aug 1996 13:00:58 -0400 Subject: [PYTHON MATRIX-SIG] naming conventions References: <3211F11C.5F70@mit.edu> <199608141126.LAA04342@fermi.eeel.nist.gov> Message-ID: <3212064A.3F28@mit.edu> Michael McLay wrote: > > Jim Hugunin writes: > > > Also, I've decided to change the names of the precision functions > > (previously Float, Integer, and Complex) > > > > complexcode(32) > > floatcode(32) > > intcode(16) > > Thank you for making this change. The inclusion of the actual size > will make it clear that the same size numbers will be used on all > machines and it eliminates the need to remember the size names that > are abstract. I am curious why the new notation looks like a function > call. There should be a fairly short list of names needed. Could it > be done as a constant like complexcode32 complexcode64? That would > be easier to type. Also, isn't the code workd redundant? How about > shortening the names to something like: > > Float -> float32 > double -> float64 > Integer -> int32 > Long -> int64 Okay, I like your names better than mine, though in this case I would use capital letters. Float32 Int32 ... This is consistent with the naming conventions for constants in python as in Ellipses and None, (and in NumPy as in NewAxis). My problem now is an easy way to specify that I want an array of floats that are the same size as python floats. I don't believe there is any guarantee that this is the same as Float64 on all systems. I used floatcode() as a way to specfify that in my system. types.FloatType is an option, but a little bit cumbersome for my tastes. And I'd probably import that as well as IntType and ComplexType into the Numeric namespace. Other suggestions? I could probably support using float (the builtin function to convert to a python float) as the parameter but that would be a definate kludge. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 14 18:14:26 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 14 Aug 1996 13:14:26 -0400 Subject: [PYTHON MATRIX-SIG] naming conventions References: Message-ID: <32120972.224C@mit.edu> Jean-Bernard ADDOR wrote: > > On Wed, 14 Aug 1996, Jim Hugunin wrote: > > > > complexcode(32) > > floatcode(32) > > intcode(16) > > ... > > > What about floatcode(16), I have arrays of more than 1 000 000 elements, > I need to save memory. Float16 will not be suported. Float32 and Float64 are the only sizes of float that I know are supported natively on architectures that I'm familiar with. I would guess that Float128 will work on Crays (and others?) I have no desire to support any data types other than the native C ones (and complex numbers which are too important to ignore). Besides, if you really want to store only 16 bits of precision you should probably be using fixed precision numbers anyway (and Int16 will work just fine). -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Wed Aug 14 18:18:49 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 14 Aug 1996 20:18:49 +0300 Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: Jim Hugunin's message of Wed, 14 Aug 1996 11:30:36 -0400 References: <3211F11C.5F70@mit.edu> Message-ID: Jim Hugunin writes: > These names are clearly much more consistent than the previous ones, Could you provide a list of changes in the alpha2 release, like this oldname1 newname1 oldname2 newname2 etc... so it would be easier to convert existing code to use the new names. > however, I still can see room for improvement. Let's make all the improvements at once (for alpha2). It is much more easier to write code if the names of library functions are not constantly drifting... :) -- Janne Sinkkonen ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 14 18:26:36 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 14 Aug 1996 13:26:36 -0400 Subject: [PYTHON MATRIX-SIG] naming conventions References: <3211F11C.5F70@mit.edu> Message-ID: <32120C4C.1643@mit.edu> Janne Sinkkonen wrote: > > Jim Hugunin writes: > > > These names are clearly much more consistent than the previous ones, > > Could you provide a list of changes in the alpha2 release, like this > > oldname1 newname1 > oldname2 newname2 > etc... > > so it would be easier to convert existing code to use the new names. Will do, I might even provide an automated tool for that if I get around to it. > > however, I still can see room for improvement. > > Let's make all the improvements at once (for alpha2). It is much more > easier to write code if the names of library functions are not > constantly drifting... :) That's the point about trying to get to a beta1 release. As soon as I reach that point, I will be promising to avoid incompatible changes (if at all possible). For now I am much more concerned with getting things right than with being consistent (though I have every intention of getting this naming thing over with in alpha2). -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Wed Aug 14 18:22:10 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Wed, 14 Aug 1996 18:22:10 +0100 (BST) Subject: [PYTHON MATRIX-SIG] alpha2 and default axes In-Reply-To: <3210E31F.6522@mit.edu> Message-ID: On Tue, 13 Aug 1996, Jim Hugunin wrote: > [...] > > What to do about default axes? > > I'd really like some more feedback from you people out there as to what > the default axes for the various NumPy functions should be. The basic > functions I see here are: > > ufunc.reduce, ufunc.accumulate, sort, argsort, argmax, ... > fft -1 > take -1, so that take(b,argsort(a)) works > choose, Not applicable? > repeat, repeats= could actually be a tuple containing the number of times each dimension should be repeated. In this case, repeats[-1] should correspond to the last dimension of a, and any missing dimensions in repeats= should default to one. So, axis=-1 > compress -1, same as take() > concatenate 0, I *think*. In all cases, the ability to use non-default axes should be preserved. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Wed Aug 14 18:56:39 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Wed, 14 Aug 1996 19:56:39 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: <32120972.224C@mit.edu> References: <32120972.224C@mit.edu> Message-ID: <199608141756.TAA24610@nu> >>>>> "JH" == Jim Hugunin writes: JH> Float16 will not be suported. Float32 and Float64 are the only JH> sizes of float that I know are supported natively on JH> architectures that I'm familiar with. I would guess that JH> Float128 will work on Crays (and others?) I think the system where the size of the object is given as an integer is much better than this concatenation trick. With this new scheme you need more identifiers for less flexibility. What if I want Float48? alpha1 would accept it, and give me Float64 instead. How do you want to solve this now? Furthermore it is now more difficult to choose the size at runtime. Furthermore: If I have a Cray-python program that I load on my SGI, I'd like to get an exception for the Float128, not a compiler error. ? Rob. -- === Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ == ==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/ Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ==== == PGPid 0xFA19277D == Use Linux! Free Software Rules The World! ============= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From templon@studbolt.mit.edu Wed Aug 14 18:59:12 1996 From: templon@studbolt.mit.edu (Jeffrey Templon) Date: Wed, 14 Aug 1996 13:59:12 -0400 Subject: [PYTHON MATRIX-SIG] naming conventions Message-ID: <199608141759.NAA00572@studbolt.mit.edu> uh oh, will these names (e.g. FloatType) be something used within C/C++ extensions, or are they something I will have to type in python code?? (sorry, my use of NumPy is still at a low level.) I hope not the latter, it is really tiring to have to constantly peck at the shift key. having everything lowercase really speeds the typing up and slows the frustration down. I'd vote against making these types of names. Jeff ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From barton@simsg1.mdc.com Wed Aug 14 19:28:55 1996 From: barton@simsg1.mdc.com (Brien Barton) Date: Wed, 14 Aug 1996 11:28:55 -0700 (PDT) Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: <3212064A.3F28@mit.edu> Message-ID: On Wed, 14 Aug 1996, Jim Hugunin wrote: > Float32 > Int32 > ... > > My problem now is an easy way to specify that I want an array of floats > that are the same size as python floats. ... How about leaving off the number if you want the default size? i.e. Float, Int -- Brien =============================================================================== Brien Barton McDonnell Douglas Aerospace, Huntington Beach, CA email: barton@simsg1.mdc.com, voice: (714)896-2249, fax:(714)896-5939 "My witty proclivities are nothing compared to my ludicrous ineptitudes." - Bob Hope =============================================================================== ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From da@maigret.cog.brown.edu Wed Aug 14 20:52:18 1996 From: da@maigret.cog.brown.edu (David Ascher) Date: Wed, 14 Aug 1996 15:52:18 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: <3211F11C.5F70@mit.edu> from "Jim Hugunin" at Aug 14, 96 11:30:36 am Message-ID: <199608141952.PAA22561@maigret> > Also, I've decided to change the names of the precision functions > (previously Float, Integer, and Complex) > > complexcode(32) > floatcode(32) > intcode(16) I don't like the word code, mostly because it can mean so many things. I can think of at least N different meanings. =) Any other suggestions? "type"? --da ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 15 00:06:28 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Wed, 14 Aug 1996 18:06:28 -0500 Subject: [PYTHON MATRIX-SIG] In place ufuncs. In-Reply-To: <321204B7.1273@mit.edu> (message from Jim Hugunin on Wed, 14 Aug 1996 12:54:15 -0400) Message-ID: <199608142305.TAA01814@python.org> The '**' operator doesn't work as I'd expect. Is this the intended behaviour? >>> power(arange(4),2.) # Works OK. 0. 1. 4. 9. >>> arange(4) ** 2 # Also OK 0 1 4 9 >>> arange(4) ** 2. # Huh? Traceback (innermost last): File "", line 1, in ? TypeError: illegal argument type for built-in operation >>pow(arange(4),2.) # Oh, its same as pow. Traceback (innermost last): File "", line 1, in ? TypeError: illegal argument type for built-in operation >>> -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 15 00:55:19 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Wed, 14 Aug 1996 18:55:19 -0500 Subject: [PYTHON MATRIX-SIG] Re: Another way to crash the interpreter. In-Reply-To: <199608142305.TAA01814@python.org> (tim@lassi.ece.uiuc.edu) Message-ID: <199608142353.TAA01946@python.org> Admittedly this isn't a good idea, but it still shouldn't crash... >>> from Numeric import * >>> arange(4)[::0] Floating point exception -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 15 03:07:29 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Wed, 14 Aug 1996 21:07:29 -0500 Subject: [PYTHON MATRIX-SIG] Bug? inn fft module In-Reply-To: <199608142353.TAA01946@python.org> (tim@lassi.ece.uiuc.edu) Message-ID: <199608150206.WAA02265@python.org> Hi, I found what may be another bug. fft corrupts its argument when passed a complex argument. With a double argument it seems OK. >>> a = ones((4,), Complex()) >>> fft(a) # OK (4.+0.j) (0.+0.j) (0.+0.j) (0.+0.j) >>> a # OK (4.+0.j) (0.+0.j) (0.+0.j) (0.+0.j) >>> a = ones((4,), Complex()) >>> b = ones((4,), Float()) >>> fft(a), fft(b) # Both OK ( (4.+0.j) (0.+0.j) (0.+0.j) (0.+0.j), (4.+0.j) (0.+0.j) (0.+0.j) (0.+0.j)) >>> a # Ooops (4.+0.j) (0.+0.j) (0.+0.j) (0.+0.j) >>> b # But this is still OK 1. 1. 1. 1. >>> -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@cherokee.unl.edu Thu Aug 15 05:12:54 1996 From: drh@cherokee.unl.edu (Doug Heisterkamp) Date: Wed, 14 Aug 1996 23:12:54 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] Linear Least Squares for LinAlg.py Message-ID: <9608150412.AA02735@cherokee.unl.edu> Hi, I've written a linear least square function to add to LinAlg.py. Let me know if you find any problems with it. Doug Heisterkamp drh@cherokee.unl.edu # Linear Least Squares def solveLinearLeastSquares(a, b, rcond=1.e-10): """solveLinearLeastSquares(a,b) returns x,resids,rank,s where x minimizes 2-norm(|b - Ax|) resids is the sum square residuals rank is the rank of A s is an rank of the singual values of A in desending order If b is a matrix then x is also a matrix with corresponding columns. If the rank of A is less than the number of columns of A or greater than the numer of rows, then residuals will be returned as an empty array otherwise resids = sum((b-dot(A,x)**2). Singular values less than s[0]*rcond are treated as zero. """ one_eq = len(b.shape) == 1 if one_eq: b = b[:, Numeric.NewAxis] _assertRank2(a, b) # _assertSquareness(a) m = a.shape[0] n = a.shape[1] n_rhs = b.shape[1] ldb = max(n,m) if m != b.shape[0]: raise LinAlgError, 'Incompatible dimensions' t =_commonType(a, b) real_t = _array_type[0][_array_precision[t]] lapack_routine = _findLapackRoutine('gelss', t) bstar = Numeric.zeros((ldb,n_rhs),t) bstar[:b.shape[0],:n_rhs] = cp(b) a,bstar = _castCopyAndTranspose(t, a, bstar) # minimum value of lwork:3*min(n,m) + max([2*min(m,n),max(m,n),n_rhs]) lwork = 8*min(n,m) + max([2*min(m,n),max(m,n),n_rhs]) s = Numeric.zeros((min(m,n),),real_t) work = Numeric.zeros((lwork,), t) # Note: in next version rcond will be passed directly to lapack module # by for now wrap it in an array arcond = Numeric.array([rcond],real_t) if _array_kind[t] == 1: # Complex routines take different arguments rwork = Numeric.zeros((5*min(m,n)-1,), real_t) results = lapack_routine( m, n, n_rhs, a, m, bstar,ldb , s, arcond, 0,work,lwork,rwork,0 ) else: results = lapack_routine( m, n, n_rhs, a, m, bstar,ldb , s, arcond, 0,work,lwork,0 ) if results['info'] > 0: raise LinAlgError, 'SVD did not converge in Linear Least Squares' resids = Numeric.array([],t) if one_eq: x = cp(Numeric.ravel(bstar)[:n]) if (results['rank']==n) and (m>n): resids = Numeric.array([Numeric.sum((Numeric.ravel(bstar)[n:])**2)]) else: x = cp(transpose(bstar)[:n,:]) if (results['rank']==n) and (m>n): resids = cp(Numeric.sum((transpose(bstar)[n:,:])**2)) return x,resids,results['rank'],cp(s[:min(n,m)]) ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Thu Aug 15 09:26:03 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Thu, 15 Aug 1996 10:26:03 +0200 Subject: [PYTHON MATRIX-SIG] Default axis In-Reply-To: <32109F1F.5852@mit.edu> (message from Jim Hugunin on Tue, 13 Aug 1996 11:28:31 -0400) Message-ID: <9608150826.AA12033@acds21> I find myself almost always typing add.reduce(a, -1). What I mean by this function is to do the reduction along all of the vectors in my matrix. Why is it unreasonable to assume that functions like add.reduce act on the cells of the array? Anything must be possible; the question is just which version is most frequent and should be the default. If you follow the J convention for arrays with subarrays, i.e. the first indices label the frames and the last the cells, then a sum over a list of vectors would be add.reduce with axis 0. With axis -1 you would get a list of the sum of the elements of each vector. Both are reasonable, but the first one is much more frequent. On the other hand, there are operations tyhat in such cases would typically operate on the individual vectors (such as sort), and those would typically be applied to axis -1. Of course you can also adopt the opposite convention for index assignment, but that doesn't change the fact that different functions should have different default axes. Now concatenate is another story entirely, and my current thoughts there are to leave axis=0 as its default. This will be the one exception to the axis=-1 rule. I also disagree that concatenate should broadcast its arguments. should concatenate([[1,2,3],[4,5,6]], 0) -> [[1,2,3],[4,5,6],[0,0,0]]? I certainly hope not! I certainly hope that it does! Adding a zero column or row to an array is a frequent function, and in the old version extremely complicated (and probably slow). A good example is my interpolation code (which I don't havew at hand right now, but I think I have posted it a while ago). And replying to Carlos' question: > Since these arrays are aligned in the usual sense (a+b would work), > one would expect concatenate((a,b)) to work by default. This means > axis=0. What do others think? I agree. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Thu Aug 15 09:37:44 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Thu, 15 Aug 1996 10:37:44 +0200 Subject: [PYTHON MATRIX-SIG] default axes In-Reply-To: (message from Janne Sinkkonen on 14 Aug 1996 00:22:36 +0300) Message-ID: <9608150837.AA12057@acds21> For ufunc.add.reduce(), sort() & Co., and fft(), -1 seems the most natural choice for me. I agree about sort and fft, but not about reduce etc. (Besides, another argument is compatibility with the Python built-in reduce(), which when applied to a nested list reduces along the outermost nesting level, i.e. the first axis. > take, choose, repeat, compress About take(), I don't really know. Maybe 0. choose()... does it have a default axis? repeat() is like concatenate(), the default axis should be 0. compress()... no idea. I'd say 0 for all of them. trace() and diagonal()... should they operate on the diagonal between -1 and -2, especially if reduce and the others will use the default Definitely. matrices. Likewise, dot() should reduce -1. Actually, dot() is the only function about which I am not sure. There are several options that make sense: 1) Axis -1 for both arguments. Good for vectors and lists of vectors. 2) Axis -1 for the first and -2 for the second. Good for matrices and lists of matrices. 3) Axis -1 for the first and 0 for the second. Good for higher-rank tensors. My personal favourite is 3), but I can't give any relly good argument. But evidently dot() needs two optional axis arguments to cover all cases. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Thu Aug 15 09:47:54 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Thu, 15 Aug 1996 10:47:54 +0200 Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: <3211F11C.5F70@mit.edu> (message from Jim Hugunin on Wed, 14 Aug 1996 11:30:36 -0400) Message-ID: <9608150847.AA12104@acds21> Following the conventions of the python standard library, all of these have been converted to: arrayrange, astype, tolist, ... I'd prefer either capitalized versions or added underscores. Also, I've decided to change the names of the precision functions (previously Float, Integer, and Complex) complexcode(32) floatcode(32) intcode(16) ... Adding "code" makes sense from your point of view, but for soimeone jusrt reading a program it is confusing. I'd assume that "code" stands for "program code" if no other meaning is evident from context. How about "inttype(32)" etc.? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Thu Aug 15 09:56:53 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Thu, 15 Aug 1996 10:56:53 +0200 Subject: [PYTHON MATRIX-SIG] In place ufuncs. In-Reply-To: <199608142305.TAA01814@python.org> (tim@lassi.ece.uiuc.edu) Message-ID: <9608150856.AA12113@acds21> The '**' operator doesn't work as I'd expect. Is this the intended behaviour? Of course not, since ** and power() should always be exactly equivalent. Unfortunately I can't check what's wrong without having Python 1.4 :-( Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jbaddor@phy.ulaval.ca Thu Aug 15 12:18:53 1996 From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR) Date: Thu, 15 Aug 1996 07:18:53 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: <32120972.224C@mit.edu> Message-ID: So, it seems that intcode(8) would continue to be supported, it would be great to save space. How to detect overflows (and correct by setting to the minimum or maximum value)? Jean-Bernard On Wed, 14 Aug 1996, Jim Hugunin wrote: > Jean-Bernard ADDOR wrote: > > > > On Wed, 14 Aug 1996, Jim Hugunin wrote: > > > > > > complexcode(32) > > > floatcode(32) > > > intcode(16) > > > ... > > > > > What about floatcode(16), I have arrays of more than 1 000 000 elements, > > I need to save memory. > > Float16 will not be suported. Float32 and Float64 are the only sizes of > float that I know are supported natively on architectures that I'm > familiar with. I would guess that Float128 will work on Crays (and > others?) > > I have no desire to support any data types other than the native C ones > (and complex numbers which are too important to ignore). > > Besides, if you really want to store only 16 bits of precision you > should probably be using fixed precision numbers anyway (and Int16 will > work just fine). > > -Jim > > ================= > MATRIX-SIG - SIG on Matrix Math for Python > > send messages to: matrix-sig@python.org > administrivia to: matrix-sig-request@python.org > ================= > ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Thu Aug 15 14:18:25 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 15 Aug 1996 16:18:25 +0300 Subject: [PYTHON MATRIX-SIG] default axes In-Reply-To: Konrad Hinsen's message of Thu, 15 Aug 1996 10:37:44 +0200 References: <9608150837.AA12057@acds21> Message-ID: Konrad Hinsen writes: > Actually, dot() is the only function about which I am not sure. > There are several options that make sense: > 1) Axis -1 for both arguments. Good for vectors and lists of vectors. 2D-matrices are lists of vectors. The interpretation just depends. :) > 2) Axis -1 for the first and -2 for the second. Good for matrices > and lists of matrices. This would require the second argument to be two-dimensional. I would prefer a dot() which would give a scalar when applied to two vectors. This holds for 1) and 3). > 3) Axis -1 for the first and 0 for the second. Good for higher-rank > tensors. > My personal favourite is 3), but I can't give any relly good argument. I prefer 3) now. 3) would be nice for 2D matrices, because then 0 would be the same as -2. dot() refers to the mathematical concept of dot product or inner product, and I guess 3) would fulfill some clean formal definition provided both arguments are real objects and not lists of objects. If add.reduce() would operate on -1, then a dot like proposed in 1) would be equivalent to add.reduce(a*b) which is not too difficult to write, thus that kind of dot() would be more redundant than 3). On the other hand, Konrad had a good argument against reducing -1 (python's standard reduce reduces axis 0), so I'm not sure anymore about that. How about two functions? dot() would be like 3), and then there could be 'vdot()' (vector dot) like 1)? vdot() would eliminate the commonly needed add.reduce(a,b,-1), thus add.reduce() could reduce over 0 by default. > But evidently dot() needs two optional axis arguments to cover all cases. I agree. -- Janne ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 15 14:34:30 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 15 Aug 1996 09:34:30 -0400 Subject: [PYTHON MATRIX-SIG] Re: Bug? inn fft module References: <9608150205.AA29492@MIT.EDU> Message-ID: <32132766.277A@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > Hi, > > I found what may be another bug. fft corrupts its argument when > passed a complex argument. With a double argument it seems OK. Clearly a bug. I'll fix it - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 15 15:21:34 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 15 Aug 1996 10:21:34 -0400 Subject: [PYTHON MATRIX-SIG] In place ufuncs. References: <9608142304.AA11756@MIT.EDU> Message-ID: <3213326E.A9F@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > The '**' operator doesn't work as I'd expect. Is this the intended behaviour? ... This is actually a bug in the interpreter (it's there in 1.3 too, but nobody noticed). I've just sent off a patch for this to Guido. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Thu Aug 15 17:29:43 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Thu, 15 Aug 1996 18:29:43 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] Fun: hacking some Numerics. Message-ID: <199608151629.SAA17976@nu> I'm running python-1.4b2 + Numeric on an ALPHA. Just for fun I was hacking together a script to do dumb factorization. I have a few problems that could be due to this being a 64bit python, but I don't have 1.4b2 on any other machine here to test. Please help. My script and the output are appended below. Two questions with simpler cases are extracted from the script: 1) nu[160]NumPy% python Python 1.4b2 (Aug 12 1996) [C] Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam >>> from Numeric import * >>> array([], 'l') EmptyArray >>> array([], 'l')[0] 4294967296 >>> array([], 'l')[1] Traceback (innermost last): File "", line 1, in ? IndexError: index out of bounds >>> for i in array([], 'l'): ... print i ... 4294967296 2) nu[161]NumPy% python Python 1.4b2 (Aug 12 1996) [C] Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam >>> from Numeric import * >>> where([0,1,1,0,1,1],[0,0,0,0,0,0],[1,1,1,1,1,1]) 1 0 0 1 0 0 >>> where([0,1,2,0,1,2],[0,0,0,0,0,0],[1,1,1,1,1,1]) 1 0 0 0 0 0 Thanks in advance, Rob. ------------------------------------------------------------------------ from Numeric import * import math def sieve(max): numbers=range(max+1) size=int(math.sqrt(max)) if size<5: trials=[2,3] else: trials=sieve(size) for i in trials: try: j=i*i while 1: numbers[j]=0 j=j+i except IndexError: pass return filter(lambda x:x>1,numbers) def asieve(max): numbers=arange(max+1) # one is not prime numbers[1]=0 size=int(math.sqrt(max)) if size<5: trials=[2,3] else: trials=asieve(size) print "We need to try all in "+`trials` for i in trials: print "Filtering by %d"%i cond=numbers%i cond[i]=1 print cond print numbers numbers=where(cond,numbers,0) print numbers return nonzero(numbers) def factor(num,upto=1000000): for p in sieve(upto): if num%p==0: print "Can divide by %d"%p def afactor(num,upto=1000000): for p in asieve(upto): if num%p==0: print "Can divide by %d"%p factor(129753308,upto=99) afactor(129753308,upto=99) --------------------------------------------------------------- Can divide by 2 Can divide by 29 We need to try all in [2, 3] Filtering by 2 0 0 1 1 0 1 0 1 0 1 0 0 2 3 4 5 6 7 8 9 0 0 2 3 0 5 0 7 0 9 Filtering by 3 0 0 2 1 0 2 0 1 0 0 0 0 2 3 0 5 0 7 0 9 0 0 0 0 0 0 0 0 0 0 We need to try all in array([], 'l') Filtering by 4294967296 1 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 0 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------------------------------------------------------------------- -- === Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ == ==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/ Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ==== == PGPid 0xFA19277D == Use Linux! Free Software Rules The World! ============= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 15 17:51:04 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 15 Aug 1996 12:51:04 -0400 Subject: [PYTHON MATRIX-SIG] Fun: hacking some Numerics. References: <199608151629.SAA17976@nu> Message-ID: <32135578.77C9@mit.edu> Rob.Hooft@embl-heidelberg.de wrote: > > I'm running python-1.4b2 + Numeric on an ALPHA. Just for fun I was hacking > together a script to do dumb factorization. I have a few problems that could > be due to this being a 64bit python, but I don't have 1.4b2 on any other > machine here to test. Please help. ... First, I'm glad you're playing with this on an alpha. I have a couple around here, but don't have that much time to test on 64-bit systems. 1) where is fixed in alpha2 2) array([], 'l')[0] is a bug (even on 32bit machines) I'll fix it. 3) for i in array([], 'l') is the same bug. Thanks for the bugs - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 15 19:45:43 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 15 Aug 1996 14:45:43 -0400 Subject: [PYTHON MATRIX-SIG] Poll - Lapack and FFTPack Message-ID: <32137057.4579@mit.edu> I've discovered once again that building Lapack on a system without a FORTRAN compiler is a lot of ugly work, and you get something significantly slower than the "real" version in the bargain. Nonetheless, I've managed to convince myself that LAPACK is clearly the right way to go as far a standard linear algebra library is concerned for NumPy. Doug Heisterkamp's (and Konrad's) lapack interface module covers most of what people have been asking for in a standard library. Possible solution: 1) Everybody buys a FORTRAN compiler ;) 2) Everyone goes through a hellish day of porting to get lapack compiled on their system 3) I distribute precompilied lapack and fftpack libraries (with the blas) for ALL the common architectures. So, here's the poll: If you have a way to produce lapack/fftpack library binaries for a given platform and are able and willing to allow those binaries to be freely distributed, please send me a piece of mail listing your computer/os and what libraries you could provide. I'm assuming here that if you give me a statically linked lapack library, linked against libblas and libf77, then I can link this into my C module with no problem. If this isn't true, please help me understand this better. A little bit at my wits end over the whole standard library business... - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hohn@math.utah.edu Thu Aug 15 20:52:16 1996 From: hohn@math.utah.edu (Michael Hohn) Date: Thu, 15 Aug 1996 13:52:16 -0600 (MDT) Subject: [PYTHON MATRIX-SIG] Poll - Lapack and FFTPack In-Reply-To: <32137057.4579@mit.edu> (message from Jim Hugunin on Thu, 15 Aug 1996 14:45:43 -0400) Message-ID: <199608151952.NAA11267@alab07.math.utah.edu> >> ... >> Possible solution: >> >> 1) Everybody buys a FORTRAN compiler ;) >> >> 2) Everyone goes through a hellish day of porting to get lapack compiled >> on their system >> ... Actually, LAPACK seems to work with g77, the gnu fortran compiler (at least with version 0.5.17); installing it requires some disk space (~100Mb) as well as the gcc-2.7* source. Mike ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Thu Aug 15 19:39:10 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Thu, 15 Aug 1996 19:39:10 +0100 (BST) Subject: [PYTHON MATRIX-SIG] default axes In-Reply-To: Message-ID: On 15 Aug 1996, Janne Sinkkonen wrote: > > If add.reduce() would operate on -1, then a dot like proposed in 1) > would be equivalent to add.reduce(a*b) which is not too difficult to > write, thus that kind of dot() would be more redundant than 3). On the > other hand, Konrad had a good argument against reducing -1 (python's > standard reduce reduces axis 0), so I'm not sure anymore about that. I really think dot(a,b) should behave _exactly_ like add.reduce(a*b,axis=-1) The big difference is that, unlike the expression above, there would be no need to allocate memory to store a*b, just the final result. If, for example, a.shape=(m,n) b.shape=(n,p) then dot(a[...,NewAxis],b,axis=-2).shape = (m,p) -> matrix multiplication whithout having to allocate an array of shape=(m,n,p), as add.reduce would. In general, by adding axes as needed and broadcasting dimensions, one can perform anything from "vectorized" dot products to "vectorized" array multiplication of arbitrary rank. I proposed this to the list one or two months ago, but then never got back to it. Clearly, dot() should allow the default axis to be specified. Note that *one* axis seems to be enough: for a dot product of row vectors, all axes must be aligned. For "intermediate" rank multiplication, some axes must be aligned (assume the outer), while correctly adding the necessary additional axes will align the inner. Full rank multiplication of two arrays could be written: dot(a[...,(n-1)*(NewAxis,)],b,axes=-n) where n is the number of dimensions of b, and assuming the last dimension of a matches the first of b. > How about two functions? dot() would be like 3), and then there could > be 'vdot()' (vector dot) like 1)? vdot() would eliminate the commonly > needed add.reduce(a,b,-1), thus add.reduce() could reduce over 0 by > default. I believe this would be the way to go. Not that it really matters, but I would call your vdot() just dot(), and give matrix multiplication another name (mtimes(), mmult(), mprod(), whatever). All cases of matrix multiplication are possible with [v]dot(), yet I agree that adding axes by hand could be done better in a function built on top of dot(). Konrad> But evidently dot() needs two optional axis arguments to cover all cases. > > I agree. > -- > Janne See above. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Thu Aug 15 22:41:11 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Thu, 15 Aug 1996 17:41:11 -0400 Subject: [PYTHON MATRIX-SIG] naming conventions In-Reply-To: Your message of "Wed, 14 Aug 1996 13:26:36 EDT." <32120C4C.1643@mit.edu> References: <3211F11C.5F70@mit.edu> <32120C4C.1643@mit.edu> Message-ID: <199608152141.RAA09148@monty> > > so it would be easier to convert existing code to use the new names. > > Will do, I might even provide an automated tool for that if I get around > to it. There's a tool that should be pretty close to what you want (it lexes C code, but should be adaptable to lex Python code -- note there's a Python tokenizer in Lib/tokenizer.py): Tools/scripts/fixcid.py. I intend to use fixcid.py for the Great Renaming. (I still need to postprocess the output manually, for a variety of reasons, one of which is that I'm a perfectionist and would like to take the opportunity to do a general clean-up...). --Guido van Rossum (home page: http://www.python.org/~guido/) ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From phil@geog.ubc.ca Fri Aug 16 00:25:23 1996 From: phil@geog.ubc.ca (Phil Austin) Date: Thu, 15 Aug 1996 16:25:23 -0700 (PDT) Subject: [PYTHON MATRIX-SIG] Poll - Lapack and FFTPack In-Reply-To: <32137057.4579@mit.edu> References: <32137057.4579@mit.edu> Message-ID: <199608152325.QAA10650@coot.geog.ubc.ca> Jim Hugunin writes: > > So, here's the poll: > > If you have a way to produce lapack/fftpack library binaries for a given > platform and are able and willing to allow those binaries to be freely > distributed, please send me a piece of mail listing your computer/os and > what libraries you could provide. > We could do any of: Solaris 2.5 (Sparc 20) with f77 4.0 Sunos 4.1.4 (Sparc 20) with f77 2.0.1 AIX 3.2 with xlf (version ?) IRIX 6.2 with f77 6.2 (R5000 and R8000) IRIX 4.0.5 with f77 6.2 (R3000) Also the f2c'd version of fftpack that comes with Mumit Khan's fftpack++ has built on all of the above with gcc 2.7.2: (see http://www.xraylith.wisc.edu/~khan/software/fftpack/fftpack.html) ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Fri Aug 16 10:21:23 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Fri, 16 Aug 1996 11:21:23 +0200 Subject: [PYTHON MATRIX-SIG] Poll - Lapack and FFTPack In-Reply-To: <32137057.4579@mit.edu> (message from Jim Hugunin on Thu, 15 Aug 1996 14:45:43 -0400) Message-ID: <9608160921.AA14451@acds21> 3) I distribute precompilied lapack and fftpack libraries (with the blas) for ALL the common architectures. Netlib has LAPACK binaries for most common platforms. I remember that the SGI version they have is only for R4xxx processors, so I had to compile my own for the R3000, which I can offer to anyone who needs it. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Fri Aug 16 10:32:35 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Fri, 16 Aug 1996 11:32:35 +0200 Subject: [PYTHON MATRIX-SIG] default axes In-Reply-To: (message from Janne Sinkkonen on 15 Aug 1996 16:18:25 +0300) Message-ID: <9608160932.AA14512@acds21> > 2) Axis -1 for the first and -2 for the second. Good for matrices > and lists of matrices. This would require the second argument to be two-dimensional. I would prefer a dot() which would give a scalar when applied to two vectors. This holds for 1) and 3). Good point. I was actually assuming that axis=-2 is taken to mean -1 whenever there are not enough dimensions, an similrly axis=1 means axis=0 for a 1D array. But I am not at all sure if that is how the current code behaves. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Fri Aug 16 10:36:00 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Fri, 16 Aug 1996 05:36:00 -0400 Subject: [PYTHON MATRIX-SIG] default axes In-Reply-To: (message from Carlos Fonseca on Thu, 15 Aug 1996 19:39:10 +0100 (BST)) Message-ID: <199608160936.FAA20848@cyclone.ERE.UMontreal.CA> > I really think dot(a,b) should behave _exactly_ like > > add.reduce(a*b,axis=-1) Why? > Full rank multiplication of two arrays could be written: > > dot(a[...,(n-1)*(NewAxis,)],b,axes=-n) That is a lot too complicated for a frequent operation, especially considering that n might not be available as a variable or constant, i.e. it would have to be written as shape(b)[0]. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Fri Aug 16 11:14:05 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Fri, 16 Aug 1996 12:14:05 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] Another problem? Message-ID: <199608161014.MAA19954@nu> While hacking some more on my "code-cracker" :-) script, I found what I think is another problem: nu[101]NumPy% python Python 1.4b2 (Aug 12 1996) [C] Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam >>> from Numeric import * >>> nonzero([0,2,0,4]) 1 1 3 3 3 3 >>> from the description I read nonzero should return [1,3] here. It looks like a mixture with repeat... Furthermore, I did some more work on the script, got it working, but the results are very disappointing: Can divide by 2 Can divide by 29 factor took 10.577 seconds Can divide by 2 Can divide by 29 afactor took 7.916 seconds It gets WORSE if I increase the size of the problem. Profiling (run appended) changes the ratio between conventional and numeric dramatically, so that is rather useless in this case. Can anyone help me to make optimal use of the arrays here? The script is of no serious use whatsoever (it may make a simple demo), but my understanding of Numeric might be boosted.... Rob. ---------------------------------------------------------- from Numeric import * import math def sieve(max): numbers=range(max+1) size=int(math.sqrt(max)) if size<5: trials=[2,3] else: trials=sieve(size) for i in trials: try: j=i*i while 1: numbers[j]=0 j=j+i except IndexError: pass return filter(lambda x:x>1,numbers) def asieve(max,atype='l'): numbers=array([1],atype) numbers=resize(numbers,[max+1]) # one is not prime numbers[1]=0 size=int(math.sqrt(max)) if size<5: trials=[2,3] else: trials=asieve(size) #print "We need to try all in "+`trials` for i in trials: #print "Filtering %d by %d"%(max,i) cond=concatenate((array([1],atype),zeros([i-1],atype))) #print cond cond=resize(cond,[max+1]) #print cond cond[i]=0 #print cond #print numbers numbers=where(cond,0,numbers) #print numbers return nonzero(numbers) def factor(num,upto=1000000): for p in sieve(upto): if num%p==0: print "Can divide by %d"%p def afactor(num,upto=1000000): for p in asieve(upto): if num%p==0: print "Can divide by %d"%p import timing timing.start() factor(129753308,upto=99999) timing.finish() print "factor took %7.3f seconds"%(timing.micro()/1.e6) timing.start() afactor(129753308,upto=99999) timing.finish() print "afactor took %7.3f seconds"%(timing.micro()/1.e6) import profile #profile.run("factor(129753308,upto=99999)") #profile.run("afactor(129753308,upto=99999)") ---------------------------------------------------------- nu[120]NumPy% python ~/x.py Can divide by 2 Can divide by 29 100341 function calls (100339 primitive calls) in 284.433 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 216.867 216.867 284.433 284.433 profile:0(factor(129753308,upto=99999)) 0 0.000 0.000 profile:0(profiler) 1 0.000 0.000 67.567 67.567 python:0(14222.C.1) 100335 29.233 0.000 29.233 0.000 x.py:19() 3/1 38.133 12.711 67.367 67.367 x.py:4(sieve) 1 0.200 0.200 67.567 67.567 x.py:45(factor) Can divide by 2 Can divide by 29 397 function calls (395 primitive calls) in 15.233 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 77 0.033 0.000 0.033 0.000 Numeric.py:152(ravel) 3 0.033 0.011 0.233 0.078 Numeric.py:158(nonzero) 3 0.150 0.050 0.200 0.067 Numeric.py:16(arrayRange) 74 3.767 0.051 3.767 0.051 Numeric.py:171(where) 3 0.050 0.017 0.050 0.017 Numeric.py:192(ones) 151 2.133 0.014 2.133 0.014 Numeric.py:43(concatenate) 77 0.250 0.003 2.383 0.031 Numeric.py:81(resize) 3 0.000 0.000 0.000 0.000 Precision.py:34(Integer) 1 8.483 8.483 15.233 15.233 profile:0(afactor(129753308,upto=99999)) 0 0.000 0.000 profile:0(profiler) 1 0.000 0.000 6.750 6.750 python:0(14222.C.2) 3/1 0.117 0.039 6.533 6.533 x.py:21(asieve) 1 0.217 0.217 6.750 6.750 x.py:50(afactor) ------------------------------------------------------------- -- === Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ == ==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/ Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ==== == PGPid 0xFA19277D == Use Linux! Free Software Rules The World! ============= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Fri Aug 16 15:56:13 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Fri, 16 Aug 1996 09:56:13 -0500 Subject: [PYTHON MATRIX-SIG] Another problem? In-Reply-To: <199608161014.MAA19954@nu> (Rob.Hooft@embl-heidelberg.de) Message-ID: <199608161454.KAA07145@python.org> I was about to send some mail myself about the non-zero problem. I tracked it down in the numeric library and it looks like, def nonzero(a): """Return the indices of the elements of a which are not zero, a must be 1d """ return repeat(arange(len(a)), a) should be: def nonzero(a): """Return the indices of the elements of a which are not zero, a must be 1d """ return repeat(arange(len(a)), nonZero(a)) At least that gives the behaviour I expect. -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 16 16:14:41 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 16 Aug 1996 11:14:41 -0400 Subject: [PYTHON MATRIX-SIG] Another problem? References: <199608161014.MAA19954@nu> Message-ID: <32149061.45BC@mit.edu> Rob.Hooft@embl-heidelberg.de wrote: > > While hacking some more on my "code-cracker" :-) script, I found what I think > is another problem: > > nu[101]NumPy% python > Python 1.4b2 (Aug 12 1996) [C] > Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam > >>> from Numeric import * > >>> nonzero([0,2,0,4]) > 1 1 3 3 3 3 > >>> > > from the description I read nonzero should return [1,3] here. It looks > like a mixture with repeat... nonzero is implemented using repeat, I made a mistake in writing it to give that strange mixture. This is fixed in alpha2 which will be released before I go home tonight. > Furthermore, I did some more work on the script, got it working, but > the results are very disappointing: > > Can divide by 2 > Can divide by 29 > factor took 10.577 seconds > Can divide by 2 > Can divide by 29 > afactor took 7.916 seconds I'm running on a faster machine than you, so my numbers are faster in both cases, still the relative comparision is valid. Standard python version factor took 2.708 seconds Using NumPy - properly ;) afactor took 0.322 seconds Here's my new version of your afactor and asieve functions. The changes to afactor are actually not needed to get the speed improvement. I'd be tempted to claim that the new version of asieve is easier to understand as well as faster, the changes to afactor are a little awkward but I thought you might be interested in seeing the style anyway. I doubt that my new version is more than a factor of 2 slower than a C implementation of the same algorithm (though feel free to show me wrong with a code sample). def asieve(max,atype='l'): size=int(sqrt(max)) if size<5: known_primes=[2,3] else: known_primes=asieve(size) #Initially assume all numbers are prime numbers=ones([max+1], atype) #0 and 1 are not prime numbers[0:2]=0 #print trials for i in known_primes: #Set multiples of i to be nonprime numbers[(i*i)::i] = 0 #Those entries which are nonzero are prime return nonzero(numbers) def afactor(num,upto=1000000): #Calculate all of the primes up to upto s = asieve(upto) #Return just those primes that divide evenly into num for d in take(s, nonzero(equal(num % s, 0))): print "Can divide by %d"%d -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Fri Aug 16 16:29:48 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Fri, 16 Aug 1996 10:29:48 -0500 Subject: [PYTHON MATRIX-SIG] Factoring? In-Reply-To: <199608161014.MAA19954@nu> (Rob.Hooft@embl-heidelberg.de) Message-ID: <199608161528.LAA07312@python.org> Here's another factoring routine. It runs pretty fast (under a second using the profiler for '129753308'), but I have no idea if its very good algorithymically. I doubt that this is really what you want, but its yours to play with. I've been tweaking it recently, so if you find any bugs, let me know. Enjoy. def factor(n): """Return a tuple containing the factors of n. This is probably not the best way to do this, but hey, it's simple. """ # Take care of special cases. if n <= 0: raise ValueError elif n <= 3: return [n] elif n <= 5: c = arange(2,n+1) else: # General case. sr = int(sqrt(n)) c = concatenate((arange(2, n/sr), n/arange(sr,0,-1))) c = compress(equal(n%c,0), c) factors = [c[0]] while len(c) > 1: c = choose(notEqual(c[1:]%c[0],0), (c[1:]/c[0], c[1:])) if c[0] != 1: factors.append(c[0]) return factors -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 16 17:03:06 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 16 Aug 1996 12:03:06 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 Message-ID: <32149BBA.14D2@mit.edu> I've made my decisions on the final conventions for alpha2, but I thought I'd give people a chance to comment on them before the end of the day today when the release goes out. Yep, you heard right, alpha2 will be available before I go home tonight. These are also very likely to be the conventions for the final release, but I'm not making any promises until 1.0beta1. 1) Explicitly declaring an array's type Note: most people will never need to use any of these names as the typical array functions will produce the right type by default. For types constants will be defined within Numeric.py. They will have the following names (on a typical system, on a supercomputer their might be different values available): Float - the size of a python float, generally the largest float available on your system Float0 - the smallest float on your system (usually Float32) Float32 - usually how you get a C float Float64 - usually how you get a C double For integers: Integer and Integer0 as before UnsignedInteger8 Integer8 Integer16 Integer32 Integer64 (if you're lucky) For complex numbers: Complex, Complex0 Complex32 and Complex64 This solution is clearly a compromise, but the best compromise I could come up with. 2) Default axes After reading all of the discussion over what are the appropriate axes for the various operations, I've become convinced that there is no obvious choice. Therefore I think it is really important to have a single default axis so that at least people will only have one rule to remember. Because I can't possibly conceive of doing "fft" and its ilk with a default axis other than -1, every function in NumPy will have a default axis of -1 (or -2 for matrix operations). This currently includes all of the following functions. sort, argsort, argmax, argmin, fft, take, repeat, compress, concatenate, ufunc.reduce, ufunc.accumulate I wish I could come up with a better compromise, but I myself was finding it hard to remember what the default axes were for different operations, and that's just intolerable. I will add keyword arguments to all of the functions that accept an axis so that you can at least write concatenate([a,b], axis=0) which I think is much more readable than the non-keyword alternative. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Fri Aug 16 17:40:24 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Fri, 16 Aug 1996 11:40:24 -0500 Subject: [PYTHON MATRIX-SIG] Yet another way to crash the interpreter. In-Reply-To: <32149061.45BC@mit.edu> (message from Jim Hugunin on Fri, 16 Aug 1996 11:14:41 -0400) Message-ID: <199608161638.MAA07431@python.org> Hi, Here's one more: Numeric's sqrt doesn't work with long its. And other Numerical stuff seems to crash the interpreter when combined with long ints. For example: >>> from Numeric import * >>> sqrt(4l) Traceback (innermost last): File "", line 1, in ? AttributeError: attribute-less object >>> 4/arange(1,3) 4 2 >>> 4l/arange(1,3) Segmentation fault ...Later >>> from Numeric import * >>> 4l*arange(1,3) Segmentation fault -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 16 17:49:41 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 16 Aug 1996 12:49:41 -0400 Subject: [PYTHON MATRIX-SIG] Re: Yet another way to crash the interpreter. References: <9608161637.AA21236@MIT.EDU> Message-ID: <3214A6A5.1FDB@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > Hi, > > Here's one more: Numeric's sqrt doesn't work with long its. And other > Numerical stuff seems to crash the interpreter when combined with long > ints. For example: > > >>> from Numeric import * > >>> sqrt(4l) > Traceback (innermost last): > File "", line 1, in ? > AttributeError: attribute-less object That's life... Well seriously, what do you expect to happen here? Taking the sqrt of a long int is a fairly involved process, and I'd hate to be the one who had to write the code to find the sin of one. If a python object has a __sqrt__ method, then the sqrt function will work properly on it. Since long ints don't export any such methods there's not really any good options. Sorry. > >>> 4/arange(1,3) > 4 2 > >>> 4l/arange(1,3) > Segmentation fault > > ...Later > > >>> from Numeric import * > >>> 4l*arange(1,3) > Segmentation fault These are very strange, and don't happen to me on either solaris of NT with alpha2. Please test them out again with alpha2 on your system and if the problem persists we might have to track it down together. BTW - what system are you working on? -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Fri Aug 16 18:28:05 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Fri, 16 Aug 1996 13:28:05 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <32149BBA.14D2@mit.edu> (message from Jim Hugunin on Fri, 16 Aug 1996 12:03:06 -0400) Message-ID: <199608161728.NAA19827@cyclone.ERE.UMontreal.CA> > After reading all of the discussion over what are the appropriate axes > for the various operations, I've become convinced that there is no > obvious choice. Therefore I think it is really important to have a > single default axis so that at least people will only have one rule to > remember. I'd rather remember a more complicated rule than type explicit axis specifications for almost every function! > Because I can't possibly conceive of doing "fft" and its ilk with a > default axis other than -1, every function in NumPy will have a default > axis of -1 (or -2 for matrix operations). This currently includes all Could it be that you have a special bias for FFT? I don't consider FFTs so fundamental that they should set the default for all array functions. Statistically most functions would best have a default of 0, those that should have another default are the exceptions. > I wish I could come up with a better compromise, but I myself was > finding it hard to remember what the default axes were for different > operations, and that's just intolerable. Using -1 for everything is more intolerable than anything else. A quick glance at my existing code shows that I would need an explicit axis specifications for 80% of my function calls! Actually the default axis discussion has a long history in the APL community. The original APL allowed axis specifications in the same style as Python now does. The default axis was always zero, but for reduce and accuulate an alternate form with a default of -1 was provided. The various problems with this approach (and other limitations in APL) led to the rank concept in J. For most applications there is not much difference between function ranks and axis specifications, since the effect for simple arrays is rather similar. But J also gave up the "the same default for everyone" rule. However, it is possible to inquire about the default rank of any J function, which helps to reduce confusion and bad memory problems ;-) > I will add keyword arguments to all of the functions that accept an axis > so that you can at least write concatenate([a,b], axis=0) which I think > is much more readable than the non-keyword alternative. Definitely. But what happens to dot(), which needs two axes? Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 16 18:50:43 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 16 Aug 1996 13:50:43 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 References: <199608161728.NAA19827@cyclone.ERE.UMontreal.CA> Message-ID: <3214B4F3.2AC1@mit.edu> Konrad HINSEN wrote: > > Because I can't possibly conceive of doing "fft" and its ilk with a > > default axis other than -1, every function in NumPy will have a default > > axis of -1 (or -2 for matrix operations). This currently includes all > > Could it be that you have a special bias for FFT? I don't consider > FFTs so fundamental that they should set the default for all > array functions. Statistically most functions would best have > a default of 0, those that should have another default are the > exceptions. I don't have a particular bias towards fft, but I do have one towards the huge collection of non-strctural numeric operations that have the same properties. Things like histogram, spline, sort, argmax, etc. > > I wish I could come up with a better compromise, but I myself was > > finding it hard to remember what the default axes were for different > > operations, and that's just intolerable. > > Using -1 for everything is more intolerable than anything else. > A quick glance at my existing code shows that I would need > an explicit axis specifications for 80% of my function calls! If this really troubles you, write: def take(a, axis=0): Numeric.take(a, axis) at the start of your modules (though not at the start of modules that you want me to be able to read). > Actually the default axis discussion has a long history in the APL > community. The original APL allowed axis specifications in the same > style as Python now does. The default axis was always zero, but for > reduce and accuulate an alternate form with a default of -1 was > provided. The various problems with this approach (and other > limitations in APL) led to the rank concept in J. For most > applications there is not much difference between function ranks and > axis specifications, since the effect for simple arrays is rather > similar. But J also gave up the "the same default for everyone" > rule. However, it is possible to inquire about the default rank > of any J function, which helps to reduce confusion and bad memory > problems ;-) And one of my greatest complaints with J is similar to the complaints you are always hearing about perl, it makes for very concise but hard to read code. Python has always made the tradeoff for greater readability over less typing where the question has come up. I really think that I'm following in that tradition here. > > I will add keyword arguments to all of the functions that accept an axis > > so that you can at least write concatenate([a,b], axis=0) which I think > > is much more readable than the non-keyword alternative. > > Definitely. But what happens to dot(), which needs two axes? Probably gets axis=(axis1, axis2), but I'm not overly concerned about dot at this point. Right now, and probably until after the 1.0 release dot does not allow non default axis specification. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Fri Aug 16 18:59:13 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Fri, 16 Aug 1996 13:59:13 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <3214B4F3.2AC1@mit.edu> (message from Jim Hugunin on Fri, 16 Aug 1996 13:50:43 -0400) Message-ID: <199608161759.NAA22334@cyclone.ERE.UMontreal.CA> > I don't have a particular bias towards fft, but I do have one towards > the huge collection of non-strctural numeric operations that have the > same properties. Things like histogram, spline, sort, argmax, etc. That may be a long list, but how often are they applied to arrays of rank higher than 1? In other words, how frequently would one have to override a default of zero? If we settle for a single default for every function (which I still consider a bad solution), the best test would be to write a lot of code with explicit axis specifications for everything and then count which one occurs most often. I bet that is going to be zero. > If this really troubles you, write: > > def take(a, axis=0): Numeric.take(a, axis) > > at the start of your modules (though not at the start of modules that > you want me to be able to read). That's the point, we don't want to create dialects. The problem is that *I* don't want to read code that is compatible with a general default of -1. > And one of my greatest complaints with J is similar to the complaints > you are always hearing about perl, it makes for very concise but hard to > read code. Python has always made the tradeoff for greater readability But for different reasons. BTW, I don't particularly like J either; I can never remember all the funny symbols after not using them for two days. But I never had problems with remembering the default ranks, because in almost all cases you can deduce them by considering the most typical application of a function. Basically, the default should be zero for structural operations, -1 for non-structural operations acting on vectors, and -2 for non-structural operations acting on matrices (e.g. inversion). I don't think this is difficult to remember, and I can't think of a function for which the answer according to this rule is not obvious. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 16 19:18:08 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 16 Aug 1996 14:18:08 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 References: <199608161759.NAA22334@cyclone.ERE.UMontreal.CA> Message-ID: <3214BB60.352D@mit.edu> Konrad HINSEN wrote: > If we settle for a single default for every function (which I still > consider a bad solution), the best test would be to write a lot > of code with explicit axis specifications for everything and then > count which one occurs most often. I bet that is going to be zero. I happen to disagree with you about what such a comparision would reveal, but I could see the value in performing it. > > And one of my greatest complaints with J is similar to the complaints > > you are always hearing about perl, it makes for very concise but hard to > > read code. Python has always made the tradeoff for greater readability > > But for different reasons. BTW, I don't particularly like J either; > I can never remember all the funny symbols after not using them for > two days. But I never had problems with remembering the default ranks, > because in almost all cases you can deduce them by considering the > most typical application of a function. Basically, the default > should be zero for structural operations, -1 for non-structural > operations acting on vectors, and -2 for non-structural operations > acting on matrices (e.g. inversion). I don't think this is difficult > to remember, and I can't think of a function for which the answer > according to this rule is not obvious. Okay, here's an example of my problems: argmax(x) has a natural default axis of -1, right? So, what is the natural default axis of maximum.reduce(x)? If it's not also -1, I'd argue that you have a confusing situation. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Fri Aug 16 19:25:59 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Fri, 16 Aug 1996 14:25:59 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <3214BB60.352D@mit.edu> (message from Jim Hugunin on Fri, 16 Aug 1996 14:18:08 -0400) Message-ID: <199608161825.OAA24108@cyclone.ERE.UMontreal.CA> > > If we settle for a single default for every function (which I still > > consider a bad solution), the best test would be to write a lot > > of code with explicit axis specifications for everything and then > > count which one occurs most often. I bet that is going to be zero. > > I happen to disagree with you about what such a comparision would > reveal, but I could see the value in performing it. That's why I looked at all my code, and found that with a default of -1 I'd have to add axis specifications to 80% of all function calls. With a default of 0 I couldn't find any code that would need modification. I don't claim that my code is representative, but I want to see the code that benefits from a default of -1 before I believe in its existence. > Okay, here's an example of my problems: > > argmax(x) has a natural default axis of -1, right? > > So, what is the natural default axis of maximum.reduce(x)? If it's not > also -1, I'd argue that you have a confusing situation. Why? argmax() and maximum.reduce() are two very different things. Any reduction is a structural operation with a default of zero. argmax() is not a reduction, and also returns very different information (an index rather than an array element). Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Fri Aug 16 19:36:25 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Fri, 16 Aug 1996 20:36:25 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] Another problem? In-Reply-To: <32149061.45BC@mit.edu> References: <199608161014.MAA19954@nu> <32149061.45BC@mit.edu> Message-ID: <199608161836.UAA20142@nu> >>>>> "JH" == Jim Hugunin writes: JH> Rob.Hooft@embl-heidelberg.de wrote: >> factor took 10.577 seconds >> afactor took 7.916 seconds JH> I'm running on a faster machine than you, so my numbers are JH> faster in both cases, still the relative comparision is valid. JH> factor took 2.708 seconds JH> afactor took 0.322 seconds Your machine isn't much faster, it is the python virtual machine that is much faster :-\. With your version on my box: factor took 10.327 seconds afactor took 0.475 seconds see? I'm running on a 150MHz alpha here, so speed isn't that bad, it is just that python is juggling 64bit entities everywhere.... JH> Here's my new version of your afactor and asieve functions. JH> #Set multiples of i to be nonprime JH> numbers[(i*i)::i] = 0 Right. That is the key. I've been wondering how to do that without realizing that slices like this are incredibly powerful. BUT: there is a bug in your script: try running it with upto=999999 IndexError: invalid slice :-) If the bug is fixed, the behaviour is almost o(N). BTW: I'm running on an ALPHA, and I also get a crash when combining arrays with long integers. "gdb" tells me we're somewhere in "PyObject_Str".... Rob. -- === Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ == ==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/ Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ==== == PGPid 0xFA19277D == Use Linux! Free Software Rules The World! ============= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Carlos Fonseca Fri Aug 16 19:31:16 1996 From: Carlos Fonseca (Carlos Fonseca) Date: Fri, 16 Aug 1996 19:31:16 +0100 (BST) Subject: [PYTHON MATRIX-SIG] default axes In-Reply-To: <199608160936.FAA20848@cyclone.ERE.UMontreal.CA> Message-ID: On Fri, 16 Aug 1996, Konrad HINSEN wrote: > > I really think dot(a,b) should behave _exactly_ like > > > > add.reduce(a*b,axis=-1) > > Why? Perhaps I should have put it a different way: I would like the functionality of add.reduce(a*b,axis=-1), but without the need to allocate memory to store a*b, to be available. Why, because it appears to be as simple and general as it can get. I also thought that the name dot() would fit this description, but looking at the definition of dot() in Numeric.py, perhaps this functionality should simply be provided by multiarray.innerproduct() > > Full rank multiplication of two arrays could be written: > > > > dot(a[...,(n-1)*(NewAxis,)],b,axes=-n) [ actually, it should be dot(a[(Ellipses,)+(n-1)*(NewAxis,)],b,axes=-n) ] > > That is a lot too complicated for a frequent operation, especially > considering that n might not be available as a variable or constant, > i.e. it would have to be written as shape(b)[0]. I agree, and this is why I wrote further down in the same post that I agreed with the idea of writing two functions. innerproduct(a,b,axis) as add.reduce(a*b,axis) provides all the functionality that is needed to write dot() for general matrix multiplication. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Fri Aug 16 20:57:47 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Fri, 16 Aug 1996 21:57:47 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] Another problem? In-Reply-To: <32149061.45BC@mit.edu> References: <199608161014.MAA19954@nu> <32149061.45BC@mit.edu> Message-ID: <199608161957.VAA21810@nu> >>>>> "JH" == Jim Hugunin writes: JH> I doubt that my new version is more than a factor of 2 slower JH> than a C implementation of the same algorithm (though feel free JH> to show me wrong with a code sample). I decided to accept that challenge: nu[263]~% cc -O4 -o x x.c -lm -non_shared nu[264]~% time ./x Can divide by 2 Can divide by 29 ./x 0.03s user 0.02s system 83% cpu 0.060 total Remember: nu[265]~% python ./x.py Can divide by 2 Can divide by 29 factor took 10.354 seconds Can divide by 2 Can divide by 29 afactor took 0.573 seconds and, yes the machine is "empty", so clock-times are comparable. And: changing the array to type='b' makes the python version slower, so I'm not being unfair.... The only trick I've added is making the thing non-recursive, but I doubt that change would make the python version much faster. nu[266]~% python Python 1.4b2 (Aug 12 1996) [C] Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam >>> 0.573/0.060 > 2.0 1 >>> ----------------------------------- #include #include #include #define bool char int *sieve(int max) { bool *sieve; int *result; int i,j,limit; sieve=(bool *)malloc((max+1)*sizeof(bool)); for (i=0;i<=max;i++) sieve[i]=1; sieve[0]=0; sieve[1]=0; limit=floor(sqrt((float)max)); for (i=2;i<=limit;i++) { if (sieve[i]) { for (j=i*i;j<=max;j+=i) sieve[j]=0; } } j=0; for (i=2;i<=max;i++) j+=sieve[i]; /*printf("Sieve contains %d primes\n",j);*/ result=(int *)malloc((j+1)*sizeof(int)); j=0; for (i=2;i<=max;i++) if (sieve[i]) result[j++]=i; result[j]=0; free(sieve); return(result); } void factor(int a,int max) { int *s; int i; if (max<2) return; s=sieve(max); for (i=0;s[i];i++) { if (!(a%s[i])) { printf("Can divide by %d\n",s[i]); } } free(s); } int main() { factor(129753308,99999); exit(0); } ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From mclay@eeel.nist.gov Fri Aug 16 15:57:25 1996 From: mclay@eeel.nist.gov (Michael McLay) Date: Fri, 16 Aug 96 14:57:25 GMT Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <199608161728.NAA19827@cyclone.ERE.UMontreal.CA> References: <32149BBA.14D2@mit.edu> <199608161728.NAA19827@cyclone.ERE.UMontreal.CA> Message-ID: <199608161653.QAA15807@fermi.eeel.nist.gov> Konrad HINSEN writes: > > After reading all of the discussion over what are the appropriate axes > > for the various operations, I've become convinced that there is no > > obvious choice. Therefore I think it is really important to have a > > single default axis so that at least people will only have one rule to > > remember. > > I'd rather remember a more complicated rule than type explicit axis > specifications for almost every function! > > > Because I can't possibly conceive of doing "fft" and its ilk with a > > default axis other than -1, every function in NumPy will have a default > > axis of -1 (or -2 for matrix operations). This currently includes all > > Could it be that you have a special bias for FFT? I don't consider > FFTs so fundamental that they should set the default for all > array functions. Statistically most functions would best have > a default of 0, those that should have another default are the > exceptions. Let me qualify this by saying I'm not entirely sure I understand the definition of axis. I guess that qualifies me as a novice user. For a novice user making the default -1 would not be as intuitive as making it 0. Also, since Konrad seems to think that the majority of functions would use 0 as the default, then perhaps that should be the default value. I still favor keeping the rule simple and requiring an explicit value for changing axis to something other than the default. I suppose asking you to change the default to something other than what you use the most would be a good test of the irritation factor of having to always specify the axis. If you are not willing to type axis=-1 in every function, then perhaps keeping a simple rule is not the correct tradeoff. Michael ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Sat Aug 17 00:10:09 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 16 Aug 1996 19:10:09 -0400 Subject: [PYTHON MATRIX-SIG] Release 1.0alpha2 available Message-ID: <3214FFD1.7714@mit.edu> NumPy-1.0a2 is now available at the usual location: ftp://ftp.sls.lcs.mit.edu/pub/jjh/NumPy-1.0a2.tar.gz I've removed the fftmodule for this iteration while I work out the best way to handle the standard library. This version contains many small bug fixes, a large number of name changes and a new standard for default axes. Axis 0 is now always the default axis. This is the one feature in alpha2 that I think has a reasonable chance of changing incompatibly before the beta1 release. There is also a script fixnames.py that can be used to fix names from the 1.0a1 conventions to 1.0a2. Read INSTALL for more information on this. Please do try the dynamic installation thing again and let me know your successes and failures on different platforms. As usual, have fun and let me know how it goes - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Sat Aug 17 21:04:47 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Sat, 17 Aug 1996 21:04:47 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <199608161759.NAA22334@cyclone.ERE.UMontreal.CA> Message-ID: On Fri, 16 Aug 1996, Konrad HINSEN wrote: > > I don't have a particular bias towards fft, but I do have one towards > > the huge collection of non-strctural numeric operations that have the > > same properties. Things like histogram, spline, sort, argmax, etc. > > That may be a long list, but how often are they applied to arrays > of rank higher than 1? In other words, how frequently would one > have to override a default of zero? Everytime one wanted to evaluate the fft (or whatever) of multiple one-dimensional signals at once. In genetic algorithms (GAs, what I would like to write code for), individuals can all be evaluated independently from each other, which is ideal for vectorized operations. If assessing each individual involves computing the fft of a different 1d signal, then axis=-1. If one can say that individuals (in GAs, that is) will mostly be described by 1d (vector of decision variables, vector of objective values, etc) or 2d structures (a covariance matrix, a 2d pattern), and that outer dimensions will be used to structure the population, since most computations will be local to the individual itself, -1 and -2 will definetely be the most common choices for axes. I am still new to Python (but experieced with MATLAB), and I've only written a couple of functions so far. But the answer to your question is "very often", in my case... > most typical application of a function. Basically, the default > should be zero for structural operations, -1 for non-structural > operations acting on vectors, and -2 for non-structural operations > acting on matrices (e.g. inversion). I don't think this is difficult > to remember, and I can't think of a function for which the answer > according to this rule is not obvious. > > Konrad. I am afraid I do not understand what you mean by structural and non-structural operations. In particular, why is take() structural and argsort() non-structural? For take(a,argsort(a)) to make sense, both should have the same defaults, whatever the dimensions of a. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Sat Aug 17 20:07:10 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Sat, 17 Aug 1996 20:07:10 +0100 (BST) Subject: [PYTHON MATRIX-SIG] take() in 1.0a2 (longish, sorry) Message-ID: Hi, I don't know if the following is intentional or not: >>> from Numeric import * >>> a=array([[2,3,7,6,4,7],[6,9,6,4,3,2]]) >>> a 2 3 7 6 4 7 6 9 6 4 3 2 >>> sort(a,-1) 2 3 4 6 7 7 2 3 4 6 6 9 >>> argsort(a,-1) 0 1 4 3 2 5 5 4 3 0 2 1 >>> take(a,argsort(a,-1),-1) 2 3 4 6 7 7 7 4 6 2 7 3 6 9 3 4 6 2 2 3 4 6 6 9 >>> I.e., when take is given a 2 dimensional indices array, it adds yet another dimension to a. This should not happen if take(a,argsort(a,-1),-1) is to be equivalent to sort(a,-1). Note that, in the example above, indices is perfectly aligned with a. In general, if b=take(a,indices,axis) then b[i,...,j,...,k]=a[i,...,indices[i,...,j,...,k],...,k] ^ axis with broadcasting of dimensions for all axes other than the "active" axis. Since a and indices would normally be aligned at the last dimension, at least the following should be true: a 2 3 7 6 4 7 6 9 5 4 3 2 take(a,[1,0,1],-1) # select columns 3 2 3 9 6 9 take(a,[1,0,1],-2) Arrays not aligned! take(a,[[1],[0],[1]],-1) Arrays not aligned! take(a,[[1],[0],[1]],-2) # select rows 6 9 5 4 3 2 2 3 7 6 4 7 6 9 5 4 3 2 As for the default axes, oh well... :-) Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Sat Aug 17 20:15:57 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Sat, 17 Aug 1996 20:15:57 +0100 (BST) Subject: [PYTHON MATRIX-SIG] sum() in 1.0a2 Message-ID: I think sum(a) (and other reductions) should return an array with shape () when a is 1d, and not a scalar. Currently, sum(a).anyarraymethod and sum(a)[0] will fail if a is 1d. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Sun Aug 18 02:03:04 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Sun, 18 Aug 1996 03:03:04 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] argsort() on array([1,1],'b') Message-ID: <199608180103.DAA26454@nu> I guess you don't want to know that this happened while I was trying to improve on Jim's last version of sieve? This happens on a Linux box (1.0a2) as well as on an ALPHA (1.0a1). amigo[639]test% python Python 1.4b2 (Aug 7 1996) [GCC 2.7.2p snapshot 960426] Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam >>> >>> from Numeric import * >>> argsort([0,1]) 0 1 >>> a=array([0,1],'b') >>> argsort(a) zsh: segmentation fault python Rob. ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Sun Aug 18 08:59:11 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Sun, 18 Aug 1996 09:59:11 +0200 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: (message from Carlos Fonseca on Sat, 17 Aug 1996 21:04:47 +0100 (BST)) Message-ID: <9608180759.AA16966@acds21> Everytime one wanted to evaluate the fft (or whatever) of multiple one-dimensional signals at once. In genetic algorithms (GAs, what I would Obviously, but how often does this occur? (Of course I am not asking how often such code gets executed, but how often you have to type such a function call.) In all of my array code, which is not just Python code but also a few MB of APL code, such applications are extremely rare. Even if such an operation is central to GA applications, that doesn't mean that the majority of array functions in a complete program (i.e. including setup or reading of input arrays, analysis, output formatting, etc.) would benefit from a default axis of -1. But of course you can convince me that I am wrong by sending me a few complete programs that do something useful and that need an axis specification of -1 in the majority of axis-related operations. I am afraid I do not understand what you mean by structural and non-structural operations. In particular, why is take() structural and argsort() non-structural? For take(a,argsort(a)) to make sense, both should have the same defaults, whatever the dimensions of a. Basically a structural operation is one that acts on or modifies the shape of an array, as opposed to a non-structural operation that cares mostly about the values of the array elements. take() is clearly structural (it doesn't care at all about the values of array elements), whereas argsort is not (the values matter a lot, and intrinsically it can't deal with higher-rank arrays). And I am sure that for most applications of take() a default axis of 0 is appropriate, whereas most applications of argsort() would benefit from -1. Of course that means that take(a,argsort(a)) doesn't do anything useful. But in what situation would you use it anyway? To sort the 1D subarrays of a, you would write sort(a) (which being non-structural should have a default axis of -1). Using take() makes sense e.g. if you only want a subset of the elements, but I can't believe that this is a frequent operation. Besides, my APL experience tells me that argsort() is never used on anything but a rank-1 array. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Sun Aug 18 09:10:59 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Sun, 18 Aug 1996 10:10:59 +0200 Subject: [PYTHON MATRIX-SIG] take() in 1.0a2 (longish, sorry) In-Reply-To: (message from Carlos Fonseca on Sat, 17 Aug 1996 20:07:10 +0100 (BST)) Message-ID: <9608180810.AA16974@acds21> I.e., when take is given a 2 dimensional indices array, it adds yet another dimension to a. This should not happen if take(a,argsort(a,-1),-1) I hope that this intentional, since it is a very useful function for the construction of higher-rank arrays. is to be equivalent to sort(a,-1). Note that, in the example above, If sort(a,-1) is what you want, then that is what you should write. take() is meant for different (and much more diverse) applications, and I don't see a reason to limit its flexibility just to create a less efficient synonym for sort(). My definition for take(), using the convenient J concepts of frames and cells, would be: the result has the frames of the index argument with elements picked from the value argument, i.e. if b = take(a, i, axis) then b[n_1,..,n_k] = a[(axis-1)*(All,), i[n_1,..,n_k], ...] with k being the rank of i. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@physik.rwth-aachen.de Sun Aug 18 09:18:05 1996 From: hinsen@physik.rwth-aachen.de (Konrad Hinsen) Date: Sun, 18 Aug 1996 10:18:05 +0200 Subject: [PYTHON MATRIX-SIG] sum() in 1.0a2 In-Reply-To: (message from Carlos Fonseca on Sat, 17 Aug 1996 20:15:57 +0100 (BST)) Message-ID: <9608180818.AA16982@acds21> I think sum(a) (and other reductions) should return an array with shape () when a is 1d, and not a scalar. Currently, sum(a).anyarraymethod and sum(a)[0] will fail if a is 1d. Which is precisely why I have always insisted that array operations should be implemented as functions and not as methods. Of course the alternative would be to make rank-0 arrays distinct from scalars, and this alternative has been discussed a lot in the early days of the Matrix SIG. But it creates a few fundamental problems. Everyones idea of arrays is that they are collections of scalars, and one expects to be able to pick the scalars from an array by indexing. But if rank-0 arrays are distinct from scalars, indexing a rank-1 array would return a rank-0 array. Worse, there would be no obvious way to extract a real scalar from a rank-0 array, so another conversion function would be necessary. The resulting system would be extremely confusing to users. Not having specific rank-0 objects is therefore the lesser evil, but then we have to live with the implementation limitations given by the Python interpreter. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de Chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. A | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Sun Aug 18 16:10:52 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Sun, 18 Aug 1996 16:10:52 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <9608180759.AA16966@acds21> Message-ID: On Sun, 18 Aug 1996, Konrad Hinsen wrote: > Obviously, but how often does this occur? (Of course I am not > asking how often such code gets executed, but how often you have to > type such a function call.) In all of my array code, which is not > just Python code but also a few MB of APL code, such applications > are extremely rare. Even if such an operation is central to GA > applications, that doesn't mean that the majority of array functions > in a complete program (i.e. including setup or reading of input > arrays, analysis, output formatting, etc.) would benefit from a > default axis of -1. In wanting to write generic GA code, where the structures that characterize the individual typically have known dimensions (fitness is a scalar, performance is at most a vector (in multiobjective optimization), but the structure of the population is a decision of who actually puts the GA together, the code must be written relative the last dimension of the array. Thus, -1 are -2 the axes that end up making sense. If the population was assumed to be unstructured, then one of these would equivalent to 0, but not in general. > But of course you can convince me that I am wrong by sending me a few > complete programs that do something useful and that need an axis > specification of -1 in the majority of axis-related operations. Not having a working take() (see one of my earlier messages) hasn't helped :-( > [explation of structural vs. non-structural] > > Of course that means that take(a,argsort(a)) doesn't do anything > useful. But in what situation would you use it anyway? To sort the 1D > subarrays of a, you would write sort(a) (which being non-structural > should have a default axis of -1). But suppose I have to arrays, a and b, both aligned and three dimensional, and that there is a ono to one correspondence between the elements of a and those of b. I need to sort a and, at the same time, rearrange b so that the original relationship is retained: ix=argsort(a) A=take(a,ix) B=take(b,ix) This should be enough. > Using take() makes sense e.g. if > you only want a subset of the elements, but I can't believe that this > is a frequent operation. This is called "selection" (one of the 3 main operators) operators. > Besides, my APL experience tells me that > argsort() is never used on anything but a rank-1 array. > > Konrad. > My experience is different. But Matlab doesn't let me write something like the above even for 2d arrays, so I end up using a for-loop. Something else: How can I achieve rank = argsort(argsort(cost)) without having to call argsort twice? Something like an inverted take (ekat below :-) rank = ekat(arange(n),argsort(cost)) would be ideal. This would be like take, but "indices" would refer to the output matrix, and not to the input. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Sun Aug 18 16:27:49 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Sun, 18 Aug 1996 11:27:49 -0400 Subject: [PYTHON MATRIX-SIG] sum() in 1.0a2 References: Message-ID: <32173675.531E@mit.edu> Carlos Fonseca wrote: > > I think sum(a) (and other reductions) should return an array with shape () > when a is 1d, and not a scalar. Currently, sum(a).anyarraymethod and > sum(a)[0] will fail if a is 1d. Sorry about this, but there has already been much discussion of this issue and the agreement was that array functions that returns 0d arrays should return python scalars. I agree that this can occasionally be confusing, but I think that our conclusion when we last discussed this was sound (look at the archives if you're feeling brave). -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Sun Aug 18 16:21:07 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Sun, 18 Aug 1996 16:21:07 +0100 (BST) Subject: [PYTHON MATRIX-SIG] take() in 1.0a2 (longish, sorry) In-Reply-To: <9608180810.AA16974@acds21> Message-ID: On Sun, 18 Aug 1996, Konrad Hinsen wrote: > I.e., when take is given a 2 dimensional indices array, it adds yet > another dimension to a. This should not happen if take(a,argsort(a,-1),-1) > > I hope that this intentional, since it is a very useful function > for the construction of higher-rank arrays. But the point is that higher-rank arrays can be easily and efficiently constructed by adding dummy dimensions and relying on broadcasting, whereas the reverse is not possible if functions insist on producing higher-rank arrays. At least, it means that more memory must be allocated before the higher-rank arrays can be indexed at all. > is to be equivalent to sort(a,-1). Note that, in the example above, > > If sort(a,-1) is what you want, then that is what you should write. > take() is meant for different (and much more diverse) applications, > and I don't see a reason to limit its flexibility just to create > a less efficient synonym for sort(). I have answered this in my previous message. Also, see above. > My definition for take(), using the convenient J concepts of > frames and cells, would be: the result has the frames of the > index argument with elements picked from the value argument, > i.e. if > b = take(a, i, axis) > then > b[n_1,..,n_k] = a[(axis-1)*(All,), i[n_1,..,n_k], ...] > with k being the rank of i. > > Konrad. This behaviour can be achieved efficiently with the definition I proposed via broadcasting. The opposite behaviour can only be achived from this one, if at all, via indexing. Meanwhile, lots of memory have already had to be allocated. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Carlos Fonseca Sun Aug 18 15:40:54 1996 From: Carlos Fonseca (Carlos Fonseca) Date: Sun, 18 Aug 1996 15:40:54 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Re: sum() in 1.0a2 + indexing BUG In-Reply-To: <9608180818.AA16982@acds21> Message-ID: First, the bug: >>> from Numeric import * >>> array(0)[0:] On Sun, 18 Aug 1996, Konrad Hinsen wrote: > > I think sum(a) (and other reductions) should return an array with shape () > when a is 1d, and not a scalar. Currently, sum(a).anyarraymethod and > sum(a)[0] will fail if a is 1d. > > Which is precisely why I have always insisted that array operations > should be implemented as functions and not as methods. > > Of course the alternative would be to make rank-0 arrays distinct from > scalars, and this alternative has been discussed a lot in the early > days of the Matrix SIG. But it creates a few fundamental > problems. Everyones idea of arrays is that they are collections of > scalars, and one expects to be able to pick the scalars from an array > by indexing. But if rank-0 arrays are distinct from scalars, > indexing a rank-1 array would return a rank-0 array. Worse, there > would be no obvious way to extract a real scalar from a rank-0 > array, so another conversion function would be necessary. The > resulting system would be extremely confusing to users. My message referred to reductions, not to indexing. Indexing could still return scalars, where appropriate. I understand that indexing with scalars (but not with slices!) could be seen as a reduction, and thus made to return a null-shape array, leading to the situation you describe. Perhaps indexing into a null-shape array could return the scalar? This works in the present implementation. But see below... > Not having specific rank-0 objects is therefore the lesser evil, > but then we have to live with the implementation limitations > given by the Python interpreter. > > Konrad. > But we *do* have them: >>> from Numeric import * >>> a=array(5) >>> a.shape () >>> a[0] 5 It is fair to expect the array constructor to return an array. Perhaps it should return one with shape (1,)? But then, what about array([5])? Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Sun Aug 18 17:23:11 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Sun, 18 Aug 1996 18:23:11 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] arange(with one integer parameter) Message-ID: <199608181623.SAA17078@nu> I had yet another look at the sieve script. With the help of Jim's time() calls, I saw that a lot of time was spent in the statement "arange(max)". Looking at the definition this is not surprising: the code is so general that the easy cases like this suffer immensely. On my machine, add.accumulate(1+zeros([1000000]))-1 (4 operations on the whole array, but I think the most efficient we can do at this moment since these are implemented in C) is two times faster than arange(1000000) Maybe arange, or this special case of arange with one parameter, deserve to be implemented in C? This form is called quite often, even in Numeric.py! Rob. -- === Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ == ==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/ Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ==== == PGPid 0xFA19277D == Use Linux! Free Software Rules The World! ============= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Sun Aug 18 17:44:10 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Sun, 18 Aug 1996 12:44:10 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 References: Message-ID: <3217485A.4C27@mit.edu> Carlos Fonseca wrote: > > On Sun, 18 Aug 1996, Konrad Hinsen wrote: > > > Obviously, but how often does this occur? (Of course I am not ... > array. Thus, -1 are -2 the axes that end up making sense. > If the population was assumed to be unstructured, then one of these would > equivalent to 0, but not in general. I'm going to stay out of this discussion for now, but please continue! > > [explation of structural vs. non-structural] > > > > Of course that means that take(a,argsort(a)) doesn't do anything > > useful. But in what situation would you use it anyway? To sort the 1D > > subarrays of a, you would write sort(a) (which being non-structural > > should have a default axis of -1). > > But suppose I have to arrays, a and b, both aligned and three dimensional, > and that there is a ono to one correspondence between the elements of a > and those of b. I need to sort a and, at the same time, rearrange b so > that the original relationship is retained: > > ix=argsort(a) > A=take(a,ix) > B=take(b,ix) > > This should be enough. You have a good point here, but I think that the issue is you want a different function from Konrad. Alright, writing functions is something I can do. What would you like it to be called? > My experience is different. But Matlab doesn't let me write something > like the above even for 2d arrays, so I end up using a for-loop. So at least we aren't in danger of having you defect back to matlab :) > Something else: > > How can I achieve > > rank = argsort(argsort(cost)) < > without having to call argsort twice? Something like an inverted take > (ekat below :-) I see what you're looking for here, but I'm not convinced that having to call argsort twice is enough of a burden to justify the function you're asking for. I'd either like to see more examples of how this would be useful, or have you wait and ask for this in version 1.1. > rank = ekat(arange(n),argsort(cost)) > > would be ideal. This would be like take, but "indices" would refer to the > output matrix, and not to the input. > > Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Carlos Fonseca Sun Aug 18 17:54:09 1996 From: Carlos Fonseca (Carlos Fonseca) Date: Sun, 18 Aug 1996 17:54:09 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Re: Array indexing bug + strange behaviour In-Reply-To: Message-ID: This bug is still in 1.0a2. This happens under Linux 2.0.12, gcc 2.7.2 (from the Debian distribution, which has the strength-reduce bug fixed). I've linked NumPy dynamically, but it also happens with NumPy statically linked. On Tue, 13 Aug 1996, Carlos Fonseca wrote: > This seems to be reproducible. Found it by chance... > > Python 1.4b2 (Aug 11 1996) [GCC 2.7.2] > Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam > >>> from Numeric import * > >>> a=arange(10) > >>> a[10:10].shape > (0,) > >>> a[-1:10].shape > IndexError: index out of bounds > >>> a[-1:10].shape > (1,) > >>> > > Carlos The only thing unusual with my setup is that I compiled the interpreter with -O4. If nobody else can reproduce this, I'll try recompiling it with a more conservative setting. The numeric modules themselves were compiled with -g (the default). The other bug reported by Jean-Bernard ADDOR is also there: >>> max(arange(5),3) 0 1 2 3 4 >>> min(arange(5),3) 3 Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Sun Aug 18 18:10:57 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Sun, 18 Aug 1996 13:10:57 -0400 Subject: [PYTHON MATRIX-SIG] Don't use max and min with Numeric Python! Message-ID: <32174EA1.5A19@mit.edu> Carlos Fonseca wrote: > The other bug reported by Jean-Bernard ADDOR is also there: > > >>> max(arange(5),3) > 0 1 2 3 4 > >>> min(arange(5),3) > 3 This is not a bug! This is an unfortunate design decision in the python interpreter, but there's nothing I can do about it. What you usually think of as max should be writen maximum under Numeric Python. I'm sure that this will trip up a lot of people, but I don't have a good solution to this until Guido adds the ability to use exceptions with comparision operations. I guess I could override these builtin functions if you do from Numeric import *, but that doesn't seem like good behavior. Repeat: use maximum and minimum instead of max and min with array objects. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Sun Aug 18 22:09:04 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Sun, 18 Aug 1996 22:09:04 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <3217485A.4C27@mit.edu> Message-ID: On Sun, 18 Aug 1996, Jim Hugunin wrote: > Carlos Fonseca wrote: > > > ix=argsort(a) > > A=take(a,ix) > > B=take(b,ix) > > > > This should be enough. > > You have a good point here, but I think that the issue is you want a > different function from Konrad. Alright, writing functions is something > I can do. What would you like it to be called? How do you feel about index(a,indices,axis). Alternatively, select(...) would also make sense, I think. Thanks for looking into this. > > My experience is different. But Matlab doesn't let me write something > > like the above even for 2d arrays, so I end up using a for-loop. > > So at least we aren't in danger of having you defect back to matlab :) :-) > > Something else: > > > > How can I achieve > > > > rank = argsort(argsort(cost)) > < > > without having to call argsort twice? Something like an inverted take > > (ekat below :-) > > I see what you're looking for here, but I'm not convinced that having to > call argsort twice is enough of a burden to justify the function you're > asking for. I'd either like to see more examples of how this would be > useful, or have you wait and ask for this in version 1.1. Plain indexing should always be more efficient than sorting, but this is certainly not a problem for me at the moment. I agree that there is more than enough to concentrate on until v1.0. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Mon Aug 19 14:38:35 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Mon, 19 Aug 1996 09:38:35 -0400 Subject: [PYTHON MATRIX-SIG] linear algebra Message-ID: <32186E5B.4BA8@mit.edu> I'm finally having some good success at putting together a standard library for NumPy. There will be easy to compile, small C versions of all the necessary Lapack and Blas routines available so that anybody with a C compiler can use the standard lib. Now I have a question for those people out there who use linear algebra more than I do. All of the current interface routines (from LinAlg.py) do the following: return transpose(lapackfunction(transpose(input_matrix))) Should these two transpositions be there? This is obviously related to the different index order between NumPy and FORTRAN. Still, I've always personally considered it a superficial difference that is best ignored. If I remember by Linear Algebra correctly transpose(inverse(transpose(m))) == inverse(m). However, I very rarely use any linear algebra functions in my code so I'm not the right person to be making that decision. Opinions? -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 17:16:52 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 12:16:52 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: (message from Carlos Fonseca on Sun, 18 Aug 1996 16:10:52 +0100 (BST)) Message-ID: <199608191616.MAA18876@cyclone.ERE.UMontreal.CA> > In wanting to write generic GA code, where the structures that > characterize the individual typically have known dimensions (fitness is a > scalar, performance is at most a vector (in multiobjective optimization), > but the structure of the population is a decision of who actually puts the > GA together, the code must be written relative the last dimension of the > array. Thus, -1 are -2 the axes that end up making sense. > If the population was assumed to be unstructured, then one of these would > equivalent to 0, but not in general. I readily believe that, but this is the same example that you have given before. My question was not about this one data object, but about the frequency of axes other than 0 in a complete program. I guess the only thing that will convince me is such a program... > But suppose I have to arrays, a and b, both aligned and three dimensional, > and that there is a ono to one correspondence between the elements of a > and those of b. I need to sort a and, at the same time, rearrange b so > that the original relationship is retained: > > ix=argsort(a) > A=take(a,ix) > B=take(b,ix) Well, in this case you would need an explicit axis specification. And I don't see what would be so bad about it. You can always come up with an example which shows than axis=n should be the default, probably for any n ;-) (the proof is left as an exercise for the reader). For deciding which is the best default argument for each function, I'd apply the following criteria: 1) What is the most common axis for each individual function? 2) How can the resulting list best be approximated by a sufficiently simple rule? > > Using take() makes sense e.g. if > > you only want a subset of the elements, but I can't believe that this > > is a frequent operation. > > This is called "selection" (one of the 3 main operators) operators. I am not sure what you are referring to. Is that a special term from GA applications? > My experience is different. But Matlab doesn't let me write something > like the above even for 2d arrays, so I end up using a for-loop. Which is terribly inefficient. I have long given up Matlab due to such limitations... > How can I achieve > > rank = argsort(argsort(cost)) > > without having to call argsort twice? Something like an inverted take > (ekat below :-) > > rank = ekat(arange(n),argsort(cost)) Unless your array is very big, this variant might actually be more expensive than the first one, because it involves three interpreted function calls. The best solution for such applications would be a special function that inverts a permutation (which is O(N), unlike sorting). Than you would write rank = inv_permutation(argsort(cost)) This function would potentially be more generally useful than your ekat(). Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 17:32:28 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 12:32:28 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: (message from Carlos Fonseca on Sun, 18 Aug 1996 22:09:04 +0100 (BST)) Message-ID: <199608191632.MAA20254@cyclone.ERE.UMontreal.CA> > On Sun, 18 Aug 1996, Jim Hugunin wrote: > > > Carlos Fonseca wrote: > > > > > ix=argsort(a) > > > A=take(a,ix) > > > B=take(b,ix) > > > > > > This should be enough. > > > > You have a good point here, but I think that the issue is you want a > > different function from Konrad. Alright, writing functions is something > > I can do. What would you like it to be called? > > How do you feel about index(a,indices,axis). Alternatively, select(...) > would also make sense, I think. Thanks for looking into this. Before we add functions that differ only in details, let's consider the APL approach to this kind of problem: concatenate the two arrays, sort the result, and split them again. How efficient would that be in Python? It mostly depends on the concatenation (which APL implementations treat with special care because it is extremely frequently used). Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 17:27:32 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 12:27:32 -0400 Subject: [PYTHON MATRIX-SIG] arange(with one integer parameter) In-Reply-To: <199608181623.SAA17078@nu> (Rob.Hooft@embl-heidelberg.de) Message-ID: <199608191627.MAA20040@cyclone.ERE.UMontreal.CA> > Maybe arange, or this special case of arange with one parameter, > deserve to be implemented in C? This form is called quite often, even > in Numeric.py! Definitely. Arange() is one of the most frequent array constructors. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 17:25:15 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 12:25:15 -0400 Subject: [PYTHON MATRIX-SIG] Re: sum() in 1.0a2 + indexing BUG In-Reply-To: (message from Carlos Fonseca on Sun, 18 Aug 1996 15:40:54 +0100 (BST)) Message-ID: <199608191625.MAA19687@cyclone.ERE.UMontreal.CA> > My message referred to reductions, not to indexing. Indexing could still > return scalars, where appropriate. But having indexing work differently from reduction only adds to the confusion. > to the situation you describe. Perhaps indexing into a null-shape array > could return the scalar? This works in the present implementation. But see Again this is hardly an obvious behaviour. The number of indices must always be equal to the rank of an array, so a rank-0 array needs exactly zero indices ;-) > But we *do* have them: > > >>> from Numeric import * > >>> a=array(5) > >>> a.shape > () > >>> a[0] > 5 > > It is fair to expect the array constructor to return an array. Perhaps > it should return one with shape (1,)? But then, what about array([5])? That is indeed a problem. You are right that the array constructor should return an array, but on the other hand there are no rank-0 arrays. Since we have decided not to have rank-0 array objects, I can think of two solutions: 1) Declare scalars to be special cases of arrays, and let the constructor return a scalar. 2) Raise an exception. I definitely favour the first, because I can imagine that array(x) with scalar x can occur as a special case of an application where x could be an arbitrary nested list. In that case returning a scalar would most probably work. On the other hand, I can't think of too many cases where one would type array(5) by mistake and not notice the error without an exception. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From paul@aem.umn.edu Mon Aug 19 17:41:32 1996 From: paul@aem.umn.edu (Ralph Paul) Date: Mon, 19 Aug 1996 11:41:32 -0500 Subject: [PYTHON MATRIX-SIG] linear algebra In-Reply-To: <32186E5B.4BA8@mit.edu> Message-ID: On Mon, 19 Aug 1996 09:38:35 -0400 owner-matrix-sig@python.org wrote: > Should these two transpositions be there? This is obviously related to > the different index order between NumPy and FORTRAN. Still, I've always > personally considered it a superficial difference that is best ignored. > > If I remember by Linear Algebra correctly > transpose(inverse(transpose(m))) == inverse(m). > > However, I very rarely use any linear algebra functions in my code so > I'm not the right person to be making that decision. Opinions? Hi, I would like to comment on that. It probably does not make a big difference if stick with limited matrix- vector operations like : b=A*x <=> b=x'*A' but if go one level lower I think it gets quite annoying to have to switch your indexing around. Just to throw in a suggestion let me tell what the Ada95 standard does to work around this problem. In Ada95 the compiler has to have a " pragma Convention (Fortran, Fortran_Matrix);" which changes the way an array is actually stored in memory. For the programmer there is no change at all, the compiler takes care of all necessary changes to make the array Fortran as well as Ada compatible. Would this be possible in python without a serious perfomance overhead ? Ralph Paul paul@aem.umn.edu or ralph@ifr.luftahrt.uni-stuttgart.de ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 17:42:04 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 12:42:04 -0400 Subject: [PYTHON MATRIX-SIG] linear algebra In-Reply-To: <32186E5B.4BA8@mit.edu> (message from Jim Hugunin on Mon, 19 Aug 1996 09:38:35 -0400) Message-ID: <199608191642.MAA24938@cyclone.ERE.UMontreal.CA> > All of the current interface routines (from LinAlg.py) do the following: > > return transpose(lapackfunction(transpose(input_matrix))) > > Should these two transpositions be there? This is obviously related to > the different index order between NumPy and FORTRAN. Still, I've always > personally considered it a superficial difference that is best ignored. > > If I remember by Linear Algebra correctly > transpose(inverse(transpose(m))) == inverse(m). True for inversion, but for little else, except in the special case of symmetric matrices. Personally I think it is important to work with the "right" index order that everyone is used to. Python users should not have to know anything about implementation details. Besides, if I understand everything correctly, transposition should cost almost nothing, right? Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Mon Aug 19 17:46:30 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Mon, 19 Aug 1996 12:46:30 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 References: <199608191632.MAA20254@cyclone.ERE.UMontreal.CA> Message-ID: <32189A66.34E5@mit.edu> Konrad HINSEN wrote: > > > On Sun, 18 Aug 1996, Jim Hugunin wrote: > > > > > Carlos Fonseca wrote: > > > > > > > ix=argsort(a) > > > > A=take(a,ix) > > > > B=take(b,ix) > > > > > > > > This should be enough. > > > > > > You have a good point here, but I think that the issue is you want a > > > different function from Konrad. Alright, writing functions is something > > > I can do. What would you like it to be called? > > > > How do you feel about index(a,indices,axis). Alternatively, select(...) > > would also make sense, I think. Thanks for looking into this. > > Before we add functions that differ only in details, let's consider > the APL approach to this kind of problem: concatenate the two arrays, > sort the result, and split them again. How efficient would that > be in Python? It mostly depends on the concatenation (which APL > implementations treat with special care because it is extremely > frequently used). Concatenation is reasonably efficient. It could be better, but I'm holding off on any non-trivial efficiency improvements until after release 1.0. Right now I think a solid, stable and reasonably complete implementation is much more important. I don't see any good way to solve Carlos's problem using concatenation (without including arbitrary comparision functions for sort which I don't want to do). How would you reccommend he gets the equivalent of: ix=argsort(a) A=take(a,ix) B=take(b,ix) for > 1d arrays without some take-like function? -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Mon Aug 19 17:50:14 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Mon, 19 Aug 1996 12:50:14 -0400 Subject: [PYTHON MATRIX-SIG] linear algebra References: <199608191642.MAA24938@cyclone.ERE.UMontreal.CA> Message-ID: <32189B46.114C@mit.edu> Konrad HINSEN wrote: > > > All of the current interface routines (from LinAlg.py) do the following: > > > > return transpose(lapackfunction(transpose(input_matrix))) > > > > Should these two transpositions be there? This is obviously related to > > the different index order between NumPy and FORTRAN. Still, I've always > > personally considered it a superficial difference that is best ignored. > > > > If I remember by Linear Algebra correctly > > transpose(inverse(transpose(m))) == inverse(m). > > True for inversion, but for little else, except in the special case of > symmetric matrices. > > Personally I think it is important to work with the "right" index > order that everyone is used to. Python users should not have to know > anything about implementation details. > > Besides, if I understand everything correctly, transposition should > cost almost nothing, right? Transposition costs almost nothing. Transposition followed by a copy is O(n). These FORTRAN routines expect contiguous arrays, which requires the transposed array to be copied before calling them. Therefore this is a non-trivial amount of computation. I agree that python users should not have to know anything about implementation details. I'm just wondering why the transposed order is more natural than the native one. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 18:10:47 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 13:10:47 -0400 Subject: [PYTHON MATRIX-SIG] linear algebra In-Reply-To: Message-ID: <199608191710.NAA26967@cyclone.ERE.UMontreal.CA> > Just to throw in a suggestion let me tell what the Ada95 standard does to > work around this problem. In Ada95 the compiler has to have a > " pragma Convention (Fortran, Fortran_Matrix);" which changes the way > an array is actually stored in memory. > For the programmer there is no change at all, the compiler takes care of all > necessary changes to make the array Fortran as well as Ada compatible. > > Would this be possible in python without a serious perfomance overhead ? One could have a second kind of array object that used Fortran conventions for storage and inverts indexing. But I doubt that this is worth the effort. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Mon Aug 19 18:22:09 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Mon, 19 Aug 1996 13:22:09 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 References: <199608191714.NAA27307@cyclone.ERE.UMontreal.CA> Message-ID: <3218A2C1.72D9@mit.edu> Konrad HINSEN wrote: > > > Concatenation is reasonably efficient. It could be better, but I'm > > holding off on any non-trivial efficiency improvements until after > > release 1.0. Right now I think a solid, stable and reasonably complete > > implementation is much more important. > > > > I don't see any good way to solve Carlos's problem using concatenation > > (without including arbitrary comparision functions for sort which I > > don't want to do). How would you reccommend he gets the equivalent of: > > > > ix=argsort(a) > > A=take(a,ix) > > B=take(b,ix) > > > > for > 1d arrays without some take-like function? > > Concatenation is indeed not what is needed, it is what APL > calls lamination (but it is implemented as a special case > of concatenation): the creation of a new axis along which > the index 0 refers to a and the index 1 to b. Sort() then > reshuffles all elements automatically, and a simple indexing > recovers the sorted a and b. by lamination you mean array([a,b])? This still doesn't solve the problem. in this case and an b will each be sorted according to their own values. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 18:18:05 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 13:18:05 -0400 Subject: [PYTHON MATRIX-SIG] linear algebra In-Reply-To: <32189B46.114C@mit.edu> (message from Jim Hugunin on Mon, 19 Aug 1996 12:50:14 -0400) Message-ID: <199608191718.NAA27456@cyclone.ERE.UMontreal.CA> > Transposition costs almost nothing. Transposition followed by a copy is > O(n). These FORTRAN routines expect contiguous arrays, which requires > the transposed array to be copied before calling them. Therefore this > is a non-trivial amount of computation. Fortran routines rarely require contiguous arrays, and LAPACK routines definitely don't. It's just a matter of correct interfacing, but this would have to be done at the C level, since on the Python level the necessary data about the memory layout is no longer available. The current low-level LAPACK interface expects Fortran-layout arrays, but one could as well have one that handles the "transposition" itself, although that would be a more difficult task. So maybe we should leave everything as it is for now and improve the interface later. > I agree that python users should not have to know anything about > implementation details. I'm just wondering why the transposed order is > more natural than the native one. No more natural, but conventional. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsenk@ere.umontreal.ca Mon Aug 19 18:14:18 1996 From: hinsenk@ere.umontreal.ca (Konrad HINSEN) Date: Mon, 19 Aug 1996 13:14:18 -0400 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <32189A66.34E5@mit.edu> (message from Jim Hugunin on Mon, 19 Aug 1996 12:46:30 -0400) Message-ID: <199608191714.NAA27307@cyclone.ERE.UMontreal.CA> > Concatenation is reasonably efficient. It could be better, but I'm > holding off on any non-trivial efficiency improvements until after > release 1.0. Right now I think a solid, stable and reasonably complete > implementation is much more important. > > I don't see any good way to solve Carlos's problem using concatenation > (without including arbitrary comparision functions for sort which I > don't want to do). How would you reccommend he gets the equivalent of: > > ix=argsort(a) > A=take(a,ix) > B=take(b,ix) > > for > 1d arrays without some take-like function? Concatenation is indeed not what is needed, it is what APL calls lamination (but it is implemented as a special case of concatenation): the creation of a new axis along which the index 0 refers to a and the index 1 to b. Sort() then reshuffles all elements automatically, and a simple indexing recovers the sorted a and b. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsenk@ere.umontreal.ca Departement de chimie | Tel.: +1-514-343-6111 ext. 3953 Universite de Montreal | Fax: +1-514-343-7586 C.P. 6128, succ. Centre-Ville | Deutsch/Esperanto/English/Nederlands/ Montreal (QC) H3C 3J7 | Francais (phase experimentale) ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@cherokee.unl.edu Mon Aug 19 19:10:33 1996 From: drh@cherokee.unl.edu (Doug Heisterkamp) Date: Mon, 19 Aug 1996 13:10:33 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] asarray and Complex? Message-ID: <9608191810.AA08422@cherokee.unl.edu> asarray is not converting the array to a different type when the typecode is given: >>> from Numeric import * >>> a = arange(4) >>> b = asarray(a,Complex32) >>> b 0 1 2 3 Also, the Complex type code is not working for me, but Complex32 is: >>> d = a.astype(Complex) >>> d 0. 1. 2. 3. >>> d[0] = 1 -1j >>> d 1. 1. 2. 3. >>> d = a.astype(Complex32) >>> d (0.+0.j) (1.+0.j) (2.+0.j) (3.+0.j) (4.+0.j) (5.+0.j) (6.+0.j) (7.+0.j) (8.+0.j) Doug drh@cherokee.unl.edu ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@cherokee.unl.edu Mon Aug 19 19:39:12 1996 From: drh@cherokee.unl.edu (Doug Heisterkamp) Date: Mon, 19 Aug 1996 13:39:12 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] linear algebra In-Reply-To: <32186E5B.4BA8@mit.edu> from "Jim Hugunin" at Aug 19, 96 09:38:35 am Message-ID: <9608191839.AA08503@cherokee.unl.edu> > All of the current interface routines (from LinAlg.py) do the following: > > return transpose(lapackfunction(transpose(input_matrix))) > > Should these two transpositions be there? This is obviously related to > the different index order between NumPy and FORTRAN. Still, I've always > personally considered it a superficial difference that is best ignored. > > If I remember by Linear Algebra correctly > transpose(inverse(transpose(m))) == inverse(m). > For functions like inverse and eigenvalues, the transpose is not needed. To skip the transpose for other functions is really just pushing the transpose back to when the user is placing data in the matrix. This would probably cause to much confusion in a standard library. I have a version of LinAlg.py in which I do not transpose the matrices. That version does not even copy the matrices. I just catch the exception when the array is not contiguous and then copy it. When I use that version, I know the data should be contiguous and is all ready stored for Fortran use. Doug Heisterkamp drh@cherokee.unl.edu ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From paul@aem.umn.edu Mon Aug 19 20:01:51 1996 From: paul@aem.umn.edu (Ralph Paul) Date: Mon, 19 Aug 1996 14:01:51 -0500 Subject: [PYTHON MATRIX-SIG] linear algebra In-Reply-To: <199608191718.NAA27456@cyclone.ERE.UMontreal.CA> Message-ID: On Mon, 19 Aug 1996 13:18:05 -0400 owner-matrix-sig@python.org wrote: [ ...snip... ] > The current low-level LAPACK interface expects Fortran-layout > arrays, but one could as well have one that handles the "transposition" > itself, although that would be a more difficult task. So maybe we > should leave everything as it is for now and improve the interface > later. How about providing functions that make the conversion obvious. Something like "To_Fortran" . That way you know what is happening but you don't have to know about the column oriented storage ( = transpose ) Fortran uses. Since you can code this in C, you can probably make it pretty fast. Ralph Paul paul@aem.umn.edu or ralph@ifr.luftahrt.uni-stuttgart.de ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From drh@cherokee.unl.edu Mon Aug 19 20:16:50 1996 From: drh@cherokee.unl.edu (Doug Heisterkamp) Date: Mon, 19 Aug 1996 14:16:50 -0500 (CDT) Subject: [PYTHON MATRIX-SIG] EmptyArray as false Message-ID: <9608191916.AA08623@cherokee.unl.edu> It would be useful if an empty array acted as false, in the same way that an empty list does. >>> from Numeric import * >>> a = array([]) >>> a EmptyArray >>> if a: print "a==TRUE" ... a==TRUE >>> if []: print "[] == TRUE" ... >>> Doug Heisterkamp drh@cherokee.unl.edu ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From phil@geog.ubc.ca Mon Aug 19 20:54:50 1996 From: phil@geog.ubc.ca (Phil Austin) Date: Mon, 19 Aug 1996 12:54:50 -0700 (PDT) Subject: [PYTHON MATRIX-SIG] linear algebra (Column major arrays) In-Reply-To: <199608191710.NAA26967@cyclone.ERE.UMontreal.CA> References: <199608191710.NAA26967@cyclone.ERE.UMontreal.CA> Message-ID: <199608191954.MAA12771@coot.geog.ubc.ca> >>>>> "Konrad" == Konrad HINSEN writes: >> Just to throw in a suggestion let me tell what the Ada95 >> standard does to work around this problem. In Ada95 the >> compiler has to have a " pragma Convention (Fortran, >> Fortran_Matrix);" which changes the way an array is actually >> stored in memory. For the programmer there is no change at >> all, the compiler takes care of all necessary changes to make >> the array Fortran as well as Ada compatible. >> >> Would this be possible in python without a serious perfomance >> overhead ? Konrad> One could have a second kind of array object that used Konrad> Fortran conventions for storage and inverts indexing. But Konrad> I doubt that this is worth the effort. We're hoping that users can implement column-major arrays without large performance penalties if they aren't intrinsic to the Python matrix library. Settling on one index order among our binary data api (netcdf), other matrix packages (splus), and our compiled code (F77, HPF, F90, and C++ using MV++,r A++/P++ or Barton and Nackman--all column major), eliminates a vexing source of confusion and cuts a suprising amount of work from debugging, tutorial writing, etc. Phil Austin INTERNET: phil@geog.ubc.ca (604) 822-2175 FAX: (604) 822-6150 http://www.geog.ubc.ca/~phil Associate Professor Atmospheric Sciences Programme Geography #217 University of British Columbia 1984 W Mall Vancouver, BC V6T 1Z2 CANADA ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From pas@lems.brown.edu Mon Aug 19 20:51:57 1996 From: pas@lems.brown.edu (Perry A. Stoll) Date: Mon, 19 Aug 1996 15:51:57 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] repr vs. str Message-ID: Currently the str and repr functions call the same function to print an array object, namely string_repr. From the manual http://www.python.org/doc/ref/node23.html#SECTION00431000000000000000 __repr__(self) Called by the repr() built-in function and by string conversions (reverse or backward quotes) to compute the string representation of an object. __str__(self) Called by the str() built-in function and by the print statement compute the string representation of an object. Seems like print and str should return the same string, which in this case would be whatever the array print function is. I thought repr should try to return a string which could be used to reconstruct the object and str was purely for human consumption. Is that correct? -Perry ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Mon Aug 19 21:10:18 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Mon, 19 Aug 1996 16:10:18 -0400 Subject: [PYTHON MATRIX-SIG] linear algebra (Column major arrays) References: <199608191710.NAA26967@cyclone.ERE.UMontreal.CA> <199608191954.MAA12771@coot.geog.ubc.ca> Message-ID: <3218CA2A.3E22@mit.edu> Phil Austin wrote: > > >>>>> "Konrad" == Konrad HINSEN writes: > > >> Just to throw in a suggestion let me tell what the Ada95 > >> standard does to work around this problem. In Ada95 the > >> compiler has to have a " pragma Convention (Fortran, > >> Fortran_Matrix);" which changes the way an array is actually > >> stored in memory. For the programmer there is no change at > >> all, the compiler takes care of all necessary changes to make > >> the array Fortran as well as Ada compatible. > >> > >> Would this be possible in python without a serious perfomance > >> overhead ? > > Konrad> One could have a second kind of array object that used > Konrad> Fortran conventions for storage and inverts indexing. But > Konrad> I doubt that this is worth the effort. > > We're hoping that users can implement column-major arrays without > large performance penalties if they aren't intrinsic to the Python > matrix library. Settling on one index order among our binary data api > (netcdf), other matrix packages (splus), and our compiled code (F77, > HPF, F90, and C++ using MV++,r A++/P++ or Barton and Nackman--all > column major), eliminates a vexing source of confusion and cuts a > suprising amount of work from debugging, tutorial writing, etc. I have to admit to a certain bafflement as to the importance of this issue to people... Nonetheless, there are many ways of implementing column major arrays with close to zero performance hit within NumPy. The use of general strides allows for you to force Array objects to access their data exactly as if they were a FORTRAN column-major array. Personally I find this approach rather distasteful, but a number of diehard FORTRAN users were thrilled when they figured out they could do this, so if it's useful to you... Also, the transpose function is extremely efficient (almost negligible). So long as your C/FORTRAN functions can handle discontiguous strided arrays (as apparently Lapack can) then this option will also work for you. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Mon Aug 19 23:23:42 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Mon, 19 Aug 1996 17:23:42 -0500 Subject: [PYTHON MATRIX-SIG] Another way to crash the interpreter using long ints... In-Reply-To: <3218CA2A.3E22@mit.edu> (message from Jim Hugunin on Mon, 19 Aug 1996 16:10:18 -0400) Message-ID: <199608192222.SAA15772@python.org> Check this out: >>> from Numeric import * >>> c = concatenate((arange(1l,5l),)) >>> c.shape (4,) >>> c Segmentation fault -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Mon Aug 19 21:37:49 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Mon, 19 Aug 1996 21:37:49 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 In-Reply-To: <199608191616.MAA18876@cyclone.ERE.UMontreal.CA> Message-ID: On Mon, 19 Aug 1996, Konrad HINSEN wrote: > > This is called "selection" (one of the 3 main operators) operators. > > I am not sure what you are referring to. Is that a special term from > GA applications? Sorry, I edited that line about three times and it doesn't make sense. Selection is one of the three main GA operators, i.e., just about every GA would include a line: Offspring = my_take(Parents,indices,axis=(-1 or -2)) I will not insist on the default axis issue, since you have obviously given a lot more thought to the subject than I can claim to have done. As long as the default values are documented and explained, that should be fine. But even if take and friends should have axis=0 by default, please, not sort(), argsort() and fft(), and any other matrix operations. :-) > Unless your array is very big, this variant might actually be more > expensive than the first one, because it involves three interpreted > function calls. The best solution for such applications would be > a special function that inverts a permutation (which is O(N), unlike > sorting). Than you would write > > rank = inv_permutation(argsort(cost)) > > This function would potentially be more generally useful than your > ekat(). > > Konrad. I hadn't thought of that, but I agree with you here. Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Mon Aug 19 22:10:37 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Mon, 19 Aug 1996 22:10:37 +0100 (BST) Subject: [PYTHON MATRIX-SIG] linear algebra In-Reply-To: <32186E5B.4BA8@mit.edu> Message-ID: On Mon, 19 Aug 1996, Jim Hugunin wrote: > All of the current interface routines (from LinAlg.py) do the following: > > return transpose(lapackfunction(transpose(input_matrix))) > > Should these two transpositions be there? This is obviously related to > the different index order between NumPy and FORTRAN. Still, I've always > personally considered it a superficial difference that is best ignored. > > If I remember by Linear Algebra correctly > transpose(inverse(transpose(m))) == inverse(m). > > However, I very rarely use any linear algebra functions in my code so > I'm not the right person to be making that decision. Opinions? > > -Jim As long as the result is mathematically equivalent, there should be no need to have transpose() there. Any equivalences of this kind should be exploited as much as possible, even if they apply to only a small number of operations. Thus, if Lapack implements C= A^(-1).B efficiently (in Fortran style), then Python should compute c=b.a^(-1) equally efficiently, just by passing the c-arrays unchanged to the fortran code (and the appropriately swapped dimensions, without any need for copying or transposing the result). In general, python should be as good with row vectors (1d vectors *are* row vectors in python) as LAPACK with column vectors. In matlab A\b is more efficient than b/A (the second is implemented as (A'\b')'), but both are available. I am happy if python comes to expect row vectors if this makes the interface code simpler and more efficient. (Sorry, I can't comment on whether LAPACK requires contiguous arrays or not.) Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Tue Aug 20 03:14:01 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Tue, 20 Aug 1996 03:14:01 +0100 (BST) Subject: [PYTHON MATRIX-SIG] take() again Message-ID: I was thinking about take(), indexing, structural operations, etc., and got some more ideas on take() which should make it possible to combine both mine and Konrad's expectations into a single function. The source of confusion in my mind seems to have been that, whereas a+b expects arrays to be aligned at their last dimension, indexing works on the outer dimension. In the case of take(), it should work on the outer dimension*s*. My proposal is a take(a,indices,axis) where * the dimensions of indices must be aligned with the *outer* (or leftmost) dimensions of a (and not the inner ones, as I proposed before). * the default axis is the inner axis of _indices_. This is not necessarily the inner axis of a, as indices my have lower rank than a. We would still say axis=-1, but this would refer to indices, not to a. Now, for some examples: If indices is 1d, axis=-1 is the same as axis=0, and we have the current behaviour. If indices has the same shape as a, then take(a,argsort(a,-1)) will work as expected. Even better, if indices has shape (m,n) and a has shape (m,n,p), take(a,indices) will rearrange (or select) the rows of a. I believe this to be consistent with the idea of a structural operation, and is what I will actually need in my application. If indices is 2d and we want the current behaviour, then take([a],indices) will do it. In this way, the rank of the result will only increase if we explicitly want it to. Note that in all of the above situations, the default axis produced the desired results. Would this be acceptable? Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 20 14:04:08 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 20 Aug 1996 09:04:08 -0400 Subject: [PYTHON MATRIX-SIG] Another way to crash the interpreter using long ints... References: <199608192222.SAA15772@python.org> Message-ID: <3219B7C8.7DBD@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > Check this out: > > >>> from Numeric import * > >>> c = concatenate((arange(1l,5l),)) > >>> c.shape > (4,) > >>> c > Segmentation fault The problem in all of these cases is apparently in the array printing functions when long ints are contained in the array. My problem is that this doesn't show up on my primary developement platform. I'll look into it on other platforms around here. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 20 14:27:42 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 20 Aug 1996 09:27:42 -0400 Subject: [PYTHON MATRIX-SIG] asarray and Complex? References: <9608191810.AA08422@cherokee.unl.edu> Message-ID: <3219BD4E.6E5D@mit.edu> Doug Heisterkamp wrote: > > asarray is not converting the array to a different type when the > typecode is given: typo in Numeric.py. Fixed > Also, the Complex type code is not working for me, but Complex32 is: typo in Precision.py. Fixed ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 20 14:36:21 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 20 Aug 1996 09:36:21 -0400 Subject: [PYTHON MATRIX-SIG] repr vs. str References: Message-ID: <3219BF55.66FD@mit.edu> Perry A. Stoll wrote: > > Currently the str and repr functions call the same function > to print an array object, namely string_repr. From the manual > http://www.python.org/doc/ref/node23.html#SECTION00431000000000000000 > > __repr__(self) > Called by the repr() built-in function and by string conversions > (reverse or backward quotes) to compute the string > representation of an object. > > __str__(self) > Called by the str() built-in function and by the print statement > compute the string representation of an object. > > Seems like print and str should return the same string, which in this > case would be whatever the array print function is. I thought repr > should try to return a string which could be used to reconstruct the > object and str was purely for human consumption. Is that correct? This sounds good to me. I've made your requested change. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Tue Aug 20 15:18:18 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Tue, 20 Aug 1996 09:18:18 -0500 Subject: [PYTHON MATRIX-SIG] Another way to crash the interpreter using long ints... In-Reply-To: <3219B7C8.7DBD@mit.edu> (message from Jim Hugunin on Tue, 20 Aug 1996 09:04:08 -0400) Message-ID: <199608201416.KAA17862@python.org> I've been trying to look into it from this end, unfortunatley, my understanding of the python internals is somewhat (ok very) sketchy. For what its worth, here's what I've noticed: 1) Long ints work most of the time on alpha2: >>> arange(1,5l,2) 1L 3L >>> arange(1,5l)[::2] 1L 3L Concatenating arrays of long ints is the only thing that I've found that breaks on my machine. 2) I've inluded the stack trace for: > >>> from Numeric import * > >>> c = concatenate((arange(1l,5l),)) > >>> c.shape > (4,) > >>> c > Segmentation fault Way down at the bottom for what it's worth. Poking around the only thing that looked obviously wrong (recall I know little about the guts of python) was that in builtin_str, it's passed a tuple with ob_refcnt=3, and this gets passed to newgetargs which returns what seems to be garbage: if (!newgetargs(args, "O:str", &v)) return NULL; return strobject(v); (gdb) p *v->ob_type $20 = {ob_refcnt = 135100992, ob_type = 0x80d7a20, ob_size = 65537, ^^^^^^^^^ tp_name = 0x80d7a40 "Tpz\r\b`z\r\b\001", tp_basicsize = 0, ^^^^^^^^^^^^^^^^^ 3) This also breaks the interpreter, and I don't think it calls the array printing code. It does have that same goofy object floating around though... That's all I can think of, for now. -tim #0 0x80d78e0 in UP () #1 0x806ea2b in PyObject_Str (v=0x80d7a40) at object.c:231 #2 0x8040cc9 in builtin_str (self=0x0, args=0x80d1380) at bltinmodule.c:1386 #3 0x8047b1d in call_builtin (func=0x80a6d40, arg=0x80d1380, kw=0x0) at ceval.c:2401 #4 0x80479a1 in PyEval_CallObjectWithKeywords (func=0x80a6d40, arg=0x80d1380, kw=0x0) at ceval.c:2366 #5 0x80458c1 in eval_code2 (co=0x80cc580, globals=0x80d7f80, locals=0x0, args=0x80d156c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1629 #6 0x8047fcd in call_function (func=0x80ca0c0, arg=0x80d1560, kw=0x0) at ceval.c:2518 #7 0x8047981 in PyEval_CallObjectWithKeywords (func=0x80ca0c0, arg=0x80d1560, kw=0x0) at ceval.c:2364 #8 0x8047862 in PyEval_CallObject (func=0x80ca0c0, arg=0x80d1560) at ceval.c:2335 #9 0x803f0fd in builtin_map (self=0x0, args=0x80ceba0) at bltinmodule.c:676 #10 0x8047b1d in call_builtin (func=0x80a6e30, arg=0x80ceba0, kw=0x0) at ceval.c:2401 #11 0x80479a1 in PyEval_CallObjectWithKeywords (func=0x80a6e30, arg=0x80ceba0, kw=0x0) at ceval.c:2366 #12 0x80458c1 in eval_code2 (co=0x80cc240, globals=0x80d7f80, locals=0x0, args=0x80d79cc, argcount=1, kws=0x0, kwcount=0, defs=0x80c63ec, defcount=3, owner=0x0) at ceval.c:1629 #13 0x8047fcd in call_function (func=0x80d7ee0, arg=0x80d79c0, kw=0x0) at ceval.c:2518 #14 0x8047981 in PyEval_CallObjectWithKeywords (func=0x80d7ee0, arg=0x80d79c0, kw=0x0) at ceval.c:2364 #15 0x8047862 in PyEval_CallObject (func=0x80d7ee0, arg=0x80d79c0) at ceval.c:2335 #16 0x800dc55 in array_print (self=0x80d6940, fp=0x809fa90, flags=0) at ./arrayobject.c:1037 #17 0x806e877 in PyObject_Print (op=0x80d6940, fp=0x809fa90, flags=0) at object.c:190 #18 0x8063841 in PyFile_WriteObject (v=0x80d6940, f=0x80a53e0, flags=0) at fileobject.c:793 #19 0x80436d4 in eval_code2 (co=0x80d6980, globals=0x80ad820, locals=0x80ad820, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:894 #20 0x80419a2 in PyEval_EvalCode (co=0x80d6980, globals=0x80ad820, locals=0x80ad820) at ceval.c:282 #21 0x8058021 in run_node (n=0x80d7880, filename=0x808a8aa "", globals=0x80ad820, locals=0x80ad820) at pythonrun.c:426 #22 0x8057766 in PyRun_InteractiveOne (fp=0x809fb50, filename=0x808a8aa "") at pythonrun.c:208 #23 0x805754f in PyRun_InteractiveLoop (fp=0x809fb50, filename=0x808a8aa "") at pythonrun.c:149 #24 0x805740a in PyRun_AnyFile (fp=0x809fb50, filename=0x808a8aa "") at pythonrun.c:126 #25 0x80035b8 in main (argc=1, argv=0xbffffd30) at main.c:207 #26 0x8003075 in ___crt_dummy__ () #27 0xbffffbb8 in UP () #28 0x2fc45 in ?? () -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Tue Aug 20 15:30:46 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Tue, 20 Aug 1996 10:30:46 -0400 Subject: [PYTHON MATRIX-SIG] Another way to crash the interpreter using long ints... References: <9608201415.AA24291@MIT.EDU> Message-ID: <3219CC16.1A1D@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > I've been trying to look into it from this end, unfortunatley, my > understanding of the python internals is somewhat (ok very) > sketchy. For what its worth, here's what I've noticed: > > 1) Long ints work most of the time on alpha2: > > >>> arange(1,5l,2) > 1L 3L > >>> arange(1,5l)[::2] > 1L 3L I've figured out the source of the bug here. I'm going to explain in some detail for those who are interested. 1) An array of long ints is represented as an array of generic python objects. Elements of this array could be anything from a user-defined class to other strange builtin types. Operations on these arrays are obviously going to be less efficient that on corresponding arrays of raw C data, but they shouldn't be too bad. 2) Many C functions (take, concatenate, repeat, choose, ...) use memcpy on portions of an array in order to copy the raw contents of one array to a new one. 3) When you copy a pointer to a PyObject, you need to remember to INCREF that object. This is in contrast to every other potential type of array. 4) I forgot to add in the PyArray_INCREF call (INCREF's all the python objects in the array) to virtually all of the array C functions when I rewrote them (to avoid other potential memory leaks) for 1.0a1. I've now fixed the obvious problems for alpha3, but I'd have to admit that remembering all of the required INCREF's and DECREF's can sometimes be a confusing process (and tracking down the error can be even worse). -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Tue Aug 20 19:54:03 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 20 Aug 1996 19:54:03 +0100 Subject: [PYTHON MATRIX-SIG] Re: take() again Message-ID: <321A09CB.384E@ibs.ibs.fr> > My proposal is a take(a,indices,axis) where > > * the dimensions of indices must be aligned with the *outer* (or leftmost) > dimensions of a (and not the inner ones, as I proposed before). > > * the default axis is the inner axis of _indices_. This is not necessarily > the inner axis of a, as indices my have lower rank than a. We would still > say axis=-1, but this would refer to indices, not to a. You would be welcome in the J development team, because what you have just described is exactly how J behaves with a modified rank for its left argument (i.e. the indices). I agree that this is very useful, but modifying the access to the other argument is also useful. Obviously the best way out is to have two axis argument, then we would almost have the full J functionality. But I am not sure whether that is a realistic proposal. > If indices is 2d and we want the current behaviour, then take([a],indices) > will do it. In this way, the rank of the result will only increase if we > explicitly want it to. Yes, but what if we want the current behaviour with an arbitrary axis specification? That would be lost. Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Tue Aug 20 19:50:43 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 20 Aug 1996 19:50:43 +0100 Subject: [PYTHON MATRIX-SIG] Final conventions for alpha2 Message-ID: <321A0903.3CA3@ibs.ibs.fr> > fine. But even if take and friends should have axis=0 by default, please, > not sort(), argsort() and fft(), and any other matrix operations. :-) I agree, of course! Konrad. ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Wed Aug 21 00:09:22 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Tue, 20 Aug 1996 18:09:22 -0500 Subject: [PYTHON MATRIX-SIG] Indexing bug? In-Reply-To: <3219CC16.1A1D@mit.edu> (message from Jim Hugunin on Tue, 20 Aug 1996 10:30:46 -0400) Message-ID: <199608202307.TAA19369@python.org> I think this is a bug: >>> a = arange(8) >>> a 0 1 2 3 4 5 6 7 >>> a[::2] 0 2 4 6 >>> a[1::2] 1 3 5 >>> Shouldn't this return 1 3 5 7? -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 21 17:09:29 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 21 Aug 1996 12:09:29 -0400 Subject: [PYTHON MATRIX-SIG] Re: Indexing bug? References: <9608202306.AA27623@MIT.EDU> Message-ID: <321B34B9.184E@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > I think this is a bug: > > >>> a = arange(8) > >>> a > 0 1 2 3 4 5 6 7 > >>> a[::2] > 0 2 4 6 > >>> a[1::2] > 1 3 5 > >>> > > Shouldn't this return 1 3 5 7? Certainly should. This got lost in the translation to the new built-in slices that come with 1.4b2. It's fixed in alpha3. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From fonseca@gaivota.demon.co.uk Wed Aug 21 22:46:12 1996 From: fonseca@gaivota.demon.co.uk (Carlos Fonseca) Date: Wed, 21 Aug 1996 22:46:12 +0100 (BST) Subject: [PYTHON MATRIX-SIG] Re: take() again In-Reply-To: <321A09CB.384E@ibs.ibs.fr> Message-ID: On Tue, 20 Aug 1996, Konrad Hinsen wrote: > You would be welcome in the J development team, because what you have > just described is exactly how J behaves with a modified rank for its > left argument (i.e. the indices). I agree that this is very useful, > but modifying the access to the other argument is also useful. > Obviously the best way out is to have two axis argument, then we > would almost have the full J functionality. But I am not sure whether > that is a realistic proposal. I am not familiar with J, but from what I've read in this list, it would seem to have very complete multidimensional array handling. Why would "full" functionality not be realistic? Too complex, perhaps? > > If indices is 2d and we want the current behaviour, then take([a],indices) > > will do it. In this way, the rank of the result will only increase if we > > explicitly want it to. > > Yes, but what if we want the current behaviour with an arbitrary axis > specification? That would be lost. > One could always write take(a,[indices]) to get the current behaviour with axis=2, if indices is 1d. More generally, one could write take( a[(ni-1)*(NewAxis,)],indices[(Ellipses,)+ax*(NewAxis,)+(All,)] ) where ni is the number of dimensions in indices, and ax is the desired axis in a. Many other combinations would also be possible, of course. The above may not look nice, but it would work for *all* cases, and the default values should cover *most* cases. Currently, take()'s functionality is still incomplete, as I hope to have convinced everybody by now. What else can we do about take, so that it works for at least the two of us? ;-) Carlos ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 22 05:23:43 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Wed, 21 Aug 1996 23:23:43 -0500 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. Message-ID: <199608220421.AAA22858@python.org> I have an idea about default axes. I'm not entirely satisfied with it, but its been bugging me for a week or so, so I figured I'd let it bug you'all instead. To the best of my recollection, the arguments about default axes go like this (apologies in advance for any misrepresentation of someone's posistion): Jim Hugunin: Remembering what are the default axes is too comlicated. We should pick a single default axes and stick with it. (With perhaps 1 or 2 exceptions for some weird functions). Konrad Hinsen: It's absurd to make people type axis=? for a whole class of functions that normally use an axis other than the default. The array functions divide naturally into two classes, those that normally use axis=0 and those that use the last possible axis (-1 for vector ops, -2 for 2d matrix ops, etc.). Therefore, it should be possible to figure out with a minimum of effort what the natural axis is. I agree with both these posistions! It would be annoying to have to type axis=0 (or conversely axis=-1) all over the place if there's a single default axis. On the other hand, I'm not sure the difference between structural and non-strucural matrix ops is clear for all cases. Particularly for people new to NumPy. And, some people may have different ideas about what is the natural axis for a particular operation (Carlos said something about this, I think?). A problem I see with both posistions, particuarly Jim's, is that there will be a temptation to redefine the functions when the desired default axis with the default, e.g (as Jim posted), def fft(f): fft(f, axis=-1) Which leads to a problem with code readability for people who don't use your conventions. Some sort of naming convention could provide a way out of this box. That is, indicate by the name of the function what the default axis is, e.g., fft(f) <=> fft(f,axis=0) fft_(f) <=> fft(f,axis=-1) # _ <=> farther away <=> -1 (or -2...) A complete set of both functions could be provided, or just guidelines on how people are to name their own should they need the other axis. Pros: 1) No need to type axis=? for what should be the default case. 2) Obvious at a glance what the default axis is. 3) Removes incentive to create private versions of functions. Cons: 1) Aesthetics? 2) Requires a certain amount of function renaming. 3) Doesn't help with dot (**). 4) .... Opinions? ________________________________________________________________ (**) Another naming convention that is too ugly too live, but would take care of dot, is: dot00(f,g) = dot(f,g,axis=(0,0)) dot01(f,g) = dot(f,g,axis=(0,-1)) fft1(f) = fft(f,axis=-1) etc. -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From janne@avocado.pc.helsinki.fi Thu Aug 22 09:02:53 1996 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 22 Aug 1996 11:02:53 +0300 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. In-Reply-To: tim@lassi.ece.uiuc.edu's message of Wed, 21 Aug 1996 23:23:43 -0500 References: <199608220421.AAA22858@python.org> Message-ID: tim@lassi.ece.uiuc.edu writes: > Opinions? Here is a related idea: the default axis could be (could it be technically and easily? i'm somewhat new to python) an attribute of the functions, so one could write: fft.default_axis=-1 or for f in Numeric.ufuncs: f.default_axis=-1 Code reability would suffer badly, of course. I don't know whether this is a good idea or not, it just came to my mind. On the long run, the only sensible solution is to add some information about the semantics of the axes to the objects (arrays) themselves. -- Janne Sinkkonen ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 22 16:02:38 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 22 Aug 1996 11:02:38 -0400 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. References: <199608220421.AAA22858@python.org> Message-ID: <321C768E.63D8@mit.edu> tim@lassi.ece.uiuc.edu wrote: > > I have an idea about default axes. I'm not entirely satisfied with it, > but its been bugging me for a week or so, so I figured I'd let it bug > you'all instead. I'm glad you brought this idea up, it seems there might be a solution in it somewhere. > Some sort of naming convention could provide a way out of this > box. That is, indicate by the name of the function what the default > axis is, e.g., > > fft(f) <=> fft(f,axis=0) > fft_(f) <=> fft(f,axis=-1) # _ <=> farther away <=> -1 (or -2...) > > A complete set of both functions could be provided, or just guidelines > on how people are to name their own should they need the other axis. I really don't think that a complete set of both function should be provided. The great value in this proposal is it lets me define the "proper" default axis for each function without fear of people not being able to remember which one that is. > Pros: > 1) No need to type axis=? for what should be the default case. > 2) Obvious at a glance what the default axis is. > 3) Removes incentive to create private versions of functions. The pros all sound good to me. > Cons: > 1) Aesthetics? I don't like fft_ for the last axis. _ is getting a little bit overloaded in python these days. > 2) Requires a certain amount of function renaming. Still not a big concern to me. > 3) Doesn't help with dot (**). I don't think this should be too much of a concern. Now my comments in full: 0) I've been writing code all this week using alpha2 and I've found myself quite happy writing fft(a, axis=-1) everywhere. This isn't actually all that much extra baggage to be carrying around. That said... 1) A naming convention to distinguish between structural and non-structural operations might satisfy both Konrad and myself. I'm still not sure what that naming convention should look like. 2) This naming convention should not become a substitute for non-default axis specification. ie. people should not define concatenate_ as a substitute for concatenate( arrays, axis=-1). Using this keyword argument seems to me a great way to change the default axis when you need to. I can't think of any good naming conventions off hand, but just to make things concrete, here's a list of some names to discuss: structural operations: concatenate, reduce, take, repeat, ... nonstructural operation: sort, argsort, fft, argmax, (sum?), ... And here are several bad proposals (I'm not planning on implementing any of these): nonstructural_sort, nonstructural_fft, ... ns_sort, ns_fft, ... sort_last_axis, fft_last_axis, ... If the names of these functions somehow made their categories obvious, then I'd be happy to set the default axis for the nonstructural operations to be -1. Now to shoot down a few directions I don't want this conversation to go. > ________________________________________________________________ > > (**) Another naming convention that is too ugly too live, but would > take care of dot, is: > dot00(f,g) = dot(f,g,axis=(0,0)) > dot01(f,g) = dot(f,g,axis=(0,-1)) > fft1(f) = fft(f,axis=-1) > etc. Definately too ugly to live ;-) To say it again. The point here is to make it obvious by the name what type of function this is (structural or non) not to replace the perfectly good way we already have of overriding the default axis. On another note: Janne Sinkkonen wrote: > Here is a related idea: the default axis could be (could it be > technically and easily? i'm somewhat new to python) an attribute of > the functions, so one could write: This is reasonably easy technically, but see my comments later for why I won't do it. > fft.default_axis=-1 > > or > > for f in Numeric.ufuncs: f.default_axis=-1 > > Code reability would suffer badly, of course. I don't know whether > this is a good idea or not, it just came to my mind. Code readability would suffer far too much for my tastes. This is just another variant on the: def fft(x,axis=-1): fft(x,axis) solution. This is the sort of thing that everybody would probably enjoy when writing their own functions, but which would make reading other people's code impossible. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 22 16:32:56 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 22 Aug 1996 11:32:56 -0400 Subject: [PYTHON MATRIX-SIG] Re: take() again References: Message-ID: <321C7DA8.52DC@mit.edu> Carlos Fonseca wrote: ... > One could always write take(a,[indices]) to get the current behaviour with > axis=2, if indices is 1d. More generally, one could write > > take( a[(ni-1)*(NewAxis,)],indices[(Ellipses,)+ax*(NewAxis,)+(All,)] ) You aren't seriously suggesting that people write python code that looks like this? I think that everybody could be made happy if I added the following function to alpha3: permute(a, permutation) a and permutation must be aligned for as many axes as there are in permutation. The elements of a will be resorted according to the elements of permutation. ie. permute(a, argsort(a)) <==> sort(a) I think that with this function and take almost everything that you want to do with Carlos' fancy take would be possible. I also think that having two fairly easy to understand functions is a better situation than having one really complicated one. Note: permute(a, indices) <==> take(a, indices) iff: len(indices) = len(a) len(indices.shape) = 1 Opinions? - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 22 17:10:40 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Thu, 22 Aug 1996 11:10:40 -0500 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. In-Reply-To: <321C768E.63D8@mit.edu> (message from Jim Hugunin on Thu, 22 Aug 1996 11:02:38 -0400) Message-ID: <199608221610.MAA24096@python.org> Here some more random naming conventions for your amusement: Capitalize structural ops: Concatenate, Reduce, Take, Repeat, ... sort, argsort, fft, argmax, ... "Simple, but looks like a Class constructor..." Use 'of' with nonstructural ops (as "the argsort of x"): concatenate, reduce, take, repeat, ... sort_of, argsort_of, fft_of, argmax_of, ... "Weird" Turn nonstructural operations into adjectives, leave structural ones as verbs: concatenate, reduce, take, repeat, ... sorted, argsorted, ffted, argmaxed, ... "Weirder!" Spell nonstructural operations backwards: concatenate, reduce, take, repeat, ... tors, torsgra, tff, xamgra, ... "Very weird! Impossible to spell. Fails for palindromes." -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 22 20:01:53 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 22 Aug 1996 20:01:53 +0100 Subject: [PYTHON MATRIX-SIG] Re: take() again References: Message-ID: <321CAEA1.3AB8@ibs.ibs.fr> Carlos Fonseca wrote: > > I am not familiar with J, but from what I've read in this list, it would > seem to have very complete multidimensional array handling. Why would > "full" functionality not be realistic? Too complex, perhaps? The implementation might take so long that we'll never get to beta stage. I don't see any problems in principle. > One could always write take(a,[indices]) to get the current behaviour with > axis=2, if indices is 1d. More generally, one could write > > take( a[(ni-1)*(NewAxis,)],indices[(Ellipses,)+ax*(NewAxis,)+(All,)] ) Would you really like to write that? Or read it? > The above may not look nice, but it would work for *all* cases, and the > default values should cover *most* cases. Currently, take()'s For any reasonably frequent expression there should be a readable form. This doesn't have to be the default, but what you have written above doesn't qualify as Python code in my eyes ;-) Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 22 20:27:20 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 22 Aug 1996 20:27:20 +0100 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. References: <199608220421.AAA22858@python.org> <321C768E.63D8@mit.edu> Message-ID: <321CB498.4F4A@ibs.ibs.fr> Jim Hugunin wrote: > > I really don't think that a complete set of both function should be > provided. The great value in this proposal is it lets me define the > "proper" default axis for each function without fear of people not being > able to remember which one that is. That supposes that the naming convention is easier to remember than the default axis, which is not obvious to me. I can imagine people wondering whether the correct function is fft or fft_. > If the names of these functions somehow made their categories obvious, > then I'd be happy to set the default axis for the nonstructural > operations to be -1. I can't think of a naming scheme that would work like that. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 22 19:48:21 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 22 Aug 1996 14:48:21 -0400 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. References: <199608220421.AAA22858@python.org> <321C768E.63D8@mit.edu> <321CB498.4F4A@ibs.ibs.fr> Message-ID: <321CAB75.2236@mit.edu> Konrad Hinsen wrote: > > Jim Hugunin wrote: > > > > I really don't think that a complete set of both function should be > > provided. The great value in this proposal is it lets me define the > > "proper" default axis for each function without fear of people not being > > able to remember which one that is. > > That supposes that the naming convention is easier to remember than > the default axis, which is not obvious to me. I can imagine people > wondering whether the correct function is fft or fft_. I'd argue here that if you can remember that fft operates on the -1 axis, you can remember that all functions that operate by default on the -1 axis have an underscore after them (which by the way is not a naming convention I find reasonable). What I like about this is that if you forget that fft operates on axis=-1 by default you get an exception (for example the name fft is undefined). Otherwise, you instead get a perfectly legal array back who's values are completely different from what you expected. I find these bugs extremely hard to track down (from personal experience). Your concern about people wondering whether it's fft or fft_ is exactly my concern about people wondering if its axis=-1 or axis=0. > > If the names of these functions somehow made their categories obvious, > > then I'd be happy to set the default axis for the nonstructural > > operations to be -1. > > I can't think of a naming scheme that would work like that. I can't either, but I do think this would be a fine solution if somebody can come up with the right names. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 22 20:52:10 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 22 Aug 1996 20:52:10 +0100 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. References: <199608220421.AAA22858@python.org> <321C768E.63D8@mit.edu> <321CB498.4F4A@ibs.ibs.fr> <321CAB75.2236@mit.edu> Message-ID: <321CBA6A.675E@ibs.ibs.fr> Jim Hugunin wrote: > > Konrad Hinsen wrote: > > > > Jim Hugunin wrote: > > > > > > I really don't think that a complete set of both function should be > > > provided. The great value in this proposal is it lets me define the > > > "proper" default axis for each function without fear of people not being > > > able to remember which one that is. > > > > That supposes that the naming convention is easier to remember than > > the default axis, which is not obvious to me. I can imagine people > > wondering whether the correct function is fft or fft_. > > I'd argue here that if you can remember that fft operates on the -1 > axis, you can remember that all functions that operate by default on the > -1 axis have an underscore after them (which by the way is not a naming > convention I find reasonable). I agree, but such a naming convention is useful if it is *easier* to remember, not just as easy. > Your concern about people wondering whether it's fft or fft_ is exactly > my concern about people wondering if its axis=-1 or axis=0. That was the point of my example! > > > If the names of these functions somehow made their categories obvious, > > > then I'd be happy to set the default axis for the nonstructural > > > operations to be -1. > > > > I can't think of a naming scheme that would work like that. > > I can't either, but I do think this would be a fine solution if somebody > can come up with the right names. Actually, of all the "weird" proposals made by Tim, I give the best chances to something like the "verb/adjective" distinction. At least this is a clear distinction, which does not depend on some trivial add-on that could or could not be there. But of course I can't propose any working scheme that looks reasonable... Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 22 20:01:25 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 22 Aug 1996 15:01:25 -0400 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. References: <199608220421.AAA22858@python.org> <321C768E.63D8@mit.edu> <321CB498.4F4A@ibs.ibs.fr> <321CAB75.2236@mit.edu> <321CBA6A.675E@ibs.ibs.fr> Message-ID: <321CAE85.5D9@mit.edu> Konrad Hinsen wrote: > > Jim Hugunin wrote: > > > > Konrad Hinsen wrote: > > > > > > Jim Hugunin wrote: > > > > > > > > I really don't think that a complete set of both function should be > > > > provided. The great value in this proposal is it lets me define the > > > > "proper" default axis for each function without fear of people not being > > > > able to remember which one that is. > > > > > > That supposes that the naming convention is easier to remember than > > > the default axis, which is not obvious to me. I can imagine people > > > wondering whether the correct function is fft or fft_. > > > > I'd argue here that if you can remember that fft operates on the -1 > > axis, you can remember that all functions that operate by default on the > > -1 axis have an underscore after them (which by the way is not a naming > > convention I find reasonable). > > I agree, but such a naming convention is useful if it is *easier* > to remember, not just as easy. This I disagree with. The advantage of the naming convention (provided one can be discovered) is that you get an error if you remember incorrectly rather than getting a strange array back. This to me is REALLY important. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Marko Balabanovic Thu Aug 22 20:12:43 1996 From: Marko Balabanovic (Marko Balabanovic) Date: Thu, 22 Aug 96 12:12:43 PDT Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. In-Reply-To: Your message of Thu, 22 Aug 1996 15:01:25 -0400 Message-ID: > Konrad Hinsen wrote: > > > > Jim Hugunin wrote: > > > > > > Konrad Hinsen wrote: > > > > > > > > Jim Hugunin wrote: > > > > > > > > > > I really don't think that a complete set of both function should be > > > > > provided. The great value in this proposal is it lets me define the > > > > > "proper" default axis for each function without fear of people not being > > > > > able to remember which one that is. > > > > > > > > That supposes that the naming convention is easier to remember than > > > > the default axis, which is not obvious to me. I can imagine people > > > > wondering whether the correct function is fft or fft_. > > > > > > I'd argue here that if you can remember that fft operates on the -1 > > > axis, you can remember that all functions that operate by default on the > > > -1 axis have an underscore after them (which by the way is not a naming > > > convention I find reasonable). > > > > I agree, but such a naming convention is useful if it is *easier* > > to remember, not just as easy. > > This I disagree with. The advantage of the naming convention (provided > one can be discovered) is that you get an error if you remember > incorrectly rather than getting a strange array back. This to me is > REALLY important. > Don't forget there are two people involved, the writer of the code and potentially the reader. Of course the reader might just be the writer 3 months later after he/she has forgotten everything about it. The naming convention might still involve work on the writers part, looking in the manual to see whether it is fft or fft_ or whatever (or extra debugging when the exception occurs if the wrong function name is used). However once the reader has learned the simple rule, then the code should be much more obvious to understand. Marko .Marko Balabanovic.......Department of Computer Science.................... .Stanford University Email: marko@cs.stanford.edu Office: Gates 132 . .Gates Building 1A Phone: 415 725 8783 Fax: 415 725 1449 . .Stanford CA 94305-9010 Url: http://robotics.stanford.edu/people/marko . .USA....................................................................... ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 22 20:41:04 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Thu, 22 Aug 1996 14:41:04 -0500 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. In-Reply-To: <321C768E.63D8@mit.edu> (message from Jim Hugunin on Thu, 22 Aug 1996 11:02:38 -0400) Message-ID: <199608221939.PAA24675@python.org> Following up on my last post: after thinking about it some more, I'm beginning to like the parts of speech convention for structural vs. non-strucural ops better (but implemented differently). So I'll throw out a proposal for your dismemberment.... ________________________________ Proposal: All structural operation names will be present tense verbs (e.g., run, walk, skip; not walked, tree, overThere). The names of sort, and argSort will be changed to sorted and argSorted since sort is both a verb and a noun. ________________________________ This leads to: structural: concatenate, reduce, take, repeat, choose, reduce, accumulate, reduceAt, compress non-structural: sorted, argSorted, diagonal, trace, dot, sum, product, cumSum, cumProduct, allTrue, someTrue, fft ________________________________ Things that don't agree with the current defaults. ------------------------------------------------- diagonal, trace: These are diagonals, not axes. However, I would argue that the current default is wrong; the default should be the last diagonal, not the first. So, this does make sense. sum, product, cumSum, cumProduct: I think these would make sense with a default of -1, instead of zero. (As I think Jim alluded to in an earlier post...) allTrue, someTrue: ???? ________________________________ I was going to write more, but I think I'll throw this into the ring now since there seems to be some interest. -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 23 17:19:20 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 23 Aug 1996 12:19:20 -0400 Subject: [PYTHON MATRIX-SIG] Simple Questions... References: <199608231533.LAA06169@maigret> Message-ID: <321DDA08.46F0@mit.edu> I know I'm violating nettiquette by forwarding personal mail to the list, but given the recent trend towards esoteric discussion on the list, I thought that this might help encourage people to ask simple questions. My apologies to David. :-) David Ascher wrote: > > In the numeric package, is there a way to go from > > a = array([1,2,2,1,2]) > > via something like a.indices(2) ==> (1,2,4) ? > > [by extension to the index() method on lists]. > > I get lost between select, choose, etc. >>> from Numeric import * >>> a = array([1,2,2,1,2]) >>> nonzero(equal(a,2)) 1 2 4 equal will return an array that is one everywhere the arrays are equal and zero everywhere else. nonzero will return the indices of those elements in the array which are non-zero. (nonzero is implemented using repeat, but you shouldn't really need to know that). -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Mon Aug 26 03:20:38 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Sun, 25 Aug 1996 21:20:38 -0500 Subject: [PYTHON MATRIX-SIG] Some thoughts on default axes. In-Reply-To: <199608221939.PAA24675@python.org> (tim@lassi.ece.uiuc.edu) Message-ID: <199608260218.WAA03183@python.org> Following up on my last post (again) about distinguishing structural operations from non-structural operations based on their parts of speach. I did some research into how well this would work. I sent my proposal to a friend with no knowledge of Python and asked him to sort the NumPy operations into structural and non-structural operations based on the rule in my proposal: >Proposal: All structural operation names will be present tense verbs >(e.g., run, walk, skip; not walked, tree, overThere). The names of >sort, and argSort will be changed to sorted and argSorted since sort >is both a verb and a noun. The results were a disaster! Both my rule and the names of the operations were much more ambiguous than I had suspected. (There are far too many words that are both verbs and nouns...). I did some fine tuning of the rule, and made some changes to the names of some operations. I then repeated my experiment with two more individuals. This time I had more success. Between the two of them only one operation was identified wrongly (reduceAt) and it was misidentified only one. Once again these individuals had no prior knowledge on Numerical Python (or Python for that matter). My conclusion is that this would probably be a viable way to distinguish between structural and non-structural operations. Here are some possible areas of concern: o The rule is might be too complicated to remember (I don't think so, but I've been looking at it too much to know.) o Esthetics (again). Below is the rule and list of operation names that I sent out. I've marked the changed operation names with *s. A (clumsily worded) mnemonic for this set of rules is 'Structural operations ACT (->p.t. verb phrases) on the structure the matrix,, while non-structural operations return OBJECTS (->other phrases) derived from the matrix.' What do people think of this? Does this make it sufficently easy to determine which kind of operation each name corresponds to? Is fftOf too ugly to live? Also, do people agree or disagree with the way I've reassigned the default axes/diagonals of trace, diagonal, and product and its ilk? >o Structural operation names are be present tense verbs phrases > such as walk, runOver, fly. >o Non-Structural operation names are all other phrases (e.g., > car, walkedOn). >o If a word is both a noun and a verb treat it as a verb. > >Which of the following are structural and which are non-structural: >(Just tack on a NSO or SO after each operation name). > >allTrue >sorted * >diagonal >cumProduct >concatenate >dotProd * >take >argSorted * >repeat >choose >reduce >someTrue >summation * >accumulate >product >traceOf * >reduceAt >compress >cumSummation * >fftOf * > >(cum stands for cummulative) -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Tue Aug 27 20:55:57 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 27 Aug 96 20:55:57 +0100 Subject: [PYTHON MATRIX-SIG] LinearAlgebra.py Message-ID: <199608271859.UAA25754@ibs.ibs.fr> I remember that several people have worked on adapting my LinearAlgebra.py to the new function set, but I can't access my archive now. Would anyone be so kind as to send me a copy? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Wed Aug 28 23:34:38 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Wed, 28 Aug 1996 18:34:38 -0400 Subject: [PYTHON MATRIX-SIG] Just checking in Message-ID: <9608282232.AA26365@goldilocks.LCS.MIT.EDU> Just to keep people posted. I have the alpha3 release almost ready to go, I'm waiting on a few issues that need to be thought out. 1) Naming conventions/default axes 2) Dynamic linking (problems on many architectures) If you have any opinions on the whole naming conventions/default axis issue that has been recently discussed I'd like to hear them. I still haven't found a proposal that I like better than my current version: All default axes are 0 Functions like fft, sort, argmax, ... should generally be called with an explicit axis specification of -1. ie. fft(wave, axis=-1). This explicit axis specification is only necessary when working on 2 or more dimensional arrays. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Thu Aug 29 04:18:23 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Wed, 28 Aug 1996 23:18:23 -0400 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: Your message of "Wed, 28 Aug 1996 18:34:38 EDT." <9608282232.AA26365@goldilocks.LCS.MIT.EDU> References: <9608282232.AA26365@goldilocks.LCS.MIT.EDU> Message-ID: <199608290318.XAA20736@monty> > 2) Dynamic linking (problems on many architectures) What is the nature of these problems? I believe that Python 1.4beta3 supports dynamic linking on most architectures. (BTW for NT I had to replace the static initialization of the type pointers in type objects with dynamic initializations -- no big deal, one of those linker limitations where one bows to Microsoft -- although perhaps compiling with C++ would have helped too.) --Guido ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 29 09:53:01 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 29 Aug 96 09:53:01 +0100 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608290318.XAA20736@monty> (message from Guido van Rossum on Wed, 28 Aug 1996 23:18:23 -0400) Message-ID: <199608290756.JAA03305@ibs.ibs.fr> > > 2) Dynamic linking (problems on many architectures) > > What is the nature of these problems? I believe that Python 1.4beta3 supports > dynamic linking on most architectures. (BTW for NT I had to replace the As for HP systems, I am reasonably convinced that the problem with NumPy alpha2 is the fake module "libnumpy". After a careful study of the HP documentation, I conclude that there are two ways to use shared libraries: 1) Explicit loading, which is what Python does when importing a module. 2) Linking with a shared library, which is then loaded as soon as one of its functions is called. This works only if the shared library is in the same place as it was during linking. (Other systems, e.g. SGI, let the user specify a search path for this case.) NumPy uses the second method for libnumpy (which contains arrayobject.o and ofuncobject.o), but after installation it must fail. A possible solution would be to make libnumpy a real importable module and import it from the modules that need it. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Thu Aug 29 11:57:18 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Thu, 29 Aug 1996 12:57:18 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <9608282232.AA26365@goldilocks.LCS.MIT.EDU> References: <9608282232.AA26365@goldilocks.LCS.MIT.EDU> Message-ID: <199608291057.MAA21061@nu> >>>>> "JH" == Jim Hugunin writes: JH> Dynamic linking (problems on many architectures) So I felt pressed to at least try dynamic linking once. The effect: 1) I have to "make" instead of "make dynamic", because I need the changed sys.path with ".../numeric" in there. 2) nu[208]test%% python sieve.py Traceback (innermost last): File "sieve.py", line 2, in ? from Numeric import * File "/nu1/hooft/lib/python1.4/numeric/Numeric.py", line 4, in ? import multiarray ImportError: dlopen: cannot load /nu1/hooft/lib/python1.4/sharedmodules/multiarraymodule.so I think I'll go back to static. Unfortunately I'm not an expert on dl on DecUnix 4.0, so I don't expect to be of any more help... Rob. -- === Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ == ==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/ Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ==== == PGPid 0xFA19277D == Use Linux! Free Software Rules The World! ============= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Thu Aug 29 14:48:36 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Thu, 29 Aug 1996 09:48:36 -0400 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: Your message of "Thu, 29 Aug 1996 09:53:01 BST." <199608290756.JAA03305@ibs.ibs.fr> References: <199608290756.JAA03305@ibs.ibs.fr> Message-ID: <199608291348.JAA24669@monty> > As for HP systems, I am reasonably convinced that the problem with > NumPy alpha2 is the fake module "libnumpy". After a careful study of > the HP documentation, I conclude that there are two ways to use > shared libraries: > > 1) Explicit loading, which is what Python does when importing > a module. > > 2) Linking with a shared library, which is then loaded as soon as > one of its functions is called. This works only if the shared > library is in the same place as it was during linking. (Other > systems, e.g. SGI, let the user specify a search path for this > case.) > > NumPy uses the second method for libnumpy (which contains > arrayobject.o and ofuncobject.o), but after installation it must fail. This makes sense after all. Unless libNumPy.sl is placed in one of the standard places where the linker looks for shared libraries, it will need some strong hints. It could be that this problem doesn't occur on Solaris because the linker will look in the same directory where the referring shared library is coming from. However, if I read the "ld" man page right for HP-UX, the "+b" option should let you specify a list of directories to search for shared libraries at run-time. It may be that this information only gets used when building the main executable, in which case you can specify a SHLIB_PATH environment variable pointing to the directory containing libNumPy.sl (see the +s option). > A possible solution would be to make libnumpy a real importable > module and import it from the modules that need it. Yes, that's another approach. The Object/cobject.c file contains a little-known trick to make this easier. However I'm not sure it's worth it, assuming this problem is HP specific. The environment variable trick seems okay. (Note that in 1.4b3 you can use os.putenv() to modify the real environment of the current process, so you could even hide this in a wrapper written in Python!) --Guido van Rossum (home page: http://www.python.org/~guido/) ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 29 15:01:01 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Thu, 29 Aug 1996 09:01:01 -0500 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608290756.JAA03305@ibs.ibs.fr> (message from Konrad Hinsen on Thu, 29 Aug 96 09:53:01 +0100) Message-ID: <199608291359.JAA23575@python.org> >> > 2) Dynamic linking (problems on many architectures) >> >> What is the nature of these problems? I believe that Python 1.4beta3 supports >> dynamic linking on most architectures. (BTW for NT I had to replace the > >As for HP systems, I am reasonably convinced that the problem with >NumPy alpha2 is the fake module "libnumpy". After a careful study of >the HP documentation, I conclude that there are two ways to use >shared libraries: On Linux 1.2.13, libnumpy also gave me some problems. It turned out it had to go in /usr/lib, not /usr/local/lib. This I discovered by trial and error, not by a thorough (or any for that matter) study of the documentation ;) This is the error I was getting before moving libnumpy. Is this the error that most people are getting when the dynamic loading doesn't work? >>> import Numeric Traceback (innermost last): File "", line 1, in ? File "/usr/local/lib/python1.4/numeric/Numeric.py", line 4, in ? import multiarray ImportError: File not found >>> -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 29 16:18:33 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 29 Aug 96 16:18:33 +0100 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608291348.JAA24669@monty> (message from Guido van Rossum on Thu, 29 Aug 1996 09:48:36 -0400) Message-ID: <199608291421.QAA05615@ibs.ibs.fr> > However, if I read the "ld" man page right for HP-UX, the "+b" option > should let you specify a list of directories to search for shared > libraries at run-time. It may be that this information only gets used Right, but unless all systems have such a feature, we should better not rely on it. > when building the main executable, in which case you can specify a > SHLIB_PATH environment variable pointing to the directory containing > libNumPy.sl (see the +s option). I don't like using such global variables. I definitely would not like to install and maintain two packages that both manipulate this environment variable! Just imagine wanting to install two different versions of Python (say, 1.4 and 1.5 ;-) on the same system. > variable trick seems okay. (Note that in 1.4b3 you can use > os.putenv() to modify the real environment of the current process, so > you could even hide this in a wrapper written in Python!) That sounds a lot more attractive to me. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 29 16:05:01 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 29 Aug 96 16:05:01 +0100 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <9608282232.AA26365@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu) Message-ID: <199608291408.QAA05489@ibs.ibs.fr> > If you have any opinions on the whole naming conventions/default axis issue > that has been recently discussed I'd like to hear them. I still haven't > found a proposal that I like better than my current version: > > All default axes are 0 > Functions like fft, sort, argmax, ... should generally be called with an > explicit axis specification of -1. ie. fft(wave, axis=-1). This explicit > axis specification is only necessary when working on 2 or more dimensional > arrays. I still think that a two-class system (structural functions with a default axis of zero, others with a default of 1) is the better solution. But I mainly write to express dissatisfaction with the way dot() works now. I have been doing some matrix work recently, and not being able to use dot() for matrix multiplication is a real nuisance. I ended up redefining dot() to be LinAlg._dot2, which is exactly the kind of thing to be avoided. So unless someone can give a good argument (preferably based on a real-life application) that dot() should behave as it does now, I propose that dot() should act along axis -1 of its first and axis 0 of its second argument. This is the right choice for scalar products, matrix-vector multiplication, and matrix-matrix multiplication. I think these are more frequent than list-of-vector scalar products. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From Rob.Hooft@embl-heidelberg.de Thu Aug 29 16:50:06 1996 From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de) Date: Thu, 29 Aug 1996 17:50:06 +0200 (MET DST) Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608291408.QAA05489@ibs.ibs.fr> References: <9608282232.AA26365@goldilocks.LCS.MIT.EDU> <199608291408.QAA05489@ibs.ibs.fr> Message-ID: <199608291550.RAA22455@nu> >>>>> "KH" == Konrad Hinsen writes: >> All default axes are 0 Functions like fft, sort, argmax, >> ... should generally be called with an explicit axis specification >> of -1. ie. fft(wave, axis=-1). This explicit axis specification >> is only necessary when working on 2 or more dimensional arrays. KH> I still think that a two-class system (structural functions with KH> a default axis of zero, others with a default of 1) is the better KH> solution. I agree that it might be a bit of a nuisance to give "axis" arguments. But I prefer readability over writability myself, and the difference between structural versus other functions is not clear to me yet.... KH> But I mainly write to express dissatisfaction with the way dot() KH> works now. I have been doing some matrix work recently, and not KH> being able to use dot() for matrix multiplication is a real KH> nuisance. I ended up redefining dot() to be LinAlg._dot2, which KH> is exactly the kind of thing to be avoided. Why don't you define a MatrixMultiply routine that calls LinAlg._dot2? You don't need to redefine dot, do you? Rob -- === Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ == ==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/ Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ==== == PGPid 0xFA19277D == Use Linux! Free Software Rules The World! ============= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From sean@embl-grenoble.fr Thu Aug 29 17:16:39 1996 From: sean@embl-grenoble.fr (Sean Mcsweeney) Date: Thu, 29 Aug 1996 18:16:39 +0200 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608291408.QAA05489@ibs.ibs.fr> References: <9608282232.AA26365@goldilocks.LCS.MIT.EDU> <199608291408.QAA05489@ibs.ibs.fr> Message-ID: <199608291616.SAA08967@classic.embl-grenoble.fr> Konrad Hinsen writes: > > If you have any opinions on the whole naming conventions/default axis issue > > that has been recently discussed I'd like to hear them. I still haven't > > found a proposal that I like better than my current version: > > > > All default axes are 0 > > Functions like fft, sort, argmax, ... should generally be called with an > > explicit axis specification of -1. ie. fft(wave, axis=-1). This explicit > > axis specification is only necessary when working on 2 or more dimensional > > arrays. > > I still think that a two-class system (structural functions with a > default axis of zero, others with a default of 1) is the better > solution. > My solution would be to let the function determin the default axis -- if the functions natural usage is axis=0, then this should be the default, or otherwise as appropriate. by natural I mean if 99 times out of 100 I will use super_whizzo(A,B,C, axis=0) I don't see why I should type the axis =0 part just because its **possible** I may want axis=-1 , the one other time. and/or some default has specified that this is an axis=-1 function. Of course the implementation would document the functionality rather better than the above ;-) S ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From jim.fulton@digicool.com Thu Aug 29 17:20:48 1996 From: jim.fulton@digicool.com (Jim Fulton) Date: Thu, 29 Aug 1996 12:20:48 -0400 Subject: [PYTHON MATRIX-SIG] Just checking in References: <199608290756.JAA03305@ibs.ibs.fr> <199608291348.JAA24669@monty> Message-ID: <3225C360.C00@digicool.com> Guido van Rossum wrote: > > > As for HP systems, I am reasonably convinced that the problem with > > NumPy alpha2 is the fake module "libnumpy". After a careful study of > > the HP documentation, I conclude that there are two ways to use > > shared libraries: > > > > 1) Explicit loading, which is what Python does when importing > > a module. > > > > 2) Linking with a shared library, which is then loaded as soon as > > one of its functions is called. This works only if the shared > > library is in the same place as it was during linking. (Other > > systems, e.g. SGI, let the user specify a search path for this > > case.) > > > > NumPy uses the second method for libnumpy (which contains > > arrayobject.o and ofuncobject.o), but after installation it must fail. > > This makes sense after all. Unless libNumPy.sl is placed in one of > the standard places where the linker looks for shared libraries, it > will need some strong hints. It could be that this problem doesn't > occur on Solaris because the linker will look in the same directory > where the referring shared library is coming from. > > However, if I read the "ld" man page right for HP-UX, the "+b" option > should let you specify a list of directories to search for shared > libraries at run-time. It may be that this information only gets used > when building the main executable, in which case you can specify a > SHLIB_PATH environment variable pointing to the directory containing > libNumPy.sl (see the +s option). But all of this is alot of work. What's worse, it's work for the user, rather than the author of a module. The user has to remember to set some goofy environment variable because of some arcane detail of how a program was built. Yuck. > > > A possible solution would be to make libnumpy a real importable > > module and import it from the modules that need it. > > Yes, that's another approach. The Object/cobject.c file contains a > little-known trick to make this easier. However I'm not sure it's > worth it, assuming this problem is HP specific. No, the problem occurs on DG and DEC too, but the details vary from system to system, just to make things interesting. 8-[ It's a real hassle, which is why I came up with the cobject type. I'll admit, that for a large C API, cobject could be quite a hassle. I'd hoped to put something together for the numerics stuff, but haven't had time, and with my current job, have less motivation. > The environment > variable trick seems okay. (Note that in 1.4b3 you can use > os.putenv() to modify the real environment of the current process, so > you could even hide this in a wrapper written in Python!) putenv helps, but tha hack will have to be system dependent. I think it would be much better to "import" the interface. I'm sorry I can't help out more. One more point, I suspect that in many cases, it might be just as easy to use the Python Numeric API from C. I hope to do this for FIDL. Jim > ================= > MATRIX-SIG - SIG on Matrix Math for Python > > send messages to: matrix-sig@python.org > administrivia to: matrix-sig-request@python.org > ================= -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.python.org/ ## ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 29 18:45:02 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 29 Aug 96 18:45:02 +0100 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608291616.SAA08967@classic.embl-grenoble.fr> (message from Sean Mcsweeney on Thu, 29 Aug 1996 18:16:39 +0200) Message-ID: <199608291648.SAA06569@ibs.ibs.fr> > Konrad Hinsen writes: >... > > I still think that a two-class system (structural functions with a > > default axis of zero, others with a default of 1) is the better > > solution. > > > > My solution would be to let the function determin the default axis -- if > the functions natural usage is axis=0, then this should be the > default, or otherwise as appropriate. That comes down to the same as my proposal. Konrad -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 29 19:25:04 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 29 Aug 96 19:25:04 +0100 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608291550.RAA22455@nu> (Rob.Hooft@embl-heidelberg.de) Message-ID: <199608291728.TAA06720@ibs.ibs.fr> > KH> But I mainly write to express dissatisfaction with the way dot() > KH> works now. I have been doing some matrix work recently, and not > KH> being able to use dot() for matrix multiplication is a real > KH> nuisance. I ended up redefining dot() to be LinAlg._dot2, which > KH> is exactly the kind of thing to be avoided. > > Why don't you define a MatrixMultiply routine that calls LinAlg._dot2? > You don't need to redefine dot, do you? I am using this interactively, so "MatrixMultiply" has no chance. I redefined dot() because to me this is what dot() should do, and I have no use at all for the standard dot(). I like to type something sensible, even interactively. Of course I am not saying that I can't live with the current version of dot(). But unless someone can give arguments why the current version is *better* (or at least as good), I stick to my proposal. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From tim@lassi.ece.uiuc.edu Thu Aug 29 19:32:26 1996 From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu) Date: Thu, 29 Aug 1996 13:32:26 -0500 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608291728.TAA06720@ibs.ibs.fr> (message from Konrad Hinsen on Thu, 29 Aug 96 19:25:04 +0100) Message-ID: <199608291846.OAA24515@python.org> KH writes: >I am using this interactively, so "MatrixMultiply" has no chance. I >redefined dot() because to me this is what dot() should do, and I have >no use at all for the standard dot(). I like to type something >sensible, even interactively. > >Of course I am not saying that I can't live with the current version >of dot(). But unless someone can give arguments why the current >version is *better* (or at least as good), I stick to my proposal. I would argue that dot should act on axes (-1,-1), i.e. it should dot the vector that compose the array's together. Isn't matrix multiplication the same as the inner product for matrices, so couldn't you use define a convenience function inner(A,B) for this? Or am I off in LA LA land here? -- -tim +--------------------------------------------------------------------+ | Tim Hochberg Ultrahigh Speed Digital Electronics Lab | | tim@lassi.ece.uiuc.edu University of Illinois | | http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 | +--------------------------------------------------------------------+ ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Thu Aug 29 20:35:28 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Thu, 29 Aug 96 20:35:28 +0100 Subject: [PYTHON MATRIX-SIG] Just checking in In-Reply-To: <199608291831.UAA06945@ibs.ibs.fr> (tim@lassi.ece.uiuc.edu) Message-ID: <199608291838.UAA06964@ibs.ibs.fr> > I would argue that dot should act on axes (-1,-1), i.e. it should dot > the vector that compose the array's together. Why? What is the frequent application for which such a definition is useful? Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From stjohn@gav.gat.com Thu Aug 29 22:32:25 1996 From: stjohn@gav.gat.com (Holger St. John) Date: Thu, 29 Aug 1996 13:32:25 -0800 Subject: [PYTHON MATRIX-SIG] dynamic linking And Linux Message-ID: <199608292032.QAA24833@python.org> There may be something more than just the location of the libnumpy module involved in dynamic linking under Linux (1.2.13). The reason I say this is that I have both dynamic and static versions of Numerical Python running on my 90Mhz Pentium box. The static version runs sieve and test_all without a problem. The dynamic version (I used make dynamic) runs the sieve script ok (in 17 secs. incidentally). However when I run test_all I get the (by now) infamous "module not found: Integer" Since the static version works it must be that Integer is a built in module? Other people must be having this problem ? Holger St. John General Atomics ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Thu Aug 29 21:55:17 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Thu, 29 Aug 1996 16:55:17 -0400 Subject: [PYTHON MATRIX-SIG] dynamic linking And Linux Message-ID: <9608292053.AA07160@goldilocks.LCS.MIT.EDU> > There may be something more than just the location of the libnumpy > module involved in dynamic linking under Linux (1.2.13). The reason > I say this is that I have both dynamic and static versions of Numerical > Python running on my 90Mhz Pentium box. The static version runs sieve and > test_all without a problem. The dynamic version (I used make dynamic) > runs the sieve script ok (in 17 secs. incidentally). However when I run > test_all I get the (by now) infamous > "module not found: Integer" This is a completely different bug in the test_all.py module. I have an Integer.py file on my machine that I forgot to include in the distribution. If you remove the import Integer from the top of test_all.py (or maybe test_items.py) this problem will go away. Please tell me if the dynamic version works for you with this small fix. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From K.Maguire@dl.ac.uk Fri Aug 30 20:14:10 1996 From: K.Maguire@dl.ac.uk (Kevin Maguire) Date: Fri, 30 Aug 1996 20:14:10 +0100 (BST) Subject: [PYTHON MATRIX-SIG] NumericalPython Message-ID: Hi When I requested the archive for this SIG I only received messages up until the end of May, why is this ?? Has nothing been posted since then ??? Okay, I ftp'd and installed python1.4beta3 and NumPy-1.0a2 (which took a bit of finding) on my DEC Alpha running V3.0 of OSF1 (now renamed Digital Unix). The core python installation went reasonably smoothly, and I followed the instructions in INSTALL and Makefile.pre.in to add the Numerical support (why no make install in this package ?? ). However running the tests gives an error: % ../python -iv test_all.py ... ... ... array([[1, 66], [66, 12]], 'l') array([0, 1, 2, 3, 4, 5], 'l') TypeError: compare not supported for type Traceback (innermost last): File "test_all.py", line 42, in ? test_lines(fp.readlines()) File "test_all.py", line 22, in test_lines raise ValueError, "%s doesn't match expected %s" % (last_out, line[1:-1]) ValueError: TypeError: compare not supported for type doesn't match expected array([5, 3, 1, 0, 4, 2], 'l') I don't really know this is about. I went on and installed anyway, copying the .py files Lib/* to /usr/local/lib/python1.4/numeric/ (which 'strings python' told me was built into the executable somewhere, I missed any documentation that explained what to do to 'install' the new enhanced (?) python? I then ran through the tutorial: http://maigret.cog.brown.edu/Python/Documentation/arraytut.html Some things work, others don't. For example: >>> from Numeric import * >>> x,y,z = 1,2,3 >>> a = array([x,y,z]) >>> a 1 2 3 >>> a = array([x,y,z], Float()) Traceback (innermost last): File "", line 1, in ? TypeError: call of non-function >>> and >>> ma = array([[1,2,3],[4,5,6],[7,8,9]]) >>> ma 1 2 3 4 5 6 7 8 9 >>> ma.shape (3, 3) >>> flattened_ma = ma.reshape(9) Traceback (innermost last): File "", line 1, in ? AttributeError: reshape >>> Several other functions didn't work properly, zeros, ones, etc being examples. So either I've done something wrong in the install, or I'm missing something. Please enlighten me .... Cheers Kevin -- Kevin Maguire __ __ __ __ Daresbury Laboratory K.Maguire@dl.ac.uk / \ / \ / \ / \ Warrington, Cheshire, UK ____________________/ __\/ __\/ __\/ __\_____________________________ ___________________/ /__/ /__/ /__/ /________________________________ | / \ / \ / \ / \ \____ voice: (01925) 603221 |/ \_/ \_/ \_/ \ o \ FAX: (01925) 603634 \_____/--< ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From K.Maguire@dl.ac.uk Fri Aug 30 20:14:10 1996 From: K.Maguire@dl.ac.uk (Kevin Maguire) Date: Fri, 30 Aug 1996 20:14:10 +0100 (BST) Subject: [PYTHON MATRIX-SIG] NumericalPython Message-ID: Hi When I requested the archive for this SIG I only received messages up until the end of May, why is this ?? Has nothing been posted since then ??? Okay, I ftp'd and installed python1.4beta3 and NumPy-1.0a2 (which took a bit of finding) on my DEC Alpha running V3.0 of OSF1 (now renamed Digital Unix). The core python installation went reasonably smoothly, and I followed the instructions in INSTALL and Makefile.pre.in to add the Numerical support (why no make install in this package ?? ). However running the tests gives an error: % ../python -iv test_all.py ... ... ... array([[1, 66], [66, 12]], 'l') array([0, 1, 2, 3, 4, 5], 'l') TypeError: compare not supported for type Traceback (innermost last): File "test_all.py", line 42, in ? test_lines(fp.readlines()) File "test_all.py", line 22, in test_lines raise ValueError, "%s doesn't match expected %s" % (last_out, line[1:-1]) ValueError: TypeError: compare not supported for type doesn't match expected array([5, 3, 1, 0, 4, 2], 'l') I don't really know this is about. I went on and installed anyway, copying the .py files Lib/* to /usr/local/lib/python1.4/numeric/ (which 'strings python' told me was built into the executable somewhere, I missed any documentation that explained what to do to 'install' the new enhanced (?) python? I then ran through the tutorial: http://maigret.cog.brown.edu/Python/Documentation/arraytut.html Some things work, others don't. For example: >>> from Numeric import * >>> x,y,z = 1,2,3 >>> a = array([x,y,z]) >>> a 1 2 3 >>> a = array([x,y,z], Float()) Traceback (innermost last): File "", line 1, in ? TypeError: call of non-function >>> and >>> ma = array([[1,2,3],[4,5,6],[7,8,9]]) >>> ma 1 2 3 4 5 6 7 8 9 >>> ma.shape (3, 3) >>> flattened_ma = ma.reshape(9) Traceback (innermost last): File "", line 1, in ? AttributeError: reshape >>> Several other functions didn't work properly, zeros, ones, etc being examples. So either I've done something wrong in the install, or I'm missing something. Please enlighten me .... Cheers Kevin -- Kevin Maguire __ __ __ __ Daresbury Laboratory K.Maguire@dl.ac.uk / \ / \ / \ / \ Warrington, Cheshire, UK ____________________/ __\/ __\/ __\/ __\_____________________________ ___________________/ /__/ /__/ /__/ /________________________________ | / \ / \ / \ / \ \____ voice: (01925) 603221 |/ \_/ \_/ \_/ \ o \ FAX: (01925) 603634 \_____/--< ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 30 21:20:16 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 30 Aug 1996 16:20:16 -0400 Subject: [PYTHON MATRIX-SIG] Default Axes revisited Message-ID: <9608302018.AA17769@goldilocks.LCS.MIT.EDU> I'm been thinking a lot about all the responses (both public and private) I've gotten on the default axis issue. I have a new proposal for a naming convention (I think Tim already proposed something very similar to this, but...) As Konrad rightly suggested at the beginning: Structural Operations have a default axis of 0 Numeric/Computational Operations have a default axis of -1 However, because I don't think it's always obvious what's a structural and what's a numeric operation, all numeric operations will have a "_" after their name. So we have: take, concatenate, ... argmax_, sort_, argsort_, fft_, ... I will also probably define functions of the form: def argmax(x,y=None): raise AttributeError, "argmax is a Numeric function, use argmax_" in order to help out complete newbie's. Is everybody reasonably happy with this? - Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 30 21:13:07 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 30 Aug 1996 16:13:07 -0400 Subject: [PYTHON MATRIX-SIG] NumericalPython Message-ID: <9608302011.AA17714@goldilocks.LCS.MIT.EDU> I need to look into the archive to figure out what's wrong. There bit a little ;-) traffic on this group since then. My personal guess is that we've managed to collectively overflow some archive size limit. The latest release of NumPy is always announced on this list, so it is easy to find if you were subscribed when the last version came out. The error during testing is interesting and probably a 64-bit long quirk. I'll look into it. The other problems that you have are due to the fact that the Tutorial is way out of date. Many function names and calling conventions have been changed since the Tutorial was written (based on 0.36). The file "doc.html" should be up to date as far as naming conventions are concerned. There is still one outstanding naming/calling convention that could lead to a few more such changes before the beta1 release (after which time I won't subject people to further major incompatible changes). I'm guessing that David Ascher is waiting to update his Tutorial until this final issue is resolved (see my next post). BTW - Did you make the static or the dynamic version? I'm very interested to learn about people's experiences building the dynamic system under DEC OSF (or Digital Unix). -Jim ---------- > From: Kevin Maguire > To: matrix-sig@larch.python.org > Subject: [PYTHON MATRIX-SIG] NumericalPython > Date: Friday, August 30, 1996 3:14 PM > > Hi > > When I requested the archive for this SIG I only received messages up > until the end of May, why is this ?? Has nothing been posted since > then ??? > > Okay, I ftp'd and installed python1.4beta3 and NumPy-1.0a2 (which took > a bit of finding) on my DEC Alpha running V3.0 of OSF1 (now renamed > Digital Unix). The core python installation went reasonably smoothly, > and I followed the instructions in INSTALL and Makefile.pre.in to add > the Numerical support (why no make install in this package ?? ). > > However running the tests gives an error: > > % ../python -iv test_all.py > ... > ... > ... > array([[1, 66], [66, 12]], 'l') > array([0, 1, 2, 3, 4, 5], 'l') > TypeError: compare not supported for type > Traceback (innermost last): > File "test_all.py", line 42, in ? > test_lines(fp.readlines()) > File "test_all.py", line 22, in test_lines > raise ValueError, "%s doesn't match expected %s" % (last_out, > line[1:-1]) > ValueError: TypeError: compare not supported for type doesn't match > expected array([5, 3, 1, 0, 4, 2], 'l') > > I don't really know this is about. I went on and installed anyway, > copying the .py files Lib/* to /usr/local/lib/python1.4/numeric/ > (which 'strings python' told me was built into the executable > somewhere, I missed any documentation that explained what to do to > 'install' the new enhanced (?) python? > > I then ran through the tutorial: > > http://maigret.cog.brown.edu/Python/Documentation/arraytut.html > > Some things work, others don't. For example: > > >>> from Numeric import * > >>> x,y,z = 1,2,3 > >>> a = array([x,y,z]) > >>> a > 1 2 3 > >>> a = array([x,y,z], Float()) > Traceback (innermost last): > File "", line 1, in ? > TypeError: call of non-function > >>> > > and > > >>> ma = array([[1,2,3],[4,5,6],[7,8,9]]) > >>> ma > 1 2 3 > 4 5 6 > 7 8 9 > >>> ma.shape > (3, 3) > >>> flattened_ma = ma.reshape(9) > Traceback (innermost last): > File "", line 1, in ? > AttributeError: reshape > >>> > > Several other functions didn't work properly, zeros, ones, etc being > examples. So either I've done something wrong in the install, or I'm > missing something. Please enlighten me .... > > Cheers > Kevin > -- > Kevin Maguire __ __ __ __ Daresbury Laboratory > K.Maguire@dl.ac.uk / \ / \ / \ / \ Warrington, Cheshire, UK > ____________________/ __\/ __\/ __\/ __\_____________________________ > ___________________/ /__/ /__/ /__/ /________________________________ > | / \ / \ / \ / \ \____ voice: (01925) 603221 > |/ \_/ \_/ \_/ \ o \ FAX: (01925) 603634 > \_____/--< > > > ================= > MATRIX-SIG - SIG on Matrix Math for Python > > send messages to: matrix-sig@python.org > administrivia to: matrix-sig-request@python.org > ================= ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From pas@lems.brown.edu Fri Aug 30 22:33:45 1996 From: pas@lems.brown.edu (Perry A. Stoll) Date: Fri, 30 Aug 1996 17:33:45 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] Default Axes revisited In-Reply-To: <9608302018.AA17769@goldilocks.LCS.MIT.EDU> Message-ID: On Fri, 30 Aug 1996, Jim Hugunin wrote: > Structural Operations have a default axis of 0 > Numeric/Computational Operations have a default axis of -1 Sounds good to me. I recently understood this and completely agree. Does this mean that all functions that can operate on different axes will have an "axis" keyword? > However, because I don't think it's always obvious what's a structural and > what's a numeric operation, all numeric operations will have a "_" after > their name. > > So we have: > > take, concatenate, ... > argmax_, sort_, argsort_, fft_, ... > > I will also probably define functions of the form: > > def argmax(x,y=None): > raise AttributeError, "argmax is a Numeric function, use argmax_" But these imposter functions should exactly the same signature as their shadowed brethren. (Just checking - wouldn't there be an "axis" keyword as per the question above?) > Is everybody reasonably happy with this? - Jim Reasonably. -Perry ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From da@maigret.cog.brown.edu Fri Aug 30 22:37:51 1996 From: da@maigret.cog.brown.edu (David Ascher) Date: Fri, 30 Aug 1996 17:37:51 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] Default Axes revisited In-Reply-To: <9608302018.AA17769@goldilocks.LCS.MIT.EDU> from "Jim Hugunin" at Aug 30, 96 04:20:16 pm Message-ID: <199608302137.RAA21569@maigret> > Structural Operations have a default axis of 0 > Numeric/Computational Operations have a default axis of -1 > > However, because I don't think it's always obvious what's a structural and > what's a numeric operation, all numeric operations will have a "_" after > their name. Ugh. Not underscores again. I don't like this at all. I'd much rather go for something more explicit, like: do_sort, do_argmax, do_argsort, do_fft or: doSort, doArgmax, doArgsort, doFft or: sortOf, argmaxOf, argsortOf, fftOf or any combination thereof which at least can be *read* easily. Otherwise we will end up with: def __numericprivatefunc_(foo, bar):... someday, which I'd hate to explain to any newbie... =) --da ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 30 22:39:13 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 30 Aug 1996 17:39:13 -0400 Subject: [PYTHON MATRIX-SIG] Default Axes revisited Message-ID: <9608302137.AA18483@goldilocks.LCS.MIT.EDU> > On Fri, 30 Aug 1996, Jim Hugunin wrote: > > > Structural Operations have a default axis of 0 > > Numeric/Computational Operations have a default axis of -1 > > > Sounds good to me. I recently understood this and completely agree. Does > this mean that all functions that can operate on different axes will have > an "axis" keyword? Definately. > > However, because I don't think it's always obvious what's a structural and > > what's a numeric operation, all numeric operations will have a "_" after > > their name. > > > > So we have: > > > > take, concatenate, ... > > argmax_, sort_, argsort_, fft_, ... > > > > I will also probably define functions of the form: > > > > def argmax(x,y=None): > > raise AttributeError, "argmax is a Numeric function, use argmax_" > > But these imposter functions should exactly the same signature as their > shadowed brethren. (Just checking - wouldn't there be an "axis" keyword > as per the question above?) argmax takes a single argument. y=None is my way of handling the default axis argument. I will use the word axis there in the real version. > > Is everybody reasonably happy with this? - Jim > > Reasonably. If I can get all interested parties to say that I'll be happy. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From klm@CNRI.Reston.Va.US Fri Aug 30 22:33:50 1996 From: klm@CNRI.Reston.Va.US (Ken Manheimer) Date: Fri, 30 Aug 1996 17:33:50 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] NumericalPython In-Reply-To: <9608302011.AA17714@goldilocks.LCS.MIT.EDU> Message-ID: Jim Hugunin: > I need to look into the archive to figure out what's wrong. There bit a > little ;-) traffic on this group since then. My personal guess is that > we've managed to collectively overflow some archive size limit. > > > From: Kevin Maguire > > > > When I requested the archive for this SIG I only received messages up > > until the end of May, why is this ?? Has nothing been posted since > > then ??? I'm looking into this (barry's out today), and from what i can tell the archive is intact, and the whole thing is being delivered. I did notice that my MUA (pine) behaves rather strangely - in a way that would account exactly for the impression kevin had. Pine sees only 582 message, up to one dated May 8, with that last message holding the remaining 250 or so messages. Solaris 'mailx' seems to do a better job parsing the mail file - 821 messages, and the dates reported look good. (Reports lots of Content-length errors, though, parsing it.) Kevin, take a look at the mail file with a browser that lets you get to the bottom easily, like 'less', or 'vi' (if it'll hold 2MB), and see if the missing messages are really there, please... Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From da@maigret.cog.brown.edu Fri Aug 30 22:33:24 1996 From: da@maigret.cog.brown.edu (David Ascher) Date: Fri, 30 Aug 1996 17:33:24 -0400 (EDT) Subject: [PYTHON MATRIX-SIG] NumericalPython In-Reply-To: <9608302011.AA17714@goldilocks.LCS.MIT.EDU> from "Jim Hugunin" at Aug 30, 96 04:13:07 pm Message-ID: <199608302133.RAA21519@maigret> > There is still one outstanding naming/calling convention that could lead to > a few more such changes before the beta1 release (after which time I won't > subject people to further major incompatible changes). I'm guessing that > David Ascher is waiting to update his Tutorial until this final issue is > resolved (see my next post). That's right. I figure once I get the feeling that things like the axis and names are settled, I'll update the tutorial. --da ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hugunin@mit.edu Fri Aug 30 22:39:13 1996 From: hugunin@mit.edu (Jim Hugunin) Date: Fri, 30 Aug 1996 17:39:13 -0400 Subject: [PYTHON MATRIX-SIG] Default Axes revisited Message-ID: <9608302137.AA18483@goldilocks.LCS.MIT.EDU> > On Fri, 30 Aug 1996, Jim Hugunin wrote: > > > Structural Operations have a default axis of 0 > > Numeric/Computational Operations have a default axis of -1 > > > Sounds good to me. I recently understood this and completely agree. Does > this mean that all functions that can operate on different axes will have > an "axis" keyword? Definately. > > However, because I don't think it's always obvious what's a structural and > > what's a numeric operation, all numeric operations will have a "_" after > > their name. > > > > So we have: > > > > take, concatenate, ... > > argmax_, sort_, argsort_, fft_, ... > > > > I will also probably define functions of the form: > > > > def argmax(x,y=None): > > raise AttributeError, "argmax is a Numeric function, use argmax_" > > But these imposter functions should exactly the same signature as their > shadowed brethren. (Just checking - wouldn't there be an "axis" keyword > as per the question above?) argmax takes a single argument. y=None is my way of handling the default axis argument. I will use the word axis there in the real version. > > Is everybody reasonably happy with this? - Jim > > Reasonably. If I can get all interested parties to say that I'll be happy. -Jim ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From hinsen@ibs.ibs.fr Sat Aug 31 09:31:04 1996 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Sat, 31 Aug 96 09:31:04 +0100 Subject: [PYTHON MATRIX-SIG] Default Axes revisited In-Reply-To: <9608302018.AA17769@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu) Message-ID: <199608310734.JAA14456@ibs.ibs.fr> > I will also probably define functions of the form: > > def argmax(x,y=None): > raise AttributeError, "argmax is a Numeric function, use argmax_" I don't think that this is a good idea. People who write argmax() would get an exception anyway, although with a somewhat less clear explanation. On the other hand, those who use dir() to check out available functions (or those who use a yet-to-be-written function browser) would be lead to believe that there actually *is* a function argmax. If you want to help newbies, put a explanatory sentence in boldface after every paragraph in the documentation... > Is everybody reasonably happy with this? - Jim Otherwise, yes. I am not terribly excited by the underscores, but of all the proposals I have seen, they still look like the smallest evil. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28 Institut de Biologie Structurale | Fax: +33-76.88.54.94 41, Ave. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Sat Aug 31 17:09:54 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Sat, 31 Aug 1996 12:09:54 -0400 Subject: [PYTHON MATRIX-SIG] Default Axes revisited In-Reply-To: Your message of "Sat, 31 Aug 1996 09:31:04 BST." <199608310734.JAA14456@ibs.ibs.fr> References: <199608310734.JAA14456@ibs.ibs.fr> Message-ID: <199608311609.MAA02239@monty> > I don't think that this is a good idea. People who write argmax() > would get an exception anyway, although with a somewhat less > clear explanation. On the other hand, those who use dir() to check > out available functions (or those who use a yet-to-be-written > function browser) would be lead to believe that there actually > *is* a function argmax. If you want to help newbies, put a > explanatory sentence in boldface after every paragraph in the > documentation... Amen. --Guido ================= MATRIX-SIG - SIG on Matrix Math for Python send messages to: matrix-sig@python.org administrivia to: matrix-sig-request@python.org =================