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 <just@letterror.com> ,
Thu, 30 Apr 1998 22:11:47 +0200 , <l03102801b16e8935dc3b@[193.78.237.44]>
Message-ID: <UTC199805010939.LAA10143.jack@snelboot.cwi.nl>
> 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: <Pine.GSO.3.95.980504211634.5098A-100000@opus.vcn.bc.ca>
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: <Pine.LNX.3.96.980505145913.1618J-100000@HAL9000.ac.rwth-aachen.de>
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: <Pine.GSO.3.95.980505095549.2852B-100000@banks.scar>
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: <Pine.GSO.3.95.980505095549.2852B-100000@banks.scar>
References: <Pine.GSO.3.95.980505095549.2852B-100000@banks.scar>
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" <dubois1@llnl.gov Tue May 5 16:11:24 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 5 May 1998 08:11:24 -0700
Subject: [Matrix-SIG] possible bug in NumPy
Message-ID: <001001bd7838$1282b6e0$998a7380@pduboispc.llnl.gov>
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 <gathmann@scar.utoronto.ca>
To: matrix-sig@python.org <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: <Pine.GSO.3.95.980505095549.2852B-100000@banks.scar>
Message-ID: <v03007803b174e698b317@[128.115.36.161]>
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" <dubois1@llnl.gov Tue May 5 16:27:12 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 5 May 1998 08:27:12 -0700
Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie)
Message-ID: <001501bd783a$472e60e0$998a7380@pduboispc.llnl.gov>
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 <landrum@HAL9000.ac.rwth-aachen.de>
To: matrix-sig@python.org <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: <Pine.GSO.3.95.980505095549.2852B-100000@banks.scar>
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 <wink>.
> 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 <wink>.
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: <Pine.LNX.3.96.980505180302.1618L-100000@HAL9000.ac.rwth-aachen.de>
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: <Pine.LNX.3.96.980505180302.1618L-100000@HAL9000.ac.rwth-aachen.de>
Message-ID: <Pine.SUN.3.96.980505092045.19520B-100000@skivs.ski.org>
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: <Pine.LNX.3.96.980505180302.1618L-100000@HAL9000.ac.rwth-aachen.de>
Message-ID: <Pine.LNX.3.96.980505115521.19592A-100000@hawkeye.cis.usouthal.edu>
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 <drh@hawkeye.cis.usouthal.edu>
To: Gregory A. Landrum <landrum@hal9000.ac.rwth-aachen.de>
Cc: matrix-sig@python.org <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" <dubois1@llnl.gov Tue May 5 23:00:56 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 5 May 1998 15:00:56 -0700
Subject: [Matrix-SIG] Quick... Duck! (or: YA Newbie)
Message-ID: <002801bd7871$487b0020$998a7380@pduboispc.llnl.gov>
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 <landrum@HAL9000.ac.rwth-aachen.de>
To: Paul F. Dubois <dubois1@llnl.gov>
Cc: matrix-sig@python.org <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" <dubois1@llnl.gov Tue May 5 23:11:59 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 5 May 1998 15:11:59 -0700
Subject: [Matrix-SIG] Background for test in NumPy?
Message-ID: <000301bd7872$d354d940$998a7380@pduboispc.llnl.gov>
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: <Pine.SUN.3.93.980511175618.1119f-100000@moet.cs.colorado.edu>
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: <Pine.LNX.3.96.980505115521.19592A-100000@hawkeye.cis.usouthal.edu>
(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: <Pine.SGI.3.96.980512171814.17085A-100000@solomon>
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: <Pine.SGI.3.96.980512171814.17085A-100000@solomon>
Message-ID: <v03007815b17f6d9c9ca4@[128.115.36.161]>
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: <Pine.SGI.3.96.980512171814.17085A-100000@solomon> (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 <warren@xtepca.gsfc.nasa.gov> Wed May 13 19:31:09 1998
From: Warren Focke <warren@xtepca.gsfc.nasa.gov> (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: <Pine.SUN.3.96.980513135153.19210A-100000@xtepca.gsfc.nasa.gov>
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
1
>>> b<a
1
Lists define a comparison operator also, it even makes sense.
Warren Focke
From Paul F. Dubois" <dubois1@llnl.gov Fri May 15 16:37:23 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 15 May 1998 08:37:23 -0700
Subject: [Matrix-SIG] seriously broken parse_index?
Message-ID: <002301bd8017$5b6cc4e0$52120f80@pduboispc.llnl.gov>
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" <dubois1@llnl.gov Fri May 15 16:54:34 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 15 May 1998 08:54:34 -0700
Subject: [Matrix-SIG] sick, sick, sick
Message-ID: <000301bd8019$c20cd300$52120f80@pduboispc.llnl.gov>
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: <Pine.SGI.3.96.980517154752.27960A-100000@seth>
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: <Pine.SUN.3.96.980519103120.5504G-100000@skivs.ski.org>
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: <Pine.SUN.3.96.980519103120.5504G-100000@skivs.ski.org>
References: <199805191513.LAA14925@reactor.pgt.com>
<Pine.SUN.3.96.980519103120.5504G-100000@skivs.ski.org>
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" <dubois1@llnl.gov Tue May 19 23:13:12 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 19 May 1998 15:13:12 -0700
Subject: [Matrix-SIG] Numeric Python documentation
Message-ID: <001501bd8373$50f43020$52120f80@pduboispc.llnl.gov>
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 <cgw@pgt.com>
To: David Ascher <da@skivs.ski.org>
Cc: Charles G Waldman <cgw@pgt.com>; matrix-sig@python.org
<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" <dubois1@llnl.gov Wed May 27 17:13:27 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Wed, 27 May 1998 09:13:27 -0700
Subject: [Matrix-SIG] UserArray
Message-ID: <002f01bd898a$62b0fba0$52120f80@pduboispc.llnl.gov>
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 <h.jansen@math.tudelft.nl>
To: matrix-sig@python.org <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: <Pine.OSF.3.95.980528215647.6982A-100000@mealpha.engr.uaf.edu>
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