From hinsen@ibs.ibs.fr Mon Nov 3 13:12:46 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 3 Nov 1997 14:12:46 +0100
Subject: [MATRIX-SIG] Reworked NumPy
Message-ID: <199711031312.OAA02192@lmspc1.ibs.fr>
Believe it or not, but NumPy has profited from a virus. A biological
virus, of course, which forced me to stay in bed for three days - and
what better could I do there than a bit of Python hacking?
So here it is - the first Eezee-Install (TM) version of NumPy.
A quote from the new installation instructions:
1) Copy the file Misc/Makefile.pre.in from the Python distribution
to this directory (not necessary from Python version 1.5a4).
2) Type
python compile.py
3) Type
python install.py
I have tested it with Python 1.4 and 1.5a4 and a couple of applications;
it seems to work as expected. The installation scripts are still rather
primitive and do no error checking, but they show how easy installation
can be made with a bit of effort.
All relevant information about the modifications is in the README - so
just grab it and test it for yourself. The URL is
http://starship.skyport.net/crew/hinsen/numpy.tar.gz
Konrad.
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jim.rucker@jpl.nasa.gov Thu Nov 6 23:24:35 1997
From: jim.rucker@jpl.nasa.gov (Jim Rucker)
Date: Thu, 6 Nov 1997 15:24:35 -0800
Subject: [MATRIX-SIG] Matrix class (obviously)
Message-ID: <01BCEAC8.17885260@jruckerpc.jpl.nasa.gov>
------ =_NextPart_000_01BCEAC8.178B5FA0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
I looked at the Matrix class in Matrix.py, and didn't see anything =
relating to the determinant of a matrix, so I wrote one myself. After I =
discovered the determinant function in the Linear Algebra file, I =
compared our implementations. I noticed that your implementation =
required the Matrix to be square, and was not made a member function of =
the Matrix class. My implemetation did both of these. I'm attaching a =
file that has this code, plus exp(M), which is inacurate for Matrixes =
with large numbers. It still needs more work, but I'm afraid I don't =
have the time. Let me know what you think of these functions. I haven't =
written much of a test though. Thank you,
-Jim Rucker
------ =_NextPart_000_01BCEAC8.178B5FA0
Content-Type: application/octet-stream; name="Matrix.py"
Content-Transfer-Encoding: base64
ZnJvbSBVc2VyQXJyYXkgaW1wb3J0IFVzZXJBcnJheQ0KZnJvbSBOdW1lcmljIGltcG9ydCBtYXRy
aXhtdWx0aXBseQ0KDQpjbGFzcyBNYXRyaXgoVXNlckFycmF5KToNCiAgICBkZWYgX19tdWxfXyhz
ZWxmLCBvdGhlcik6DQoJcmV0dXJuIE1hdHJpeChtYXRyaXhtdWx0aXBseShzZWxmLmFycmF5LG90
aGVyKSkNCg0KICAgIGRlZiBkZXQoc2VsZik6DQogICAgCWlmIHNlbGYuc2hhcGVbMV09PTE6DQog
ICAgCQlyZXR1cm4gc2VsZi5hcnJheVswXVswXQ0KCXRlbXA9TWF0cml4KHRyYW5zcG9zZSh0cmFu
c3Bvc2UoTWF0cml4KHNlbGZbMTpdKSlbMTpdKSkNCglyZXRfdmFsPXNlbGYuYXJyYXlbMF1bMF0q
dGVtcC5kZXQoKQ0KCXNpZ249KC0xKQ0KCWZvciBhIGluIHJhbmdlKDEsc2VsZi5zaGFwZVsxXS0x
KToNCgkJdGVtcD10cmFuc3Bvc2UodHJhbnNwb3NlKE1hdHJpeChbbVs6MV0sbVsyOl1dKSlbMTpd
KQ0KCQl0ZW1wPU1hdHJpeChbdHVwbGUodGVtcFswXVswXSksdHVwbGUodGVtcFsxXVswXSldKQ0K
CQlyZXRfdmFsPXJldF92YWwrc2lnbipzZWxmLmFycmF5W2FdWzBdKnRlbXAuZGV0KCkNCgkJc2ln
bj1zaWduKigtMSkNCgkNCgl0ZW1wPU1hdHJpeCh0cmFuc3Bvc2UodHJhbnNwb3NlKE1hdHJpeChz
ZWxmWzotMV0pKVsxOl0pKQ0KCXJldF92YWw9cmV0X3ZhbCtzaWduKnNlbGYuYXJyYXlbLTFdWzBd
KnRlbXAuZGV0KCkNCglyZXR1cm4gcmV0X3ZhbA0KCQ0KICAgIGRlZiBfX3JtdWxfXyhzZWxmLCBv
dGhlcik6DQoJcmV0dXJuIE1hdHJpeChtYXRyaXhtdWx0aXBseShzZWxmLmFycmF5LG90aGVyKSkN
Cg0KICAgIGRlZiBfX3Bvd19fKHNlbGYsIG90aGVyKToNCiAgICAJaWYgdHlwZShvdGhlcikgPT0g
dHlwZSgwKToNCgkgICAgCXZhbHVlPWlkZW50aXR5KHNlbGYuc2hhcGVbMV0pDQoJCWZvciBhIGlu
IHJhbmdlKG90aGVyKToNCgkJCXZhbHVlPW1hdHJpeG11bHRpcGx5KHZhbHVlLHNlbGYpDQoJCXJl
dHVybiBNYXRyaXgodmFsdWUpDQoJZWxzZToNCgkJcmFpc2UgVHlwZUVycm9yLCAieCoqeSBpcyBu
b3QgaW1wbGVtZW50ZWQgZm9yIHRoaXMgdHlwZSIJDQoNCiAgICBkZWYgX19ycG93X18oc2VsZiwg
b3RoZXIpOg0KCXJhaXNlIFR5cGVFcnJvciwgIngqKnkgbm90IGltcGxlbWVudGVkIGZvciBtYXRy
aWNlcyB5Ig0KICAgIA0KICAgIGRlZiBsbihzZWxmKToNCiAgICAJc2VsZj1zZWxmLWlkZW50aXR5
KHNlbGYuc2hhcGVbMV0pDQogICAgCW5vZj1tYXRyaXhtdWx0aXBseShzZWxmLHNlbGYpDQogICAg
CXZhbHVlPXNlbGYtbm9mLzINCglmb3IgYSBpbiByYW5nZSgzLDEwLDIpOg0KCQlub2Y9bWF0cml4
bXVsdGlwbHkobm9mLHNlbGYpDQoJCXZhbHVlPXZhbHVlK25vZi9hDQoJCW5vZj1tYXRyaXhtdWx0
aXBseShub2Ysc2VsZikNCgkJdmFsdWU9dmFsdWUtbm9mL2ErMQ0KCXJldHVybiBNYXRyaXgodmFs
dWUpDQoNCiAgICBkZWYgZXhwKHNlbGYsZXJyb3I9LjAwMDEpOg0KICAgIAllcnJvcj1wb3coZXJy
b3Isc2VsZi5zaGFwZVsxXSkNCgluPWlkZW50aXR5KHNlbGYuc2hhcGVbMV0pDQoJbT0xDQoJbD1u
DQoJZm9yIGEgaW4gcmFuZ2UoMSwyMCk6DQoJCW49bWF0cml4bXVsdGlwbHkobixzZWxmKS9tDQoJ
CWlmIE1hdHJpeChuKS5kZXQoKSA8IGVycm9yOg0KCQkJYnJlYWsNCgkJbT1tKzENCgkJbD1sK24N
CglyZXR1cm4gTWF0cml4KGwpCQ0KDQpkZWYgZmFjdChuKToNCglpZiB0eXBlKG4pID09IHR5cGUo
MCk6DQoJCWlmIG49PTE6DQoJCQlyZXR1cm4gMQ0KCQlyZXR1cm4gbipmYWN0KG4tMSkgICAgICAg
IAkNCglyYWlzZSBUeXBlRXJyb3IsICJOb3QgYSB2YWxpZCB0eXBlIGZvciBmYWN0b3JpYWwiDQoJ
DQpkZWYgbG4obnVtLGFjYyk6DQoJZXM9KDEsMi43MTgyODE4Mjg0NTksNy4zODkwNTYwOTg5MzEs
MjAuMDg1NTM2OTIzMTksNTQuNTk4MTUwMDMzMTQsIDE0OC40MTMxNTkxMDI2KQ0KCWZvciBhIGlu
IHJhbmdlKDAsNik6DQoJCWlmIG51bTxlc1thXToNCgkJCW51bT0oZmxvYXQobnVtKS9lc1thXSkt
MQ0KCQkJdmFsdWU9YQ0KCQkJYnJlYWsNCgllbHNlOg0KCQl2YWx1ZT0xDQoJCW51bT1mbG9hdChu
dW0pLTENCglydW5tYXQ9bnVtDQoJY291bnQ9MQ0KCQ0KCXdoaWxlIGFicyhudW0vY291bnQpPmFj
YzoNCgkJdmFsdWU9dmFsdWUrcnVubWF0L2NvdW50DQoJCXJ1bm1hdD1ydW5tYXQqbnVtDQoJCWNv
dW50PWNvdW50KzENCgkJdmFsdWU9dmFsdWUtcnVubWF0L2NvdW50DQoJCWNvdW50PWNvdW50KzEN
CgkJcnVubWF0PXJ1bm1hdCpudW0NCglyZXR1cm4gdmFsdWUJDQoJDQppZiBfX25hbWVfXyA9PSAn
X19tYWluX18nOg0KIwlwcmludCBsbigxNDAsLjAwMDAxKQ0KCWZyb20gTnVtZXJpYyBpbXBvcnQg
Kg0KIwltID0gTWF0cml4KCBbWzEsMiwzXSxbMTEsMTIsMTNdLFsyMSwyMiwyM11dKQ0KCW09TWF0
cml4KFtbMS4wLDAsMF0sWzAsMS4wLDBdLFswLDAsMS4wXV0pDQoJcHJpbnQgbS5leHAoKQ0K
------ =_NextPart_000_01BCEAC8.178B5FA0--
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Fri Nov 7 16:05:17 1997
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 7 Nov 1997 08:05:17 -0800
Subject: [MATRIX-SIG] Matrix class (obviously)
Message-ID: <01bceb96$f0f5e5c0$998a7380@pduboispc>
Eeek! This is not how to find a determinant! It not only is not going to
work for matrices of big numbers, it won't work for big matrices of small
numbers. I'm sure there must be stuff in the Linear Algebra file to find an
LU-decomposition. Then the determinant is the product of the diagonals of L.
For example, given
M = 3, 2
-2, 1
M = 3, 0 * 1, 2/3
-2, 7/3 0, 1
so D = 3 * (7/3) = 7.
(An LU decomposition is writing M as a product of a lower triangular matrix
times an upper triangular matrix with a diagonal of 1. The work involved is
the same as the first stage of solving MX = B. No extra storage is actually
involved since you can store L and U in the same n**2 locations as M. The
determinant of a triangular matrix is the product of its diagonal elements.)
The rules you learned in school for finding determinants are fine
theoretically but have bad numerical properties on
a computer.
-----Original Message-----
From: Jim Rucker <jim.rucker@jpl.nasa.gov>
To: 'matrix-sig@python.org' <matrix-sig@python.org>
Date: Thursday, November 06, 1997 3:28 PM
Subject: [MATRIX-SIG] Matrix class (obviously)
I looked at the Matrix class in Matrix.py, and didn't see anything relating
to the determinant of a matrix, so I wrote one myself. After I discovered
the determinant function in the Linear Algebra file, I compared our
implementations. I noticed that your implementation required the Matrix to
be square, and was not made a member function of the Matrix class. My
implemetation did both of these. I'm attaching a file that has this code,
plus exp(M), which is inacurate for Matrixes with large numbers. It still
needs more work, but I'm afraid I don't have the time. Let me know what you
think of these functions. I haven't written much of a test though. Thank
you,
-Jim Rucker
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Sun Nov 9 16:02:23 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sun, 9 Nov 1997 17:02:23 +0100
Subject: [MATRIX-SIG] Matrix class (obviously)
In-Reply-To: <01bceb96$f0f5e5c0$998a7380@pduboispc> (dubois1@llnl.gov)
Message-ID: <199711091602.RAA29887@lmspc1.ibs.fr>
> Eeek! This is not how to find a determinant! It not only is not going to
> work for matrices of big numbers, it won't work for big matrices of small
> numbers. I'm sure there must be stuff in the Linear Algebra file to find an
> LU-decomposition. Then the determinant is the product of the diagonals of L.
That's how determinants ought to be calculated in LinearAlgebra, but what
is still there is a first quick hack I did (multiplying the eigenvalues).
I never got around to do it better because I didn't really need
determinants...
LU decomposition is not in LinearAlgebra as user-friendly function,
but looking at the linear equation solver is sufficient to see how
it's done.
> (An LU decomposition is writing M as a product of a lower triangular matrix
> times an upper triangular matrix with a diagonal of 1. The work involved is
> the same as the first stage of solving MX = B. No extra storage is actually
> involved since you can store L and U in the same n**2 locations as M. The
> determinant of a triangular matrix is the product of its diagonal elements.)
Currently all operations in LinearAlgebra allocate additional storage
to avoid destroying any input data. According to the "principle of
least surprise" this should be the default behaviour. However, it would
be nice to have destructive versions as an option...
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Mon Nov 10 04:17:34 1997
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Sun, 9 Nov 1997 20:17:34 -0800
Subject: [MATRIX-SIG] Matrix class (obviously)
Message-ID: <01bced8f$921b4c20$998a7380@pduboispc>
Not to start a food fight, Konrad, but to anyone used to using any of the
major linear solver packages, NOT solving the system in place would violate
the principal of least surprise.
I can certainly code up an LU in Python + Numerical as an example. Wouldn't
match the speed of a C version but it might not be too terrible for a big
enough system. And, I could show how to package such things in a proper OO
fashion. I'll assign this to myself as homework.
-----Original Message-----
From: Konrad Hinsen <hinsen@ibs.ibs.fr>
To: dubois1@llnl.gov <dubois1@llnl.gov>
Cc: jim.rucker@jpl.nasa.gov <jim.rucker@jpl.nasa.gov>; matrix-sig@python.org
<matrix-sig@python.org>
Date: Sunday, November 09, 1997 8:09 AM
Subject: Re: [MATRIX-SIG] Matrix class (obviously)
>> Eeek! This is not how to find a determinant! It not only is not going to
>> work for matrices of big numbers, it won't work for big matrices of small
>> numbers. I'm sure there must be stuff in the Linear Algebra file to find
an
>> LU-decomposition. Then the determinant is the product of the diagonals of
L.
>
>That's how determinants ought to be calculated in LinearAlgebra, but what
>is still there is a first quick hack I did (multiplying the eigenvalues).
>I never got around to do it better because I didn't really need
>determinants...
>
>LU decomposition is not in LinearAlgebra as user-friendly function,
>but looking at the linear equation solver is sufficient to see how
>it's done.
>
>> (An LU decomposition is writing M as a product of a lower triangular
matrix
>> times an upper triangular matrix with a diagonal of 1. The work involved
is
>> the same as the first stage of solving MX = B. No extra storage is
actually
>> involved since you can store L and U in the same n**2 locations as M. The
>> determinant of a triangular matrix is the product of its diagonal
elements.)
>
>Currently all operations in LinearAlgebra allocate additional storage
>to avoid destroying any input data. According to the "principle of
>least surprise" this should be the default behaviour. However, it would
>be nice to have destructive versions as an option...
>--
>---------------------------------------------------------------------------
----
>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
>---------------------------------------------------------------------------
----
>
>_______________
>MATRIX-SIG - SIG on Matrix Math for Python
>
>send messages to: matrix-sig@python.org
>administrivia to: matrix-sig-request@python.org
>_______________
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Mon Nov 10 09:01:03 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 10 Nov 1997 10:01:03 +0100
Subject: [MATRIX-SIG] Matrix class (obviously)
In-Reply-To: <01bced8f$921b4c20$998a7380@pduboispc> (dubois1@llnl.gov)
Message-ID: <199711100901.KAA00150@lmspc1.ibs.fr>
> Not to start a food fight, Konrad, but to anyone used to using any of the
> major linear solver packages, NOT solving the system in place would violate
> the principal of least surprise.
True, but not everyone is used to these packages, and other high-level
tools (e.g. Matlab) don't destroy the input data either. Besides, side
effects can be much worse in NumPy - the array data space being
overwritten might have been used by several array objects! Anyway, the
long-term goal should be to have both options.
> I can certainly code up an LU in Python + Numerical as an example. Wouldn't
> match the speed of a C version but it might not be too terrible for a big
> enough system. And, I could show how to package such things in a proper OO
> fashion. I'll assign this to myself as homework.
Speaking about OO... There isn't much of it in the current NumPy
version - there's the array object, and everything else is just a bunch
of functions. For good reasons, as those who participated in the early
discussions may remember.
Still it would be worthwhile to continue with the original idea of
providing a full-featured matrix class on top of the basic arrays.
All the linear algebra operations could be fitted in there in a much
nicer way.
And since I am in "dream mode" anyway, let's continue. How would one
best implement something like that? A complete Python wrapper eats
some efficiency, and makes it difficult to implement individual
methods in C. But there's Jim Fulton's ExtensionClass module. If NumPy
arrays were such an extension class, the basic matrix object (with C
methods) could be a C subclass of arrays, and the "final" matrix
object a Python subclass, adding the methods that can easily be
written in Python.
So just in case someone is looking for a nice side project to kill
some spare time...
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From amainc@ama-inc.com Mon Nov 10 16:20:32 1997
From: amainc@ama-inc.com (Anaytical Mechanics Associates Inc.)
Date: Mon, 10 Nov 1997 10:20:32 -0600
Subject: [MATRIX-SIG] Simplex Theory
Message-ID: <34673450.24C1E1F2@ama-inc.com>
Hi there!
I am looking for the Simplex algorithm in Fortran 77 double precision.
Any idea where I can get this?
I would greatly appreciate any assistance you can provide.
Thank you!
Hans Seywald
seywald@ama-inc.com
amainc@ama-inc.com
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From boyle@pcmdi.llnl.gov Thu Nov 13 19:13:35 1997
From: boyle@pcmdi.llnl.gov (James Boyle)
Date: Thu, 13 Nov 1997 11:13:35 -0800 (PST)
Subject: [MATRIX-SIG] matrix product in NumPy
Message-ID: <199711131913.LAA10596@cobra.llnl.gov>
This is a very simple question.
Given two arrays: a = M x N and b = N x P
How do I compute:
c = ab, such that c = M x P.
The is the simple matrix product.
The function Numeric.dot, only seems to work
for arrays of the same size a = M x N and b = M x N
What am I missing? the documentation of the Dot
in Numpy is a bit cryptic, indicating that it needs
to be done right someday - what does this mean?
Thanks for any help.
Jim
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From johann@physics.berkeley.edu Thu Nov 13 21:06:03 1997
From: johann@physics.berkeley.edu (Johann Hibschman)
Date: Thu, 13 Nov 1997 13:06:03 -0800 (PST)
Subject: [MATRIX-SIG] matrix product in NumPy
In-Reply-To: <199711131913.LAA10596@cobra.llnl.gov>
Message-ID: <Pine.SUN.3.96.971113130310.382A-100000@physics12.Berkeley.EDU>
On Thu, 13 Nov 1997, James Boyle wrote:
> What am I missing? the documentation of the Dot
> in Numpy is a bit cryptic, indicating that it needs
> to be done right someday - what does this mean?
>
> Thanks for any help.
You want the "matrixmultiply" function. It's in Numeric.
I have no idea what "dot" does, myself.
- Johann
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Nov 14 13:10:56 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 14 Nov 1997 14:10:56 +0100
Subject: [MATRIX-SIG] matrix product in NumPy
In-Reply-To: <199711131913.LAA10596@cobra.llnl.gov> (message from James Boyle
on Thu, 13 Nov 1997 11:13:35 -0800 (PST))
Message-ID: <199711141310.OAA15476@lmspc1.ibs.fr>
> This is a very simple question.
> Given two arrays: a = M x N and b = N x P
> How do I compute:
> c = ab, such that c = M x P.
> The is the simple matrix product.
>
> The function Numeric.dot, only seems to work
> for arrays of the same size a = M x N and b = M x N
If you use the latest version of NumPy, then dot() should do
what you want. In earlier versions, dot() calculated the
product between a and the *transpose* of b. The standard
matrix product was calculated by matrixmultiply() and that
function rests for compatibility (but is exactly equal to dot()
now).
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jhauser@ifm.uni-kiel.de Mon Nov 17 23:15:14 1997
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Tue, 18 Nov 1997 00:15:14 +0100 (CET)
Subject: [MATRIX-SIG] Change slice object?
Message-ID: <m0xXaNu-000syBC@lisboa.ifm.uni-kiel.de>
Currently I use the slide objects very often to map between different
grids. It's not very elegant to deal with the difference of
__getitem__ and __getsclice__. I must always test for an integer in
the slice expression
sl_tuple = (slice(12,13,None),4)
Is it possible to change the slice object in following way. Whould this
break code?
a=reshape(arange(18),(6,3))
a[0,:] => (slice(0,1,None),slice(None,None,1))
a[0:1,:] => (slice(0,1,1),slice(None,None,1))
a[0:2,:] => (slice(0,2,1),slice(None,None,1))
Currently slice(start,stop,None) is the same as slice(start,stop,1).
This would make it probably more clear why a dimension is preserved if
I use a step of 1 and dropped if I use a step of length None.
Also then there is no need for __getitem__ if one uses indexing. But I
think the method is needed for the for-loop construct, right?
But in every function which deals with slicing, one can be shure to
get only a tuple of slice objects.
I don't see, how big the impact of this change would be to the other
sequence objects in python.
One other idea. What's the way to have a __cmp__ method for slice
objects to test if a slice is completly in another slice or
overlapping at both or only one end.
== slices are equal
>= slice_a is overlapping only at the upper bound and greater or equal
at lower bound
<= slice_a is overlapping only at the lower bound and smaller or equal
at upper bound
< slice_a is completly in slice_b
> slice_a is overlapping at both ends
I think I try first with a shadow_class to implement this :-)
But are there some ideas?
__Janko
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From chase@att.com Tue Nov 18 00:42:50 1997
From: chase@att.com (Chase, Christopher J (Chris), NNAD)
Date: Mon, 17 Nov 1997 19:42:50 -0500
Subject: [MATRIX-SIG] Change slice object?
Message-ID: <c=US%a=_%p=ATT%l=NJC240PO03-971118004250Z-2495@njb140bh3.EMS.ATT.COM>
With your suggested change, what would using slice(0,5,None) mean?
Would that be an error?
Chris
----------
From: Janko Hauser[SMTP:jhauser@ifm.uni-kiel.de]
Sent: Monday, November 17, 1997 6:15 PM
To: Matrix-Sig
Subject: [MATRIX-SIG] Change slice object?
Currently I use the slide objects very often to map between different
grids. It's not very elegant to deal with the difference of
__getitem__ and __getsclice__. I must always test for an integer in
the slice expression
sl_tuple = (slice(12,13,None),4)
Is it possible to change the slice object in following way. Whould
this
break code?
a=reshape(arange(18),(6,3))
a[0,:] => (slice(0,1,None),slice(None,None,1))
a[0:1,:] => (slice(0,1,1),slice(None,None,1))
a[0:2,:] => (slice(0,2,1),slice(None,None,1))
Currently slice(start,stop,None) is the same as slice(start,stop,1).
This would make it probably more clear why a dimension is preserved
if
I use a step of 1 and dropped if I use a step of length None.
Also then there is no need for __getitem__ if one uses indexing. But
I
think the method is needed for the for-loop construct, right?
But in every function which deals with slicing, one can be shure to
get only a tuple of slice objects.
I don't see, how big the impact of this change would be to the other
sequence objects in python.
One other idea. What's the way to have a __cmp__ method for slice
objects to test if a slice is completly in another slice or
overlapping at both or only one end.
== slices are equal
>= slice_a is overlapping only at the upper bound and greater or
equal
at lower bound
<= slice_a is overlapping only at the lower bound and smaller or
equal
at upper bound
< slice_a is completly in slice_b
> slice_a is overlapping at both ends
I think I try first with a shadow_class to implement this :-)
But are there some ideas?
__Janko
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jhauser@ifm.uni-kiel.de Tue Nov 18 07:57:35 1997
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Tue, 18 Nov 1997 08:57:35 +0100 (CET)
Subject: [MATRIX-SIG] Change slice object?
In-Reply-To: <c=US%a=_%p=ATT%l=NJC240PO03-971118004250Z-2495@njb140bh3.EMS.ATT.COM>
References: <c=US%a=_%p=ATT%l=NJC240PO03-971118004250Z-2495@njb140bh3.EMS.ATT.COM>
Message-ID: <m0xXiXP-000syBC@lisboa.ifm.uni-kiel.de>
Chase, Christopher J (Chris), NNAD writes:
> With your suggested change, what would using slice(0,5,None) mean?
> Would that be an error?
I think this should then be an error, but this construct is then not
present, because the default of slice.step should then always be 1.
Is it possible to implement this slice handling only for multiarray
objects?
Uh, I see now that slices can not be used like expected for lists
Python 1.4 (Sep 1 1997) [GCC 2.7.2.1]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> a=[1,2,3,4,5]
>>> a[slice(0,3,1)]
Traceback (innermost last):
File "<stdin>", line 1, in ?
ValueError: standard sequence type does not support step size other than one
>>> a[slice(0,3)]
Traceback (innermost last):
File "<stdin>", line 1, in ?
ValueError: standard sequence type does not support step size other than one
>>> a[slice(0,3,None)]
Traceback (innermost last):
File "<stdin>", line 1, in ?
ValueError: standard sequence type does not support step size other than one
Is this right?
__Janko
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From arb@connect.com.au Tue Nov 18 10:26:51 1997
From: arb@connect.com.au (Anthony Baxter)
Date: Tue, 18 Nov 1997 21:26:51 +1100
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
Message-ID: <199711181026.VAA08497@jambu.off.connect.com.au>
is there any reason for this difference in behaviour? It's unexpected (well, it
was unexpected by me :)
>>> umath.logical_and(4,5)
1
>>> 4 and 5
5
ta,
Anthony
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From da@skivs.ski.org Tue Nov 18 18:13:48 1997
From: da@skivs.ski.org (David Ascher)
Date: Tue, 18 Nov 1997 10:13:48 -0800 (PST)
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: <199711181026.VAA08497@jambu.off.connect.com.au>
Message-ID: <Pine.SUN.3.96.971118101257.20259F-100000@skivs.ski.org>
> is there any reason for this difference in behaviour? It's unexpected
> (well, it was unexpected by me :)
>
> >>> umath.logical_and(4,5)
> 1
> >>> 4 and 5
> 5
Try:
>>> umath.boolean_and(4,5)
logical_and returns 0 or 1, boolean_and works like Python's 'and'
construct.
--da
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From motteler@laura.llnl.gov Tue Nov 18 18:42:35 1997
From: motteler@laura.llnl.gov (Zane C. Motteler)
Date: Tue, 18 Nov 1997 10:42:35 -0800 (PST)
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: <Pine.SUN.3.96.971118101257.20259F-100000@skivs.ski.org>
Message-ID: <Pine.HPP.3.95.971118103941.18313A-100000@laura.llnl.gov>
David,
On Tue, 18 Nov 1997, you wrote:
>> is there any reason for this difference in behaviour? It's unexpected
>> (well, it was unexpected by me :)
>>
>> >>> umath.logical_and(4,5)
>> 1
>> >>> 4 and 5
>> 5
>
>Try:
>
> >>> umath.boolean_and(4,5)
>
>logical_and returns 0 or 1, boolean_and works like Python's 'and'
>construct.
>
>--da
Yes, but the boolean_and of 4 and 5 is 4. It is incomprehensible how the
'4 and 5' construct comes up with 5. Incidentally, '4 or 5' comes out 4.
Perhaps the parser has inadvertently interchanged the 'and' and 'or'
operators???
Zane
-----------------------------------------------------------------------------
Zane C. Motteler, Ph. D. ___________ALSO:_________________
Computer Scientist | Professor Emeritus of Computer|
Lawrence Livermore National Laboratory | Science and Engineering |
P O Box 808, L-472 | California Polytechnic State |
Livermore, CA 94551-9900 | University, San Luis Obispo |
510/423-2143 ---------------------------------
FAX 510/423-9969
zcm@llnl.gov or motteler@laura.llnl.gov or zmottel@calpoly.edu
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Tue Nov 18 19:08:11 1997
From: beach@verinet.com (David J. C. Beach)
Date: Tue, 18 Nov 1997 12:08:11 -0700
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
References: <199711181026.VAA08497@jambu.off.connect.com.au>
Message-ID: <3471E79B.3AA4CFE3@verinet.com>
Anthony Baxter wrote:
> is there any reason for this difference in behaviour? It's unexpected (well, it
> was unexpected by me :)
>
> >>> umath.logical_and(4,5)
> 1
> >>> 4 and 5
> 5
>>> 4 and 5
5
4 is true, so return the value of the second operand, which is 5. But that's okay
because 5 is a true value. Since and here is a language construct, you can say
nifty things like
>>> go_to_your_room() and clean_up_the_mess()
and still get the return value from the second (assuming go_to_your_room() was
true)
>>> umath.logical_and(4, 5)
1
4 and 5 are both true, so logical_and returns a 1, which is true.
and, if you want a bitwise and,
>>> umath.boolean_and(4, 5)
4
the bitwise and of the binary representations for 4 and 5.
Dave
P.S. I'm not saying that I like the names...
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From da@skivs.ski.org Tue Nov 18 19:18:22 1997
From: da@skivs.ski.org (David Ascher)
Date: Tue, 18 Nov 1997 11:18:22 -0800 (PST)
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: <3471E855.C173728E@verinet.com>
Message-ID: <Pine.SUN.3.96.971118111605.23426D-100000@skivs.ski.org>
On Tue, 18 Nov 1997, David J. C. Beach wrote:
> David Ascher wrote:
>
> > logical_and returns 0 or 1, boolean_and works like Python's 'and'
> > construct.
>
> Nay!
> I'm pretty sure that boolean_and is a bitwise, behold:
Indeed, you and Zane both caught that mistake... Looking at the source,
we get the C '&' operator for boolean_and.
boolean_and --> &
logical_and --> &&
I don't know if those words really help me remember which is which, but
that's another topic. Maybe we should rename them "bitwise_and"...
--david
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From pas@xis.xerox.com Tue Nov 18 21:46:18 1997
From: pas@xis.xerox.com (Perry A. Stoll)
Date: Tue, 18 Nov 1997 13:46:18 PST
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: <Pine.SUN.3.96.971118101257.20259F-100000@skivs.ski.org>
Message-ID: <199711182146.QAA11175@terminator.xis.xerox.com>
On 18 Nov , David Ascher wrote:
>> is there any reason for this difference in behaviour? It's unexpected
>> (well, it was unexpected by me :)
>>
>> >>> umath.logical_and(4,5)
>> 1
>> >>> 4 and 5
>> 5
>
> Try:
>
> >>> umath.boolean_and(4,5)
>
> logical_and returns 0 or 1, boolean_and works like Python's 'and'
> construct.
Did you try it? I get the following:
>>> umath.boolean_and(4,5)
4
>>> 4 & 5
4
Why? I'll leave it for someone else to sort out...
-Perry
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From pas@xis.xerox.com Tue Nov 18 22:54:35 1997
From: pas@xis.xerox.com (Perry A. Stoll)
Date: Tue, 18 Nov 1997 14:54:35 PST
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: <Pine.HPP.3.95.971118103941.18313A-100000@laura.llnl.gov>
Message-ID: <199711182254.RAA11894@terminator.xis.xerox.com>
> Yes, but the boolean_and of 4 and 5 is 4. It is incomprehensible how the
> '4 and 5' construct comes up with 5.
def _and(*args):
arg = None
for arg in args:
if not arg: return None
return arg
>>> _and(4,5)
5
Incidentally, '4 or 5' comes out 4.
def _or(*args):
arg = None
for arg in args:
if arg: return arg
return arg
>>> _or(4,5)
4
These are almost what the builtins do, except that the arguments are
evaluated here for the function call. They aren't evaluated in Python
(or C) until they are tested.
Note also that umath.logical_and() returns only 1 or 0 values, which is
not the same one gets using the normal Python operators.
Add my vote for the name change to bitwise_and...I still don't know
which is supposed to do what: "logical"??? "boolean"???
-Perry
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Wed Nov 19 06:09:51 1997
From: beach@verinet.com (David J. C. Beach)
Date: Tue, 18 Nov 1997 23:09:51 -0700
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
References: <Pine.SUN.3.96.971118111605.23426D-100000@skivs.ski.org>
Message-ID: <347282AF.69C9D6CF@verinet.com>
David Ascher wrote:
> boolean_and --> &
>
> logical_and --> &&
>
> I don't know if those words really help me remember which is which, but
> that's another topic. Maybe we should rename them "bitwise_and"...
If it were up to me, I'd vote for:
umath.bitwise_and = &,
umath.logical_and = &&.
These names make it clear to me what each function does, and it only
changes the name of the boolean_and to bitwise_and (and boolean_or to
bitwise_or [of course], etc...)
Dave
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From richard.jones@bom.gov.au Wed Nov 19 06:41:59 1997
From: richard.jones@bom.gov.au (Richard Jones)
Date: Wed, 19 Nov 1997 06:41:59 +0000
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: Message from "David J. C. Beach" of 1997-Nov-18 23:9:51,
<347282AF.69C9D6CF@verinet.com>
Message-ID: <199711190641.GAA26527@mage.ho.bom.gov.au>
"David J. C. Beach" wrote:
> David Ascher wrote:
>
> > boolean_and --> &
> >
> > logical_and --> &&
> >
> > I don't know if those words really help me remember which is which, but
> > that's another topic. Maybe we should rename them "bitwise_and"...
>
> If it were up to me, I'd vote for:
>
> umath.bitwise_and = &,
> umath.logical_and = &&.
>
> These names make it clear to me what each function does, and it only
> changes the name of the boolean_and to bitwise_and (and boolean_or to
> bitwise_or [of course], etc...)
Yes, but they're different to what Python does. Well, the && case is
different. Do we need a further umath.python_and that does what Python
programmers expect???
Richard
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Wed Nov 19 07:36:23 1997
From: beach@verinet.com (David J. C. Beach)
Date: Wed, 19 Nov 1997 00:36:23 -0700
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
References: <199711190641.GAA26527@mage.ho.bom.gov.au>
Message-ID: <347296F7.664866D6@verinet.com>
Richard Jones wrote:
> Yes, but they're different to what Python does. Well, the && case is
> different. Do we need a further umath.python_and that does what Python
> programmers expect???
A good point. Perhaps what we really want, then, is this:
umath.bitwise_and = the C (or Python) operator, &
umath.logical_and = the Python 'and' operator
etc.
After reconsidering it, it seems that a logical_and that returns only a 0 or 1
doesn't have any significant advantages over Python's 'and', which can be used
to selectively evaluate a construct, return the truth value of the logical
and, or to selectively give a return value for the last true argument.
Dave
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul.Moore@uk.origin-it.com Wed Nov 19 09:54:09 1997
From: Paul.Moore@uk.origin-it.com (Moore, Paul)
Date: Wed, 19 Nov 1997 09:54:09 -0000
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
Message-ID: <c=UK%a=_%p=Origin-it%l=UKRUX002-971119095409Z-6781@ukrax001.ras.uk.origin-it.com>
One advantage of an and/or which returns 1 or 0 is that you can play
games with it, like multiply it by a constant. Consider
a * logical_and(a,b)
which gives the same values as a where b is nonzero, but zero where b is
zero. This is the sort of game that gets played in APL all the time....
(OK, this isn't a very good example, but I can't make up a realistic
case offhand).
Paul.
_______________________________________________________
Paul Moore
Oracle Development Team,
Business Application Management, Origin UK (Runcorn).
Tel : +44 (0)1928 511065
Fax : +44 (0)1928 515020
e-mail : paul.moore@uk.origin-it.com
>----------
>From: David J. C. Beach[SMTP:beach@verinet.com]
>Sent: 19 November 1997 07:36
>To: richard.jones@bom.gov.au; Matrix SIG
>Subject: Re: [MATRIX-SIG] umath.logical_blah vs normal python functions.
>
>Richard Jones wrote:
>
>> Yes, but they're different to what Python does. Well, the && case is
>> different. Do we need a further umath.python_and that does what Python
>> programmers expect???
>
>A good point. Perhaps what we really want, then, is this:
>
>umath.bitwise_and = the C (or Python) operator, &
>umath.logical_and = the Python 'and' operator
>
>etc.
>
>After reconsidering it, it seems that a logical_and that returns only a 0 or
>1
>doesn't have any significant advantages over Python's 'and', which can be
>used
>to selectively evaluate a construct, return the truth value of the logical
>and, or to selectively give a return value for the last true argument.
>
>Dave
>
>--
>David J. C. Beach
>Colorado State University
>mailto:beach@verinet.com
>http://www.verinet.com/~beach
>
>
>
>
>_______________
>MATRIX-SIG - SIG on Matrix Math for Python
>
>send messages to: matrix-sig@python.org
>administrivia to: matrix-sig-request@python.org
>_______________
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From da@skivs.ski.org Wed Nov 19 21:57:20 1997
From: da@skivs.ski.org (David Ascher)
Date: Wed, 19 Nov 1997 13:57:20 -0800 (PST)
Subject: [MATRIX-SIG] memory leak
Message-ID: <Pine.SUN.3.96.971119135551.21114A-100000@skivs.ski.org>
Is there a known memory leak in NumPy, with a patch available, or did I
just find a new one? I vaguely remember something being talked about
months ago, but clearly it hasn't made it in the latest available
distribution.
If i'm making things up, I'll have to trim my leaky program to find the
source of the bug, but I'd rather not.
Cheers,
--da
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Wed Nov 19 23:26:12 1997
From: beach@verinet.com (David J. C. Beach)
Date: Wed, 19 Nov 1997 16:26:12 -0700
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
References: <c=UK%a=_%p=Origin-it%l=UKRUX002-971119095409Z-6781@ukrax001.ras.uk.origin-it.com>
Message-ID: <34737594.85A34AA8@verinet.com>
Moore, Paul wrote:
> One advantage of an and/or which returns 1 or 0 is that you can play
> games with it, like multiply it by a constant. Consider
>
> a * logical_and(a,b)
>
> which gives the same values as a where b is nonzero, but zero where b is
> zero. This is the sort of game that gets played in APL all the time....
> (OK, this isn't a very good example, but I can't make up a realistic
> case offhand).
Is this the clear kind of programming style promoted by Python's designers?
Dave
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From R.Hooft@EuroMail.com Thu Nov 20 07:52:38 1997
From: R.Hooft@EuroMail.com (Rob Hooft)
Date: Thu, 20 Nov 1997 08:52:38 +0100 (MET)
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: <34737594.85A34AA8@verinet.com>
References: <c=UK%a=_%p=Origin-it%l=UKRUX002-971119095409Z-6781@ukrax001.ras.uk.origin-it.com>
<34737594.85A34AA8@verinet.com>
Message-ID: <199711200752.IAA22677@nu>
>>>>> "DB" == David J C Beach <beach@verinet.com> writes:
DB> Moore, Paul wrote:
>> One advantage of an and/or which returns 1 or 0 is that you can
>> play games with it, like multiply it by a constant. Consider
>>
>> a * logical_and(a,b)
>>
>> which gives the same values as a where b is nonzero, but zero
>> where b is zero. This is the sort of game that gets played in APL
>> all the time.... (OK, this isn't a very good example, but I can't
>> make up a realistic case offhand).
DB> Is this the clear kind of programming style promoted by Python's
DB> designers?
It probably is not, but I must say that when using NumPy, it is often
the only way to prevent interpreter-level loops over array elements.
It took me a long time to get used to this as well, but in the end one
can actually read ones own code! From my code, another example of the
use of boolean functions returning 0 or 1 and not any kind of value:
min=Numeric.minimum(image0,image1)
sum=image0+image1
difsquare=(image0-image1)**2
condition=Numeric.greater(difsquare,4*sum)
# if dif^2>4*sum return 2*min, else return sum
result=Numeric.choose(condition,(sum,2*min))
This use of a "condition" and a Numeric.choose call are very common
in my software.
[for the interested: this example removes cosmic rays from digitized
images by merging two measurements, taking into account that the
measurement error in each pixel is the square-root of that pixel's
value. I fear that for doing the same with more than two original
images efficiently, I will need a C function. Open for suggestions.]
--
===== R.Hooft@EuroMail.com http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
===== R&D, Nonius BV, Delft http://www.nonius.com/ ==
===== PGPid 0xFA19277D ========================== Use Linux! ==================
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From conrad@cgl.ucsf.edu Thu Nov 20 16:30:35 1997
From: conrad@cgl.ucsf.edu (Conrad Huang %CGL)
Date: 20 Nov 97 16:30:35 GMT
Subject: [MATRIX-SIG] memory leak
References: <Pine.SUN.3.96.971119135551.21114A-100000@skivs.ski.org>
Message-ID: <conrad.880043435@cgl.ucsf.edu>
da@skivs.ski.org (David Ascher) writes:
>Is there a known memory leak in NumPy, with a patch available, or did I
>just find a new one? I vaguely remember something being talked about
>months ago, but clearly it hasn't made it in the latest available
>distribution.
I have a guess as to what the problem may be, and I was going to wait
until 1.5b1 came out to see if it's already fixed. But now that you
asked...
The problem I think I discovered is not in NumPy, but it manifested
itself while I was working with a program that made extensive use of
LinearAlgebra.eigenvectors(), which calls lapack_lite.dgeev(). The
latter routine returns a dictionary of a bunch of things and constructs
the dictionary with a call to:
return Py_BuildValue("{s:i,s:c,s:c,s:i,s:i,s:i,s:i,s:i,s:i}",
"dgeev_",lapack_lite_status__,"jobvl",jobvl,"jobvr",jobvr,
"n",n,"lda",lda,"ldvl",ldvl,"ldvr",ldvr,"lwork",lwork,"info",info);
When Py_BuildValue (in Python/modsupport.c) builds the dictionary, it
calls do_mkvalue() which calls do_mkdict(), and that's where I think
the problem is. do_mkdict() goes through a loop whose body is (with
error checking removed):
k = do_mkvalue(p_format, p_va);
v = do_mkvalue(p_format, p_va);
PyDict_SetItem(d, k, v);
Since PyDict_SetItem() increments the reference count of both key and
value, k and v both have reference counts of 2 when do_mkdict() returns.
I think there should be:
Py_DECREF(k);
Py_DECREF(v);
after the call to PyDict_SetItem().
Will someone "in the know" please check my logic? Thanks,
Conrad
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From phil@geog.ubc.ca Thu Nov 20 16:11:14 1997
From: phil@geog.ubc.ca (Phil Austin)
Date: Thu, 20 Nov 1997 08:11:14 -0800
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
In-Reply-To: <199711200752.IAA22677@nu>
References: <c=UK%a=_%p=Origin-it%l=UKRUX002-971119095409Z-6781@ukrax001.ras.uk.origin-it.com>
<34737594.85A34AA8@verinet.com>
<199711200752.IAA22677@nu>
Message-ID: <199711201611.IAA27286@curlew.geog.ubc.ca>
>>>>> "Rob" == Rob Hooft <R.Hooft@EuroMail.com> writes:
Rob>> min=Numeric.minimum(image0,image1)
Rob>> sum=image0+image1
Rob>> difsquare=(image0-image1)**2
Rob>> condition=Numeric.greater(difsquare,4*sum)
Rob>> # if dif^2>4*sum return 2*min, else return sum
Rob>> result=Numeric.choose(condition,(sum,2*min))
and the obligatory posting from an S-plus expatriate:
if Python adopted Splus-style indexing this could look like:
condition= difsquare > 4*sum
result[condition]=sum
result[!condition]=2*min
Regards, Phil
Phil Austin INTERNET: phil@geog.ubc.ca
(604) 822-2175 FAX: (604) 822-6150
http://www.geog.ubc.ca/~phil
Associate Professor
Atmospheric Sciences Programme
Geography #217
University of British Columbia
1984 W Mall
Vancouver, BC V6T 1Z2
CANADA
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From guido@CNRI.Reston.Va.US Thu Nov 20 20:34:57 1997
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Thu, 20 Nov 1997 15:34:57 -0500
Subject: [MATRIX-SIG] memory leak (fwd)
In-Reply-To: Your message of "Thu, 20 Nov 1997 12:08:29 PST."
<Pine.SUN.3.96.971120120821.28788D-100000@skivs.ski.org>
References: <Pine.SUN.3.96.971120120821.28788D-100000@skivs.ski.org>
Message-ID: <199711202034.PAA07597@eric.CNRI.Reston.Va.US>
From: Conrad Huang %CGL <conrad@cgl.ucsf.edu>
> da@skivs.ski.org (David Ascher) writes:
>
> >Is there a known memory leak in NumPy, with a patch available, or did I
> >just find a new one? I vaguely remember something being talked about
> >months ago, but clearly it hasn't made it in the latest available
> >distribution.
>
> I have a guess as to what the problem may be, and I was going to wait
> until 1.5b1 came out to see if it's already fixed. But now that you
> asked...
[...]
> When Py_BuildValue (in Python/modsupport.c) builds the dictionary, it
> calls do_mkvalue() which calls do_mkdict(), and that's where I think
> the problem is. do_mkdict() goes through a loop whose body is (with
> error checking removed):
>
> k = do_mkvalue(p_format, p_va);
> v = do_mkvalue(p_format, p_va);
> PyDict_SetItem(d, k, v);
>
> Since PyDict_SetItem() increments the reference count of both key and
> value, k and v both have reference counts of 2 when do_mkdict() returns.
> I think there should be:
>
> Py_DECREF(k);
> Py_DECREF(v);
>
> after the call to PyDict_SetItem().
>
> Will someone "in the know" please check my logic? Thanks,
Your logic is flawless. Here's a patch for 1.5a4. Let me know if it
does the trick for you!
--Guido van Rossum (home page: http://www.python.org/~guido/)
Index: modsupport.c
===================================================================
RCS file: /projects/cvsroot/python/dist/src/Python/modsupport.c,v
retrieving revision 2.33
diff -c -r2.33 modsupport.c
*** modsupport.c 1997/11/19 18:53:31 2.33
--- modsupport.c 1997/11/20 20:20:45
***************
*** 169,174 ****
--- 169,175 ----
return NULL;
for (i = 0; i < n; i+= 2) {
PyObject *k, *v;
+ int err;
k = do_mkvalue(p_format, p_va);
if (k == NULL) {
Py_DECREF(d);
***************
*** 180,188 ****
Py_DECREF(d);
return NULL;
}
! if (PyDict_SetItem(d, k, v) < 0) {
! Py_DECREF(k);
! Py_DECREF(v);
Py_DECREF(d);
return NULL;
}
--- 181,190 ----
Py_DECREF(d);
return NULL;
}
! err = PyDict_SetItem(d, k, v);
! Py_DECREF(k);
! Py_DECREF(v);
! if (err < 0) {
Py_DECREF(d);
return NULL;
}
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From da@skivs.ski.org Thu Nov 20 21:09:57 1997
From: da@skivs.ski.org (David Ascher)
Date: Thu, 20 Nov 1997 13:09:57 -0800 (PST)
Subject: [MATRIX-SIG] memory leak (fwd)
In-Reply-To: <199711202034.PAA07597@eric.CNRI.Reston.Va.US>
Message-ID: <Pine.SUN.3.96.971120130701.16789A-100000@skivs.ski.org>
On Thu, 20 Nov 1997, Guido van Rossum wrote:
I asked:
>>>Is there a known memory leak in NumPy, with a patch available, or did I
>>>just find a new one? I vaguely remember something being talked about
>>>months ago, but clearly it hasn't made it in the latest available
>>>distribution.
Conrad Huang %CGL <conrad@cgl.ucsf.edu> said:
>> I have a guess as to what the problem may be, and I was going to wait
>> until 1.5b1 came out to see if it's already fixed. But now that you
>> asked...
>> [...]
>> Will someone "in the know" please check my logic? Thanks,
Guido answered:
> Your logic is flawless. Here's a patch for 1.5a4. Let me know if it
> does the trick for you!
Turns out that wasn't my problem, mine was a bug in another module.
(missing DECREF, again...). Just as well -- we got two bugs with one bug
report. =)
--david
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From chase@att.com Thu Nov 20 21:36:06 1997
From: chase@att.com (Chase, Christopher J (Chris), NNAD)
Date: Thu, 20 Nov 1997 16:36:06 -0500
Subject: [MATRIX-SIG] umath.logical_blah vs normal python functions.
Message-ID: <c=US%a=_%p=ATT%l=NJC240PO03-971120213606Z-6303@njb140bh3.EMS.ATT.COM>
I use these kinds of selection games all the time in other languages.
But with the NumPy choose() function this type of idiom is probably not
needed.
Chris
>----------
>From: Moore, Paul[SMTP:Paul.Moore@uk.origin-it.com]
>Sent: Wednesday, November 19, 1997 4:54 AM
>To: 'David J. C. Beach'
>Cc: 'Matrix SIG'
>Subject: RE: [MATRIX-SIG] umath.logical_blah vs normal python functions.
>
>One advantage of an and/or which returns 1 or 0 is that you can play
>games with it, like multiply it by a constant. Consider
>
> a * logical_and(a,b)
>
>which gives the same values as a where b is nonzero, but zero where b is
>zero. This is the sort of game that gets played in APL all the time....
>(OK, this isn't a very good example, but I can't make up a realistic
>case offhand).
>
>Paul.
>_______________________________________________________
>Paul Moore
>Oracle Development Team,
>Business Application Management, Origin UK (Runcorn).
>Tel : +44 (0)1928 511065
>Fax : +44 (0)1928 515020
>e-mail : paul.moore@uk.origin-it.com
>
>
>>----------
>>From: David J. C. Beach[SMTP:beach@verinet.com]
>>Sent: 19 November 1997 07:36
>>To: richard.jones@bom.gov.au; Matrix SIG
>>Subject: Re: [MATRIX-SIG] umath.logical_blah vs normal python functions.
>>
>>Richard Jones wrote:
>>
>>> Yes, but they're different to what Python does. Well, the && case is
>>> different. Do we need a further umath.python_and that does what Python
>>> programmers expect???
>>
>>A good point. Perhaps what we really want, then, is this:
>>
>>umath.bitwise_and = the C (or Python) operator, &
>>umath.logical_and = the Python 'and' operator
>>
>>etc.
>>
>>After reconsidering it, it seems that a logical_and that returns only a 0 or
>>1
>>doesn't have any significant advantages over Python's 'and', which can be
>>used
>>to selectively evaluate a construct, return the truth value of the logical
>>and, or to selectively give a return value for the last true argument.
>>
>>Dave
>>
>>--
>>David J. C. Beach
>>Colorado State University
>>mailto:beach@verinet.com
>>http://www.verinet.com/~beach
>>
>>
>>
>>
>>_______________
>>MATRIX-SIG - SIG on Matrix Math for Python
>>
>>send messages to: matrix-sig@python.org
>>administrivia to: matrix-sig-request@python.org
>>_______________
>>
>
>_______________
>MATRIX-SIG - SIG on Matrix Math for Python
>
>send messages to: matrix-sig@python.org
>administrivia to: matrix-sig-request@python.org
>_______________
>
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Nov 21 18:07:04 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 21 Nov 1997 19:07:04 +0100
Subject: [MATRIX-SIG] Change slice object?
In-Reply-To: <m0xXaNu-000syBC@lisboa.ifm.uni-kiel.de> (message from Janko
Hauser on Tue, 18 Nov 1997 00:15:14 +0100 (CET))
Message-ID: <199711211807.TAA09078@lmspc1.ibs.fr>
> Also then there is no need for __getitem__ if one uses indexing. But I
> think the method is needed for the for-loop construct, right?
Right. And also for indexing with a single number, e.g. a[5].
> But in every function which deals with slicing, one can be shure to
> get only a tuple of slice objects.
True. Still it would break code that relies on the current interpretation.
It would probably break my netCDF module, for example.
> I don't see, how big the impact of this change would be to the other
> sequence objects in python.
None at all, because only arrays use multidimensional indexing and
slice objects!
> One other idea. What's the way to have a __cmp__ method for slice
> objects to test if a slice is completly in another slice or
> overlapping at both or only one end.
That could easily be done, but what would it be good for?
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jhauser@ifm.uni-kiel.de Mon Nov 24 09:59:11 1997
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Mon, 24 Nov 1997 10:59:11 +0100 (CET)
Subject: [MATRIX-SIG] Change slice object?
In-Reply-To: <199711211807.TAA09078@lmspc1.ibs.fr>
References: <m0xXaNu-000syBC@lisboa.ifm.uni-kiel.de> <199711211807.TAA09078@lmspc1.ibs.fr>
Message-ID: <m0xZvIN-000syBC@lisboa.ifm.uni-kiel.de>
Konrad Hinsen writes:
> > Also then there is no need for __getitem__ if one uses indexing. But I
> > think the method is needed for the for-loop construct, right?
>
> Right. And also for indexing with a single number, e.g. a[5].
>
My idea was that exactly this kind of indexing should also be done by
__getslice__, with the syntax slice(5,6,None). Currently one gets a
mix of two types of indexing (a[5,:,:] for example). But I don't know
the overhead of __getslice__ versus __getitem__
> > But in every function which deals with slicing, one can be shure to
> > get only a tuple of slice objects.
>
> True. Still it would break code that relies on the current interpretation.
> It would probably break my netCDF module, for example.
>
This is truly the bad side of such a change, so I will try to build a
class wich can simplify the handling of indices. First I make a
shadow-class for slice (see end of this mail) and than a
composer class wich handles the index argument of __get{slice,item}__.
> > I don't see, how big the impact of this change would be to the other
> > sequence objects in python.
>
> None at all, because only arrays use multidimensional indexing and
> slice objects!
>
That's good.
> > One other idea. What's the way to have a __cmp__ method for slice
> > objects to test if a slice is completly in another slice or
> > overlapping at both or only one end.
>
> That could easily be done, but what would it be good for?
I cache array slices from netcdf-files and want to see, if a new
request can be taken from the cached arrays or must be loaded from the
file.
Oh, by the way, I want to ask the more OO-knowing people if this is a
appropiate way to handle attribute access.
I have a class wich represents a region. I can slice the region and
the get variables in that region. I catch the request in __getattr__
and load or calculate the desired variable of that region. For the
user this looks like data-access, because she gets an arrayobject. Or
should something like this be implemented with special functions, to
make it clear, that there is something happening?
r[12,8,:,:] # slice the hole region, internally hold only the
# information of the currently activ region
r.temp # if not cached, load data for this region from file
r.vorticity # load u and v and calculate vorticity in this region
r[13,8,:,:] # next timestep ...
The temp and vorticity fields are actually UserArrays, so they know
more about themselves as normal arrays.
__Janko
################## > nslice.py < ##################################
"""
Provides a class for a little bit more handy slice object
called nslice.
1997 Janko Hauser jhauser@ifm.uni-kiel.de
"""
import Numeric
N=Numeric
def test():
"""
main()
Test the nslice class
"""
a = N.arange(12)
sl = slice(0,3,None)
n_sl = nslice(sl)
print 'TEST for same behavior'
print a[sl]
print a[n_sl()]
sl = slice(0,10,2)
n_sl.stop = 10
n_sl.step = 2
print a[sl]
print a[n_sl()]
print 'TEST for comparisson'
print n_sl, sl, cmp(n_sl,sl)
n_sl.stop = 11
print n_sl, sl, cmp(n_sl,sl)
n_sl.step = 3
n_sl.stop = 10
print n_sl, sl, cmp(n_sl,sl)
print 'TEST for error handling'
e_sl = nslice((0, 2, 1))
print
return
nsliceError = "Error in nslice:\n"
class nslice:
"""
slice object with additional methods.
Currently only access to start,stop and step attributes and a way
to compare slices.
"""
def __init__(self, sl):
"""
Initialize a new instance.
"""
if (type(sl) == type(1)):
self.start = sl
self.stop = sl+1
self.step = None
elif (type(sl) == type(slice(0,1,None))):
self.start = sl.start
self.stop = sl.stop
self.step = sl.step
else:
raise nsliceError, \
"Argument must be an integer or a slice object"
return
def __repr__(self):
return 'n'+str(self.__call__())
def __call__(self):
"""
returns the new slice object
"""
return slice(self.start,
self.stop,
self.step)
def __cmp__(self,other):
"""
gives 0 if both slices are identical
gives -1 if first slice is part of second one
gives 1 in all other cases
Problem is the handling of the step attribute. The above
is only true if the steps are the same.
"""
if (type(other) != type(slice(0,1,None))):
raise nsliceError, \
"Both arguments must be slice objects"
if ((self.start == other.start) and
(self.stop == other.stop)):
return cmp(self.step, other.step)
elif ((self.start >= other.start) and (self.stop <= other.stop)):
return -1
else:
return 1
if __name__ == "__main__":
test()
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jhauser@ifm.uni-kiel.de Mon Nov 24 11:44:03 1997
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Mon, 24 Nov 1997 12:44:03 +0100 (CET)
Subject: [MATRIX-SIG] Seg fault with slice
Message-ID: <m0xZwvr-000syBC@lisboa.ifm.uni-kiel.de>
In the attempt to make the nslice object more like a slice I tried a
similar approach like Konrad Hinsen in his indexing.py but get a
seg. fault if len returns sys.maxint. This happens only on Linux not on
an alpha box. There the error is:
[0 1 2]
Traceback (innermost last):
File "nslice.py", line 46, in ?
main()
File "nslice.py", line 23, in main
print a[n_sl]
ValueError: __len__() should return >= 0
Wich I also don't understand, because maxint is clearly greater than
zero.
But this happens on Linux with python1.4 and 1.5a.
Any ideas? seg faults are real show stopper in python.
__Janko
#!/usr/local/bin/python
import Numeric
import sys
N=Numeric
maxint = sys.maxint
def test():
a = N.arange(12)
sl = slice(0,3,None)
n_sl = nslice(sl)
print a[sl]
print a[n_sl]
return
class nslice:
def __init__(self, index, shape=None):
self.index = index
self.maxint = maxint
return
def __getslice__(self):
start = self.index.start
stop = self.index.stop
step = None
return self[start:stop:step]
def __len__(self):
return self.maxint # No seg fault if I return 0
if __name__ == "__main__":
test()
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Mon Nov 24 11:52:24 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 24 Nov 1997 12:52:24 +0100
Subject: [MATRIX-SIG] Change slice object?
In-Reply-To: <m0xZvFt-000syBC@lisboa.ifm.uni-kiel.de> (message from Janko
Hauser on Mon, 24 Nov 1997 10:56:37 +0100 (CET))
Message-ID: <199711241152.MAA19411@lmspc1.ibs.fr>
> > > Also then there is no need for __getitem__ if one uses indexing. But I
> > > think the method is needed for the for-loop construct, right?
> >
> > Right. And also for indexing with a single number, e.g. a[5].
> >
> My idea was that exactly this kind of indexing should also be done by
> __getslice__, with the syntax slice(5,6,None). Currently one gets a
But what good would this be, as long as the interpreter always calls
__getitem__ for single number indices? And that can't be changed
without creating backwards compatibility problems.
On the other hand, it's nearly trivial to write an implementation of
__getitem__ that simple calls __getslice__ with the right arguments.
> This is truly the bad side of such a change, so I will try to build a
> class wich can simplify the handling of indices. First I make a
> shadow-class for slice (see end of this mail) and than a
> composer class wich handles the index argument of __get{slice,item}__.
That's close to how I do C implementations of indexing (see e.g.
the netCDF module). The interface functions called by the Python
interpreter just create a unified representation of the index request,
and the real work is done by a single function for all types of
indexing.
> > > One other idea. What's the way to have a __cmp__ method for slice
> > > objects to test if a slice is completly in another slice or
> > > overlapping at both or only one end.
> >
> > That could easily be done, but what would it be good for?
> I cache array slices from netcdf-files and want to see, if a new
> request can be taken from the cached arrays or must be loaded from the
> file.
OK, that makes sense. Adding comparison and hashing would make
slice objects suitable for all kinds of list and dictionary
operations.
> I have a class wich represents a region. I can slice the region and
> the get variables in that region. I catch the request in __getattr__
> and load or calculate the desired variable of that region. For the
> user this looks like data-access, because she gets an arrayobject. Or
> should something like this be implemented with special functions, to
> make it clear, that there is something happening?
If something looks like an attribute, then it should act like
an attribute, i.e.:
- it should always return the same value, unless the attribute
has been changed in the meantime
- changes should be possible by assignments (unless the attributes
are read-only, of course, in which case an exception should be
raised for an attempted assignment)
Within these limits, it's a pure implementation decision how the
data is obtained.
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Mon Nov 24 17:10:39 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 24 Nov 1997 18:10:39 +0100
Subject: [MATRIX-SIG] Seg fault with slice
In-Reply-To: <m0xZwvr-000syBC@lisboa.ifm.uni-kiel.de> (message from Janko
Hauser on Mon, 24 Nov 1997 12:44:03 +0100 (CET))
Message-ID: <199711241710.SAA21680@lmspc1.ibs.fr>
> In the attempt to make the nslice object more like a slice I tried a
> similar approach like Konrad Hinsen in his indexing.py but get a
> seg. fault if len returns sys.maxint. This happens only on Linux not on
> an alpha box. There the error is:
I don't quite understand your code. What is nslice supposed to do?
As it is now, the __getslice__ method of nslice never gets called,
which doesn't seem intentional. When you index the array with an
nslice object, NumPy sees it as a sequence. It asks for the length
and finds maxint, meaning maxint dimensions! I didn't check in detail
where the crash comes from, but I suppose it's some kind of memory
overflow due an extremely unreasonable request.
I *suppose* you want a[n_sl] to call the __getslice__ method,
but that doesn't happen!
In fact, your whole approach won't work, because array objects currently
accept only integers and slice objects in an indexing tuple.
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From viennet@lipn.univ-paris13.fr Mon Nov 24 20:02:59 1997
From: viennet@lipn.univ-paris13.fr (viennet@lipn.univ-paris13.fr)
Date: Mon, 24 Nov 1997 20:02:59 GMT
Subject: [MATRIX-SIG] Seg fault with slice
In-Reply-To: <m0xZwvr-000syBC@lisboa.ifm.uni-kiel.de>
References: <m0xZwvr-000syBC@lisboa.ifm.uni-kiel.de>
Message-ID: <199711242002.UAA06968@montana.univ-paris13.fr>
Janko Hauser writes:
>
> Any ideas? seg faults are real show stopper in python.
>
Thanks to people like yourself, experimenting strange ideas, seg
faults are exceptional...
I didn't understood your example, but Python should not crash.
The bug is in NumPy/arrayobject.c. Here is a quick patch:
646,647c646,651
< if (!is_slice) op1 = PySequence_GetItem(op, i);
<
---
> if (!is_slice) {
> if (!(op1=PySequence_GetItem(op, i))) {
> PyErr_SetString(PyExc_IndexError, "invalid index");
> return -1;
> }
> }
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jhauser@ifm.uni-kiel.de Mon Nov 24 20:07:38 1997
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Mon, 24 Nov 1997 21:07:38 +0100 (CET)
Subject: [MATRIX-SIG] Seg fault with slice
Message-ID: <m0xa4nC-000stZC@lisboa.ifm.uni-kiel.de>
Ha, as Konrad has ``clearly'' shown my first try was stupid, heh it
was a try :-). The result of the second try is nslice.py, which isn't
totally stupid, although the __cmp__ is not really satisfactory. I
think to use xrange to build the indices, but the result of cmp of two
xranges is also not easy to interpret. Will see.
But many thanks for the patch. Do the people from LLNL save this
patch?
__Janko
viennet@lipn.univ-paris13.fr writes:
>
> Janko Hauser writes:
> >
> > Any ideas? seg faults are real show stopper in python.
> >
>
> Thanks to people like yourself, experimenting strange ideas, seg
> faults are exceptional...
>
> I didn't understood your example, but Python should not crash.
> The bug is in NumPy/arrayobject.c. Here is a quick patch:
>
> 646,647c646,651
> < if (!is_slice) op1 = PySequence_GetItem(op, i);
> <
> ---
> > if (!is_slice) {
> > if (!(op1=PySequence_GetItem(op, i))) {
> > PyErr_SetString(PyExc_IndexError, "invalid index");
> > return -1;
> > }
> > }
>
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Nov 28 09:57:07 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 28 Nov 1997 10:57:07 +0100
Subject: [MATRIX-SIG] Updated "Easy-Install" NumPy
Message-ID: <199711280957.KAA14888@lmspc1.ibs.fr>
There's a new version of "Easy-Install NumPy" at
http://starship.skyport.net/crew/hinsen/numpy.tar.gz
This version will work with 1.5b1 - the installation script had
to be modified due to a change in the library directory names.
BTW, is anyone using this version? There hasn't been much feedback...
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Nov 28 10:10:55 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 28 Nov 1997 11:10:55 +0100
Subject: [MATRIX-SIG] Yet another random number generator
Message-ID: <199711281010.LAA14920@lmspc1.ibs.fr>
Random number addicts face a tough choice in the Python world; there
are already various random number modules in various places. And I
just another yet another one:
http://starship.skyport.net/crew/hinsen/RNGmodule.tar.gz
To get some order into this chaos, here's an overview of what
is available:
1) whrandom, in the Python standard library
Multiple independent random generators for the uniform [0, 1)
distribution. Implemented in Python, returns single numbers.
2) random, in the Python standard library
Built on whrandom, extends it with a large choice of common
distributions.
3) RandomArray, in NumPy
An interface to the Fortran library RANLIB, but it contains
only the uniform distribution (RANLIB has a bit more).
Only one random number stream. Returns single numbers or arrays
of random numbers.
4) URNG, by Paul Dubois, available from the LLNL ftp server.
Multiple independent random generators for the uniform [0, 1)
distribution. Implemented in C, returns single numbers or
arrays.
For any serious work, a C implementation (for speed) and independent
random number streams are essential, so URNG is the only choice.
And there is nothing wrong with it, as long as you want a uniform
distribution.
My RNG module is in fact nothing but an enhanced version of URNG
which adds other distributions (currently normal and exponential).
It can be used as a drop-in replacement for URNG. In addition to
random generator objects, it defines distribution objects that
can be attached to a random number stream.
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From gustav@morpheus.demon.co.uk Fri Nov 28 21:52:19 1997
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Fri, 28 Nov 1997 21:52:19 GMT
Subject: [MATRIX-SIG] Updated "Easy-Install" NumPy
In-Reply-To: <199711280957.KAA14888@lmspc1.ibs.fr>
References: <199711280957.KAA14888@lmspc1.ibs.fr>
Message-ID: <34813cdc.2713938@post.demon.co.uk>
On Fri, 28 Nov 1997 10:57:07 +0100, Konrad Hinsen <hinsen@ibs.ibs.fr>
wrote:
>There's a new version of "Easy-Install NumPy" at
>
> http://starship.skyport.net/crew/hinsen/numpy.tar.gz
>
>This version will work with 1.5b1 - the installation script had
>to be modified due to a change in the library directory names.
>
>BTW, is anyone using this version? There hasn't been much feedback...
Is this a "build-it-yourself" file, or a Win32 binary? If the former,
is the latter available anywhere?
Paul Moore.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Sat Nov 29 16:12:22 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sat, 29 Nov 1997 17:12:22 +0100
Subject: [MATRIX-SIG] Updated "Easy-Install" NumPy
In-Reply-To: <34813cdc.2713938@post.demon.co.uk> (message from Paul Moore on
Fri, 28 Nov 1997 21:52:19 GMT)
Message-ID: <199711291612.RAA20996@lmspc1.ibs.fr>
> >This version will work with 1.5b1 - the installation script had
> >to be modified due to a change in the library directory names.
> >
> >BTW, is anyone using this version? There hasn't been much feedback...
>
> Is this a "build-it-yourself" file, or a Win32 binary? If the former,
> is the latter available anywhere?
It's a source code distribution with installation scripts for
Unix. I have no idea whether it is usable and/or has any advantages
on Windows.
--
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________