From Jack.Jansen@cwi.nl Fri May 1 10:39:10 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 01 May 1998 11:39:10 +0200 Subject: [Matrix-SIG] Re: [Pythonmac-SIG] plplot on the Mac In-Reply-To: Message by Just van Rossum , Thu, 30 Apr 1998 22:11:47 +0200 , Message-ID: > I'd say, use the Python approach, which is to put a file containing an alias > pointing to the lib into the preferences folder. That way, if the user moves > the lib folder to a different location on the same volume, the alias will > still > point to the correct place. See the Python sources and EditPythonPrefs.py for > examples on how to do that. And have a look at the Mac preferences.py module (which is used by EditPythonPrefs), which has a nice interface to preferences files with default values taken from other places. The only problem is it isn't documented yet:-( -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From alawhead@vcn.bc.ca Tue May 5 05:17:43 1998 From: alawhead@vcn.bc.ca (Alexander Lawhead) Date: Mon, 4 May 1998 21:17:43 -0700 (PDT) Subject: [Matrix-SIG] Win95 version of Konrad Hinsen's netcdfmodule? Message-ID: I was wondering if anyone out there has a dll of Konrad Hinsen's netcdf module that will work with Python 1.5.1 / NumPy 1.1? Alexander From landrum@HAL9000.ac.rwth-aachen.de Tue May 5 14:32:55 1998 From: landrum@HAL9000.ac.rwth-aachen.de (Gregory A. Landrum) Date: Tue, 5 May 1998 15:32:55 +0200 (CEST) Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) Message-ID: Now that I'm about to embark on a new programming project, I think I can justify spending some time getting more comfortable with Python and NumPy. Before I do this though, I have a couple of question. Question 1: I need more bits and pieces from LAPACK than what comes with the NumPY 1.1 tarball I pulled down from LLNL yesterday. More specifically, I need all the eigenvalue/vector routines. Even more specifically, I need the ones that deal with the generalized eigenvalue problem. (e.g. zhegv, zheev and their relatives). [Ideally, since one can never be sure which numerical problems lie on the horizon, I'd have access to all of lapack... but this is clearly a vast amount of work.] I looked and looked, but I couldn't find anything that looked like it did what I need. So... my question is: "Has anyone already done a wrapper for more of lapack than what shows up in lapack_lite?" If the answer is "no", then I'll do it. Poking through the stuff that came with NumPy, it looks like it would be "reasonably straightforward." (I love learning things by jumping straight into the guts). Question 2: In a happy world, I could arrange for NumPy to use vendor supplied libraries rather than the generic versions which come with it. This would be a particularly large win for things like BLAS and LAPACK. So, for example, on my AIX machines, I'd like to use (as much as possible) IBM's BLAS implementations as well as ESSL. Here's where Konrad Hinsen's warning on the SIG about a PPro optimized BLAS has me worried: "Unfortunately the necessary compilation and linking steps are not totally trivial" I can deal with nontrivial, but I would like to know if there is some documentation about how to do things like this anywhere. Thanks (in advance) for your help, and thanks for providing NumPy to the community. -greg --------------------- Dr. Greg Landrum (landrum@hal9000.ac.rwth-aachen.de) Institute of Inorganic Chemistry Aachen University of Technology Prof.-Pirlet-Str. 1, D-52074 Aachen, Germany Phone: 049-241-80-7004 Fax: 049-241-8888-288 http://www.rwth-aachen.de/iac/Ww/group/landrum/root.html From gathmann@scar.utoronto.ca Tue May 5 15:09:15 1998 From: gathmann@scar.utoronto.ca (Oliver Gathmann) Date: Tue, 5 May 1998 10:09:15 -0400 (EDT) Subject: [Matrix-SIG] possible bug in NumPy Message-ID: Hi all, I think I found what looks like a bug in NumPy (I am not up to date with the very latest release, but I don't remember this coming up here before): Python 1.5 (#3, Feb 12 1998, 12:14:31) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Numeric import * >>> a = array([[1,1],[2,2]]) >>> b = array([[1.1,1.1],[2.1,2.1]]) >>> c = array([[0.1,0.1],[0.1,0.1]]) >>> abs(a-b) array([[0.1,0.1], [0.1,0.1]]) >>> less_equal(abs(a-b),c) array([[0, 0], [0, 0]]) >>> less_equal(c,abs(a-b)) array([[1, 1], [1, 1]]) Shouldn't that be 'all true' in both cases since abs(a-b) and c are the same thing? Oliver Oliver Gathmann (gathmann@scar.utoronto.ca) Surface and Groundwater Ecology Research Group University of Toronto phone: (416) - 287 7420 ; fax: (416) - 287 7423 From R.Hooft@EuroMail.com Tue May 5 15:47:21 1998 From: R.Hooft@EuroMail.com (Rob Hooft) Date: Tue, 5 May 1998 16:47:21 +0200 (MET DST) Subject: [Matrix-SIG] possible bug in NumPy In-Reply-To: References: Message-ID: <199805051447.QAA24741@nu> OG> >>>abs(a-b) OG> array([[0.1,0.1], OG> [0.1,0.1]]) OG> >>>less_equal(abs(a-b),c) OG> array([[0, 0], OG> [0, 0]]) >>> abs(a-b)-c array([[ 8.32667268e-17, 8.32667268e-17], [ 8.32667268e-17, 8.32667268e-17]]) i.e. They are not equal, and the Numpy comparison answers are correct. Never rely on equality of floating point numbers if they are the result of a computation. Regards, -- ===== R.Hooft@EuroMail.com http://www.Sander.EMBL-Heidelberg.DE/rob/ == ===== R&D, Nonius BV, Delft http://www.nonius.com/ == ===== PGPid 0xFA19277D ========================== Use Linux! ================== From Paul F. Dubois" Numerical calculations are almost never precise, so testing for equality is not often the right thing to do. To continue your calculation: >>> d=abs(a-b) >>> d array([[ 0.1, 0.1], [ 0.1, 0.1]]) >>> d-c array([[ 8.32667268e-017, 8.32667268e-017], [ 8.32667268e-017, 8.32667268e-017]]) >>> -----Original Message----- From: Oliver Gathmann To: matrix-sig@python.org Date: Tuesday, May 05, 1998 7:26 AM Subject: [Matrix-SIG] possible bug in NumPy >Hi all, > >I think I found what looks like a bug in NumPy (I am not up to date with >the very latest release, but I don't remember this coming up here before): > >Python 1.5 (#3, Feb 12 1998, 12:14:31) [GCC 2.7.2.3] on linux2 >Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>>> from Numeric import * >>>> a = array([[1,1],[2,2]]) >>>> b = array([[1.1,1.1],[2.1,2.1]]) >>>> c = array([[0.1,0.1],[0.1,0.1]]) >>>> abs(a-b) >array([[0.1,0.1], > [0.1,0.1]]) >>>> less_equal(abs(a-b),c) >array([[0, 0], > [0, 0]]) >>>> less_equal(c,abs(a-b)) >array([[1, 1], > [1, 1]]) > >Shouldn't that be 'all true' in both cases since abs(a-b) and c are the >same thing? > >Oliver > >Oliver Gathmann (gathmann@scar.utoronto.ca) >Surface and Groundwater Ecology Research Group >University of Toronto >phone: (416) - 287 7420 ; fax: (416) - 287 7423 > > > >------------------------------------------------------ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From zcm@llnl.gov Tue May 5 17:30:46 1998 From: zcm@llnl.gov (Zane Motteler) Date: Tue, 5 May 1998 08:30:46 -0800 Subject: [Matrix-SIG] possible bug in NumPy In-Reply-To: Message-ID: Hi Oliver, You wrote: >I think I found what looks like a bug in NumPy (I am not up to date with >the very latest release, but I don't remember this coming up here before): > >Python 1.5 (#3, Feb 12 1998, 12:14:31) [GCC 2.7.2.3] on linux2 >Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>>> from Numeric import * >>>> a = array([[1,1],[2,2]]) >>>> b = array([[1.1,1.1],[2.1,2.1]]) >>>> c = array([[0.1,0.1],[0.1,0.1]]) >>>> abs(a-b) >array([[0.1,0.1], > [0.1,0.1]]) >>>> less_equal(abs(a-b),c) >array([[0, 0], > [0, 0]]) >>>> less_equal(c,abs(a-b)) >array([[1, 1], > [1, 1]]) It's not a bug. The problem is that .1 decimal gives a repeating mantissa in binary (.000110001100011...) and of course cannot be exactly represented in floating point format, which is finite in length. 1.0001100011... will have one less bit right of the binary point, and 10.0001100011... will have two less, than .0001100011... so when you subtract off the integer part, the remaining fractions will not be equal. This is a hardware, not a software, "feature." Cheers Zane ----------------------------------------------------------------- Zane C. Motteler, Ph. D. Computer Scientist | Professor Emeritus of Lawrence Livermore National | Computer Science and Engineering Laboratory | California Polytechnic P. O. Box 808, L-38 **NOTE** | State University (7000 East Avenue, zip 94550) | San Luis Obispo, CA 93407 Livermore, CA 94551-9900 | zmottel@phoenix.csc.calpoly.edu 925/423-2143, FAX 423-9969 (NOTE AREA CODE CHANGE!!) zcm@llnl.gov From Paul F. Dubois" It is probably straight-forward to use SWIG to do this wrapping. I haven't received any such wrapping to date. Ideally one would not supply ANY version of LAPACK with NumPy. The convenience is nice, but it is almost certain that our copy will get out of date or not be as efficient as a more "official" source. The unfortunate fact that compiling and loading, especially for dynamic packages, is not bullet-proof, complicates the situation. I imagine, however, that if you are experienced at building Python extensions on your platform that you should have no real trouble removing the unwanted part of the distribution and linking to a library. The package does include instructions on how to make the package, including a Setup file you can modify. -----Original Message----- From: Gregory A. Landrum To: matrix-sig@python.org Date: Tuesday, May 05, 1998 6:41 AM Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) > >Now that I'm about to embark on a new programming >project, I think I can justify spending some time >getting more comfortable with Python and NumPy. > >Before I do this though, I have a couple of question. > >Question 1: >I need more bits and pieces from LAPACK than what >comes with the NumPY 1.1 tarball I pulled down from >LLNL yesterday. More specifically, I need all the >eigenvalue/vector routines. >Even more specifically, I need the ones that deal with >the generalized eigenvalue problem. (e.g. zhegv, zheev >and their relatives). >[Ideally, since one can never be sure which numerical >problems lie on the horizon, I'd have access to all >of lapack... but this is clearly a vast amount of >work.] >I looked and looked, but I couldn't find anything that >looked like it did what I need. So... my question is: >"Has anyone already done a wrapper for more of lapack >than what shows up in lapack_lite?" If the answer is >"no", then I'll do it. Poking through the stuff that >came with NumPy, it looks like it would be "reasonably >straightforward." (I love learning things by jumping >straight into the guts). > >Question 2: >In a happy world, I could arrange for NumPy to use >vendor supplied libraries rather than the generic >versions which come with it. This would be a particularly >large win for things like BLAS and LAPACK. So, for >example, on my AIX machines, I'd like to use (as much >as possible) IBM's BLAS implementations as well as ESSL. >Here's where Konrad Hinsen's warning on the SIG about >a PPro optimized BLAS has me worried: >"Unfortunately the necessary compilation and linking steps are >not totally trivial" >I can deal with nontrivial, but I would like to know if >there is some documentation about how to do things like >this anywhere. > >Thanks (in advance) for your help, and thanks >for providing NumPy to the community. > >-greg > > >--------------------- >Dr. Greg Landrum (landrum@hal9000.ac.rwth-aachen.de) >Institute of Inorganic Chemistry >Aachen University of Technology >Prof.-Pirlet-Str. 1, D-52074 Aachen, Germany >Phone: 049-241-80-7004 Fax: 049-241-8888-288 >http://www.rwth-aachen.de/iac/Ww/group/landrum/root.html > > >------------------------------------------------------ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From tim_one@email.msn.com Tue May 5 16:57:53 1998 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 5 May 1998 11:57:53 -0400 Subject: [Matrix-SIG] possible bug in NumPy In-Reply-To: Message-ID: <000001bd783e$904cce20$dc4f2399@tim> [Oliver Gathmann] > ... > I think I found what looks like a bug in NumPy (I am not up > to date with the very latest release, but I don't remember > this coming up here before): I haven't yet made time to get NumPy at all, but believe I can shed some painful light regardless . > Python 1.5 (#3, Feb 12 1998, 12:14:31) [GCC 2.7.2.3] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> from Numeric import * > >>> a = array([[1,1],[2,2]]) > >>> b = array([[1.1,1.1],[2.1,2.1]]) > >>> c = array([[0.1,0.1],[0.1,0.1]]) > >>> abs(a-b) > array([[0.1,0.1], > [0.1,0.1]]) > >>> less_equal(abs(a-b),c) > array([[0, 0], > [0, 0]]) > >>> less_equal(c,abs(a-b)) > array([[1, 1], > [1, 1]]) > > Shouldn't that be 'all true' in both cases since abs(a-b) and c are > the same thing? *If* they were the same thing, yes. But forget arrays for a moment: Python 1.5.1 (#0, Apr 13 1998, 20:22:04) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> x = 1.1 - 1 >>> y = .1 >>> x <= y, y <= x (0, 1) I.e., the same thing happens for scalars. >>> x == y 0 >>> x - y 8.32667268469e-017 I.e., floating-point roundoff caught you in the last bit -- neither .1 nor 1.1 are exactly representable as doubles, so y isn't actually one tenth, and while "1.1 - 1" suffers no roundoff error, the double version of "1.1" wasn't actually one and one tenth to begin with either (and loses approximately the last 3 bits of the approximation to .1 in order to "make room for" the leading 1). Clearer? I don't know what you should *do* about it in NumPy, but someone else here will -- this kind of problem has existed since the first floating-point computation ever done . what-you-see-isn't-always-what-you-get-ly y'rs - tim From landrum@HAL9000.ac.rwth-aachen.de Tue May 5 17:10:25 1998 From: landrum@HAL9000.ac.rwth-aachen.de (Gregory A. Landrum) Date: Tue, 5 May 1998 18:10:25 +0200 (CEST) Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) In-Reply-To: <001501bd783a$472e60e0$998a7380@pduboispc.llnl.gov> Message-ID: On Tue, 5 May 1998, Paul F. Dubois wrote: > It is probably straight-forward to use SWIG to do this wrapping. I haven't > received any such wrapping to date. I'll look at that. I was just reading through the SWIG docs this afternoon. > Ideally one would not supply ANY version of LAPACK with NumPy. The I think there's an argument for supplying something small and simple, just to get people started. > convenience is nice, but it is almost certain that our copy will get out of > date or not be as efficient as a more "official" source. The unfortunate This (efficiency) is certainly true. Particularly since most (all?) of the commercial unix vendors provide at least partial implementations which tend to be rather highly optimized for their platforms. > I imagine, however, that if you are experienced at building Python > extensions on your platform that you should have no real trouble removing > the unwanted part of the distribution and linking to a library. The package > does include instructions on how to make the package, including a Setup file > you can modify. Yeah, after sending my question, I decided to go rooting around in the code to see what was what. It does look fairly easy to patch in my own local BLAS implementation. Well, it will be after I add something to fix the fact that the lapack_lite distribution has hardcoded _'s on the ends of fortran subroutine names. This inconsistency is the biggest PITA in using Fortran and C together. Thanks again, -greg From da@skivs.ski.org Tue May 5 17:24:09 1998 From: da@skivs.ski.org (David Ascher) Date: Tue, 5 May 1998 09:24:09 -0700 (PDT) Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) In-Reply-To: Message-ID: On Tue, 5 May 1998, Gregory A. Landrum wrote: > This (efficiency) is certainly true. Particularly since most > (all?) of the commercial unix vendors provide at least partial > implementations which tend to be rather highly optimized > for their platforms. Keep in mind that it's relatively important to have something like the functionality of LinearAlgebra.py for platforms which do *not* provide free LAPACK, such as win32, MacOS and Linux... Also, I suspect many Unix customers don't have the $$'s to spend on LAPACK -- last I looked, SGI charged an arm and a leg for these things. That said, if you want to make it possible to do *more* if your platform provides more, far from me to stop you! --david From drh@hawkeye.cis.usouthal.edu Tue May 5 18:13:16 1998 From: drh@hawkeye.cis.usouthal.edu (Douglas R. Heisterkamp) Date: Tue, 5 May 1998 12:13:16 -0500 (CDT) Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) In-Reply-To: Message-ID: On Tue, 5 May 1998, Gregory A. Landrum wrote: ... > Yeah, after sending my question, I decided to go rooting around > in the code to see what was what. It does look fairly easy to > patch in my own local BLAS implementation. Well, it will be > after I add something to fix the fact that the lapack_lite > distribution has hardcoded _'s on the ends of fortran subroutine > names. This inconsistency is the biggest PITA in using Fortran > and C together. > define NO_APPEND_FORTRAN when compiling and the _'s will not be appended to the fortran names. A pre-lapacklite version of an interface to all of lapack may be found at ftp://ftp.cs.unl.edu/pub/drh/python/ I have not update that version in quite a while. Doug From KaliazinA@cardiff.ac.uk Tue May 5 20:08:34 1998 From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin) Date: Tue, 5 May 1998 20:08:34 +0100 Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) Message-ID: <004901bd7859$3b539dc0$8f16fb83@nedo.c305.cf.ac.uk> -----Original Message----- From: Douglas R. Heisterkamp To: Gregory A. Landrum Cc: matrix-sig@python.org Date: 05 May 1998 19:22 Subject: Re: [Matrix-SIG] Quick... Duck! (or: YA Newbie) >... >A pre-lapacklite version of an interface to all of lapack may be found at >ftp://ftp.cs.unl.edu/pub/drh/python/ > >I have not update that version in quite a while. > >Doug Recently Konrad Hinsen made some significant changes in this package, but not published it. Ask him for sources, or if he is unavailable I can send you C-files. (I yet failed to use it on win32, some functions used to crash Python, but at least they can be compiled and loaded...:) Andy From Paul F. Dubois" As you know, I just took NumPy over and haven't had much time to work on it. We have our own technology for dealing with different Fortran naming/calling conventions wrt. C, and I suppose that in the longer term I will have to get that sort of thing into the NumPy picture. -----Original Message----- From: Gregory A. Landrum To: Paul F. Dubois Cc: matrix-sig@python.org Date: Tuesday, May 05, 1998 9:08 AM Subject: Re: [Matrix-SIG] Quick... Duck! (or: YA Newbie) >On Tue, 5 May 1998, Paul F. Dubois wrote: > >> It is probably straight-forward to use SWIG to do this wrapping. I haven't >> received any such wrapping to date. > >I'll look at that. I was just reading through the SWIG docs this >afternoon. > >> Ideally one would not supply ANY version of LAPACK with NumPy. The > >I think there's an argument for supplying something >small and simple, just to get people started. > >> convenience is nice, but it is almost certain that our copy will get out of >> date or not be as efficient as a more "official" source. The unfortunate > >This (efficiency) is certainly true. Particularly since most >(all?) of the commercial unix vendors provide at least partial >implementations which tend to be rather highly optimized >for their platforms. > >> I imagine, however, that if you are experienced at building Python >> extensions on your platform that you should have no real trouble removing >> the unwanted part of the distribution and linking to a library. The package >> does include instructions on how to make the package, including a Setup file >> you can modify. > >Yeah, after sending my question, I decided to go rooting around >in the code to see what was what. It does look fairly easy to >patch in my own local BLAS implementation. Well, it will be >after I add something to fix the fact that the lapack_lite >distribution has hardcoded _'s on the ends of fortran subroutine >names. This inconsistency is the biggest PITA in using Fortran >and C together. > >Thanks again, >-greg > > > From Paul F. Dubois" I was making NumPy-1.2 to go with Python-1.5.1 and to include a few small improvements. When I ran the "test_all.py" test it failed on the line that computes b[10:, :]. In this problem b is a 4 x 4 matrix so the intention is evidently to test some strange end case. In fact, the previous "problem" is b(10:), which returns zeros((0,4),'l'). (?) This section of the test is labeled "from Carlos". In my somewhat humble opinion both of these should have been "Index Error". Obviously, I'm not in the "in" group. Can someone fill me in? I would have sworn there was no such error before. Hmm. From aaron@cs.rutgers.edu Fri May 8 11:57:23 1998 From: aaron@cs.rutgers.edu (Aaron Watters) Date: Fri, 08 May 1998 06:57:23 -0400 Subject: [Matrix-SIG] a real bug in Numeric Message-ID: <3552E513.B94C9BE2@cs.rutgers.edu> I got the following non exception abort. a, m, s out of order in mltmod - ABORT! a = 784306273 s = 0 m = 2147483399 mltmod requires: 0 < a < m; 0 < s < m I mailed this to Konrad and he said it's from the RandomArray stuff. (Actually, I meant to mail it to this list, but I typed the address wrong, I remail, to get it archived and noted.) Numeric is real cool, but non-exception aborts are not cool, no, not cool at all... -- Aaron Watters ps: been having loads of fun cutting my teeth on Numeric (again) lately... thanks everyone! From busby@icf.llnl.gov Mon May 11 23:55:45 1998 From: busby@icf.llnl.gov (L. Busby) Date: Mon, 11 May 98 15:55:45 PDT Subject: [Matrix-SIG] ANNOUNCE: Dynamically linkable Python Gist now available Message-ID: <9805112255.AA08004@icf.llnl.gov.llnl.gov> Find a new version of our Python Gist package and related modules at ftp://ftp-icf.llnl.gov/pub/python/PyGist-13.tgz. This version does not include any significant code changes. It is repackaged to build and install against stock Python, version 1.5 or 1.5.1, as a dynamically linked module. Installing it will also require our NumPy-11 package, Yorick1.4, and X Windows release 4 or higher. From the README: The Python Gist Scientific Graphics Package, version 1.3, written by Lee Busby and Zane Motteler of Lawrence Livermore National Laboratory, is a set of Python modules for production of general scientific graphics. We abbreviate the name to PyGist here and elsewhere. Gist is a scientific graphics library written by David H. Munro of Lawrence Livermore National Laboratory. It features support for three common graphics output devices: X-Windows, (Color) PostScript, and ANSI/ISO Standard Computer Graphics Metafiles (CGM). The library is small (written directly to Xlib), portable, efficient, and full-featured. It produces x-vs-y plots with good tick marks and tick labels, 2-D quadrilateral mesh plots with contours, vector fields, or pseudocolor maps on such meshes, and a selection of 3-D plots. Lee Busby From carlosm@moet.cs.colorado.edu Tue May 12 01:26:53 1998 From: carlosm@moet.cs.colorado.edu (Carlos Maltzahn) Date: Mon, 11 May 1998 18:26:53 -0600 (MDT) Subject: [Matrix-SIG] ANNOUNCE: Dynamically linkable Python Gist now available In-Reply-To: <9805112255.AA08004@icf.llnl.gov.llnl.gov> Message-ID: Hmm - just tried it, it compiled and installed fine and then I get (DEC alpha, OSF1 $4.0 464, using cc): foobar:Demo[0] python gistdemolow.py Traceback (innermost last): File "gistdemolow.py", line 3, in ? from gist import * File "/home/ri/carlosm/extensions/LLNLDistribution/Graphics/Gist/Lib/gist.py", line 5, in ? from gistC import * ImportError: dlopen: cannot load /home/ri/carlosm/alpha+OSF1/lib/python1.5/site-packages/gistCmodule.so foobar:Demo[1] foobar:Demo[1] cd /home/ri/carlosm/alpha+OSF1/lib/python1.5/site-packages/ foobar:site-packages[0] ls -l gistCmodule.so -r-xr-xr-x 1 carlosm abelian 417792 May 11 18:02 gistCmodule.so* foobar:site-packages[0] file gistCmodule.so gistCmodule.so: COFF format alpha shared library, demand paged executable or object module not stripped - version 3.11-10 I installed Numeric in a similar fashion and it works. Any ideas what I'm missing? Carlos Carlos Maltzahn - http://www.cs.colorado.edu/~carlosm/ On Mon, 11 May 1998, L. Busby wrote: > Find a new version of our Python Gist package and related modules at > ftp://ftp-icf.llnl.gov/pub/python/PyGist-13.tgz. This version does not > include any significant code changes. It is repackaged to build and > install against stock Python, version 1.5 or 1.5.1, as a dynamically > linked module. Installing it will also require our NumPy-11 package, > Yorick1.4, and X Windows release 4 or higher. > From the README: > > The Python Gist Scientific Graphics Package, version 1.3, written by > Lee Busby and Zane Motteler of Lawrence Livermore National > Laboratory, is a set of Python modules for production of general > scientific graphics. We abbreviate the name to PyGist here and > elsewhere. > > Gist is a scientific graphics library written by David H. Munro of > Lawrence Livermore National Laboratory. It features support for three > common graphics output devices: X-Windows, (Color) PostScript, and > ANSI/ISO Standard Computer Graphics Metafiles (CGM). The library is > small (written directly to Xlib), portable, efficient, and > full-featured. It produces x-vs-y plots with good tick marks and tick > labels, 2-D quadrilateral mesh plots with contours, vector fields, or > pseudocolor maps on such meshes, and a selection of 3-D plots. > > Lee Busby > > _______________________________________________ > Matrix-SIG maillist - Matrix-SIG@python.org > http://www.python.org/mailman/listinfo/matrix-sig > From hinsen@ibs.ibs.fr Tue May 12 11:57:35 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 12 May 1998 12:57:35 +0200 Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) In-Reply-To: (drh@hawkeye.cis.usouthal.edu) Message-ID: <199805121057.MAA08256@lmspc1.ibs.fr> > A pre-lapacklite version of an interface to all of lapack may be found at > ftp://ftp.cs.unl.edu/pub/drh/python/ > > I have not update that version in quite a while. The interface routines require minor modifications to work with the latest NumPy. I have such a modified version, and I use it daily with Python 1.5.1, NumPy 1.1, and various versions of LAPACK, depending on the machine. If Doug and LLNL agree, the most useful solution would be to make this interface collection available from the LLNL server, together with NumPy. In the meantime, if anyone wants it, send me an e-mail... BTW, it would be nice to establish a collection of working Setup files for use with Fortran BLAS/LAPACK routines. I can provide everything for HP/UX 9, and I will soon work on an AIX version. I also have a Setup file for Linux (using a g77 compiled LAPACK). There are usually two problems with using a FORTRAN LAPACK: 1) Fortran-C interfacing is machine dependent. In addition to the "trailing-underscore-or-not" question, some machines require some library to be linked explicitly when Fortran code is called from a C program. 2) Building shared libraries for the LAPACK interface requires that LAPACK and BLAS are available either as shared libraries or at least as position-independent code. Of course details vary from machine to machine. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen@ibs.ibs.fr Tue May 12 12:41:34 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 12 May 1998 13:41:34 +0200 Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie) In-Reply-To: <001501bd783a$472e60e0$998a7380@pduboispc.llnl.gov> (dubois1@llnl.gov) Message-ID: <199805121141.NAA08359@lmspc1.ibs.fr> > Ideally one would not supply ANY version of LAPACK with NumPy. The > convenience is nice, but it is almost certain that our copy will get out of I'd say the convenience is essential. Most NumPy users I know would give it up instantly if they had to figure out how to use a Fortran LAPACK with NumPy on their machine. Ideally a configuration script would figure out if a LAPACK library exists and do what is necessary to use it, using the supplied C routines as a fallback only. Unfortunately that is a nontrivial problem. As an interim solution, we could collect working Setup files for various machines and ship them with NumPy. I suspect that renaming a Setup file is still within the capabilities of most users. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen@ibs.ibs.fr Tue May 12 12:51:50 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Tue, 12 May 1998 13:51:50 +0200 Subject: [Matrix-SIG] Background for test in NumPy? In-Reply-To: <000301bd7872$d354d940$998a7380@pduboispc.llnl.gov> (dubois1@llnl.gov) Message-ID: <199805121151.NAA08393@lmspc1.ibs.fr> > I was making NumPy-1.2 to go with Python-1.5.1 and to include a few small > improvements. When I ran the "test_all.py" test it failed on the line that > computes b[10:, :]. In this problem b is a 4 x 4 matrix so the intention is > evidently to test some strange end case. In fact, the previous "problem" is > b(10:), which returns zeros((0,4),'l'). (?) > > This section of the test is labeled "from Carlos". > > In my somewhat humble opinion both of these should have been "Index Error". > Obviously, I'm not in the "in" group. Can someone fill me in? The Python rules for slicing sequences are somewhat surprising here. Slicing *never* returns an IndexError. It returns a new sequence whose elements are defined by the intersection of what is available and what is asked for. For out of range indices, it therefore returns an empty sequence. So zeros((0,4)) is the correct return value in this case, both for b[10:] and b[10:,:]. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From bsd@scripps.edu Wed May 13 01:21:49 1998 From: bsd@scripps.edu (Bruce Duncan) Date: Tue, 12 May 1998 17:21:49 -0700 (PDT) Subject: [Matrix-SIG] min/max question and strange result Message-ID: With python 1.5 on an SGI, I get the following: >>> a = Numeric.array((-1,0,1)) >>> a array([-1, 0, 1]) >>> min(a) -1 >>> max(a) 1 >>> a.shape (3,) >>> a.shape = (3,1) >>> a array([[-1], [ 0], [ 1]]) >>> min(a) array([1]) >>> max(a) array([-1]) This seems odd. Why is [-1] greater than [1] ?? -bsd- Bruce Duncan The Scripps Research Institute bsd "is located at" scripps "in the domain" edu # anti spam... From zcm@llnl.gov Wed May 13 16:37:08 1998 From: zcm@llnl.gov (Zane Motteler) Date: Wed, 13 May 1998 07:37:08 -0800 Subject: [Matrix-SIG] min/max question and strange result In-Reply-To: Message-ID: Bruce, You wrote: >With python 1.5 on an SGI, I get the following: > >>>> a = Numeric.array((-1,0,1)) >>>> a >array([-1, 0, 1]) >>>> min(a) >-1 >>>> max(a) >1 >>>> a.shape >(3,) >>>> a.shape = (3,1) >>>> a >array([[-1], > [ 0], > [ 1]]) >>>> min(a) >array([1]) >>>> max(a) >array([-1]) > > >This seems odd. >Why is [-1] greater than [1] ?? If what you want is the maximum element of an array, no matter how many dimensions it has, then why not do max(ravel(a)) If you try max on any two dimensional array, the max is always the first row, and the min is always the last row, and don't ask me why. Zane ----------------------------------------------------------------- Zane C. Motteler, Ph. D. Computer Scientist | Professor Emeritus of Lawrence Livermore National | Computer Science and Engineering Laboratory | California Polytechnic P. O. Box 808, L-038 | State University Livermore, CA 94551-9900 | San Luis Obispo, CA 93407 925/423-2143, FAX 925/423-9969 | zmottel@phoenix.csc.calpoly.edu zcm@llnl.gov (For FedEx, UPS, etc. use street address 7000 East Avenue, zip 94550) From hinsen@ibs.ibs.fr Wed May 13 18:15:31 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Wed, 13 May 1998 19:15:31 +0200 Subject: [Matrix-SIG] Core dump with NumPy 1.1 and Python 1.5.1 on DEC Alpha Message-ID: <199805131715.TAA16499@lmspc1.ibs.fr> A colleague working on a DEC Alpha is trying to update his Python installation to 1.5.1 and NumPy 1.1. Everything compiles fine, but when he runs "python LinearAlgebra.py", the first test comes out very wrong, and then Python crashes. The same test works fine on any other machine I use, and also with Python 1.4 and the original NumPy on the same Alpha. Everything else in NumPy seems to work correctly, including FFT stuff. Is anyone else experiencing similar problems? I don't really know where to start looking for the reason. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen@ibs.ibs.fr Wed May 13 18:24:32 1998 From: hinsen@ibs.ibs.fr (Konrad Hinsen) Date: Wed, 13 May 1998 19:24:32 +0200 Subject: [Matrix-SIG] min/max question and strange result In-Reply-To: (message from Bruce Duncan on Tue, 12 May 1998 17:21:49 -0700 (PDT)) Message-ID: <199805131724.TAA16555@lmspc1.ibs.fr> > >>> a.shape = (3,1) > >>> a > array([[-1], > [ 0], > [ 1]]) > >>> min(a) > array([1]) > >>> max(a) > array([-1]) > > This seems odd. > Why is [-1] greater than [1] ?? That's a feature of Python's current comparison approach, which is under discussion in comp.lang.python at the moment. Currently Python defines an order between any objects, whether that makes sense or not. Object types that don't define their own sense of order (as the numbers do) are sorted according to their memory address. Lists are such data types, and arrays too. That's why you get surprising answers. If you want reaonsable behaviour for arrays, use NumPy functions, e.g. Numeric.maximum.reduce(a) to find the largest element. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28 Institut de Biologie Structurale | Fax: +33-4.76.88.54.94 41, av. des Martyrs | Deutsch/Esperanto/English/ 38027 Grenoble Cedex 1, France | Nederlands/Francais ------------------------------------------------------------------------------- From Warren Focke Wed May 13 19:31:09 1998 From: Warren Focke (Warren Focke) Date: Wed, 13 May 1998 14:31:09 -0400 (EDT) Subject: [Matrix-SIG] min/max question and strange result In-Reply-To: <199805131724.TAA16555@lmspc1.ibs.fr> Message-ID: On Wed, 13 May 1998, Konrad Hinsen wrote: >[bsd@scripps.edu] > > This seems odd. > > Why is [-1] greater than [1] ?? > > That's a feature of Python's current comparison approach, which is > under discussion in comp.lang.python at the moment. > > Currently Python defines an order between any objects, whether that > makes sense or not. Object types that don't define their own sense of > order (as the numbers do) are sorted according to their memory > address. Lists are such data types, and arrays too. That's why you get > surprising answers. > > If you want reaonsable behaviour for arrays, use NumPy functions, e.g. > Numeric.maximum.reduce(a) to find the largest element. NumPy does define it's own sense of order: >int array_compare(PyArrayObject *self, PyObject *other) { > /* I'd really like to raise an exception here, but I don't think >that's possible. */ > /* This sort of comparision doesn't make sense on arrays. */ > > return -1; >} but it's at least as surprising as comparison based on pointer value: >>> a=array([1]) >>> b=array([1]) >>> a>> b In arrayobject.c, parse_index's reference counting looks seriously broken to me. Look especially at the treatment of op1. There is a mysterious duplicate PySequence_GetItem call, and later a DECREF on op1 which has no matching INCREF in the case of a slice. I'm going to fix this but this is the sort of thing that seems so broken that I wonder if I know what I am dealing with. I'd appreciate reassurance that I'm correct in my understanding of this coding. From Paul F. Dubois" Well, I just figured out part of it; in the case of a slice n gets set to 1 so that the loop below only DECREF's once to cancel out the mysterious INCREF up above. Ugh. From bsd@scripps.edu Sun May 17 23:58:27 1998 From: bsd@scripps.edu (Bruce Duncan) Date: Sun, 17 May 1998 15:58:27 -0700 (PDT) Subject: [Matrix-SIG] Threads hanging with Python C extension modules Message-ID: Greetings, I'm having trouble with threads in Python using C extension modules. My experiments with threads calling pure python code (i.e., standard python modules) work fine. However, with our C extension modules (some with Swig, others by hand, most are compute-intensive) there is a problem. After starting the first thread, the "main" thread seems to hang and does not accept user typein until the first thread completes. Any clues about why this happens? -bsd- Bruce Duncan The Scripps Research Institute bsd "is located at" scripps "in the domain" edu # anti spam... From cgw@pgt.com Tue May 19 16:13:39 1998 From: cgw@pgt.com (Charles G Waldman) Date: Tue, 19 May 1998 11:13:39 -0400 (EDT) Subject: [Matrix-SIG] Numeric Python documentation Message-ID: <199805191513.LAA14925@reactor.pgt.com> What has happened to the HTML documentation for Numeric? The links off of www.python.org seem to point to a black hole... From da@skivs.ski.org Tue May 19 18:32:06 1998 From: da@skivs.ski.org (David Ascher) Date: Tue, 19 May 1998 10:32:06 -0700 (PDT) Subject: [Matrix-SIG] Numeric Python documentation In-Reply-To: <199805191513.LAA14925@reactor.pgt.com> Message-ID: On Tue, 19 May 1998, Charles G Waldman wrote: > > What has happened to the HTML documentation for Numeric? The links > off of www.python.org seem to point to a black hole... I'm not sure which links you're referring to, but the (out of date) tutorial is at: http://starship.skyport.net/~da/numtut/ --david From cgw@pgt.com Tue May 19 19:14:51 1998 From: cgw@pgt.com (Charles G Waldman) Date: Tue, 19 May 1998 14:14:51 -0400 (EDT) Subject: [Matrix-SIG] Numeric Python documentation In-Reply-To: References: <199805191513.LAA14925@reactor.pgt.com> Message-ID: <13665.52070.238165.957596@janus.pgt.com> David Ascher writes: > > I'm not sure which links you're referring to, but the (out of date) > tutorial is at: > > http://starship.skyport.net/~da/numtut/ > Thanks. I was referring to the page http://www.python.org/sigs/matrix-sig/ which has a pointer to "Numeric Python documentation", at the URL http://starship.skyport.net/~da/Python/Numeric/ Maybe somebody ought to update this? From Paul F. Dubois" There is a minimal document included in the distribution, in subdirectory Doc. I believe some version of this is the document the link was pointing at. I'm happy to announce that we have by some miracle completed the paperwork for LLNL to hire David as a consultant and one of his tasks is to write some better documentation for NumPy. So hang in there... -----Original Message----- From: Charles G Waldman To: David Ascher Cc: Charles G Waldman ; matrix-sig@python.org Date: Tuesday, May 19, 1998 11:29 AM Subject: Re: [Matrix-SIG] Numeric Python documentation >David Ascher writes: > > > > I'm not sure which links you're referring to, but the (out of date) > > tutorial is at: > > > > http://starship.skyport.net/~da/numtut/ > > > >Thanks. I was referring to the page >http://www.python.org/sigs/matrix-sig/ > >which has a pointer to "Numeric Python documentation", at the URL >http://starship.skyport.net/~da/Python/Numeric/ > >Maybe somebody ought to update this? > > > >_______________________________________________ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From h.jansen@math.tudelft.nl Wed May 27 16:19:55 1998 From: h.jansen@math.tudelft.nl (Henk Jansen) Date: Wed, 27 May 1998 17:19:55 +0200 Subject: [Matrix-SIG] UserArray Message-ID: <356C2F1B.7C35@math.tudelft.nl> It seems that the names of the UserArray.typecode() method and the UserArray.typecode data field are in conflict. This is encountered when a UserArray object is passed into the ArrayPrinter.array2string() function. Either name should change I believe. -- Henk Jansen hjansen@math.tudelft.nl Delft University of Technology Delft, The Netherlands Information Technoloy and Systems phone: +31(0)15.278.7295 Mathematics (ITS/TWI/TA/WAGM) fax: +31(0)15.278.7209 From Paul F. Dubois" I need some instructions on what to do about UserArray. There are several versions floating around. I don't know which one is the "right" one. I don't know how many users it has, etc. -----Original Message----- From: Henk Jansen To: matrix-sig@python.org Date: Wednesday, May 27, 1998 8:32 AM Subject: [Matrix-SIG] UserArray >It seems that the names of the UserArray.typecode() method >and the UserArray.typecode data field are in conflict. >This is encountered when a UserArray object is passed into >the ArrayPrinter.array2string() function. >Either name should change I believe. > >-- > Henk Jansen hjansen@math.tudelft.nl > Delft University of Technology Delft, The Netherlands > Information Technoloy and Systems phone: +31(0)15.278.7295 > Mathematics (ITS/TWI/TA/WAGM) fax: +31(0)15.278.7209 > >_______________________________________________ >Matrix-SIG maillist - Matrix-SIG@python.org >http://www.python.org/mailman/listinfo/matrix-sig > From dubois1@llnl.gov Wed May 27 18:13:43 1998 From: dubois1@llnl.gov (Paul F. Dubois) Date: Wed, 27 May 1998 10:13:43 -0700 Subject: [Matrix-SIG] ANNOUNCE: LLNLPython1 release Message-ID: <000601bd8992$ce01d8e0$52120f80@pduboispc.llnl.gov> On ftp://ftp-icf.llnl.gov/pub/python please find file LLNLPython1.tgz. This is a gzipped-tarball which contains all the source files for Python extensions currently maintained by LLNL. This includes Numerical, RNG, PyHistory, PyPDB, and the LLNL graphics suite based on Gist. Package RNG has been improved to add a log-normal distribution and to port it to the Mac. A binary installer for Windows 95/NT is available as RNG11.exe. Numerical has been ported to the Mac and has some minor bug fixes. It is not quite ready for release 1.2 as I am still hunting for some obscure bugs and have other things I want to do first, but you are welcome to use this version at your own risk if you know how to build from source. CXX is included and is currently somewhere past alpha 6 but also not an official release. I have done this rather than wait until everything was "perfect" as the difficulty in downloading the Current_release.tgz file is prohibitive from far away. I thought everyone would be better off having just our distribution files, now separate from the Python distribution. Current_release.tgz will be removed when I make the next release. I will number these releases LLNLPython1, 2, etc. Please report any problems to support@icf.llnl.gov. From aaron@cs.rutgers.edu Wed May 27 21:29:31 1998 From: aaron@cs.rutgers.edu (Aaron Watters) Date: Wed, 27 May 1998 16:29:31 -0400 Subject: [Matrix-SIG] ANN: Pysimplex Linear Programming Message-ID: <356C77AA.3EEF581A@cs.rutgers.edu> Sorry, I should have announced here first! Please give it a shot. And thanks to everyone involved in the Numpy project, again. ANNOUNCE PySimplex ================== Readers are asked to take a look at and maybe try out my newly released PySimplex beta Python modules for Linear Programming. This software is available for any purpose, provided as is with no warrantee. Please see the COPYRIGHT for details. http://www.pythonpros.com/arw/pysimplex Pysimplex provides some basic symbolic programming tools for constructing, solving and optimizing systems of linear equations and inequalities. It includes an implementation of the classical SIMPLEX linear optimization algorithm as well as a filter for parsing and optimizing linear models encoded using the standard MPS format. Perhaps the most compelling aspect of these modules is the way they allow the user or programmer to construct models in a straightforward symbolic manner. For example the following constraint model x>=1 and y>=1 and x+2*y-1.5 >= 0 and y-3*x-0.9 >= 0 may be constructed at the python command line as follows: >>> v = VariableNamer() >>> x,y = v.x, v.y >>> constraints = all_positive(v, x-1, y-1, x+2*y-1.5, y-3*x-0.9) and the following interaction computes the maximal value for the objective function -x-y within this system of constraints. >>> (sys, ob) = constraints.rsimplex(-x-y) >>> >>> sys({}) {'_free20': 7.3, 'x': 1.0, 'y': 3.9, '_free19': 2.9} Thus the maximum value for -x-y is achieved at x=1.0 and y=3.9. Requirements ============ This software requires Python and the Python Numeric extensions. Easy installations for Python and the Numeric extensions may be obtained via links starting at http://www.python.org for Windows 95, NT and many other platforms. -- Aaron Watters === Yet what are such gaieties to me Whose thoughts are full of indices and surds? x**2 + 7*x + 53 = 11/3 -- Lewis Carroll From ffjhl@aurora.alaska.edu Fri May 29 07:00:05 1998 From: ffjhl@aurora.alaska.edu (Jonah Lee) Date: Thu, 28 May 1998 22:00:05 -0800 (AKDT) Subject: [Matrix-SIG] Re: Core dump with NumPy 1.1 and Python 1.5.1 on DEC Alpha Message-ID: Hi, I just encountered the same problem. LinerAlgebra.py and inverse() etc. core dumped. I'm using Digital Unix 3.x. The same configuration works fine on two other Linux machines. Any help will be appreciated. Regards, Jonah