From ptfenn@yahoo.com Mon Nov 1 15:33:19 1999
From: ptfenn@yahoo.com (Tom Fenn)
Date: Mon, 1 Nov 1999 10:33:19 -0500
Subject: [Matrix-SIG] Using contiguous arrays with normal C syntax
Message-ID: <02e001bf247e$70729560$14996382@mmm.com>
Hello:
I'm trying to use contiguous arrays using the normal C syntax. Here's some
code that shows what I'm trying to do:
PyObject *myfunction(PyObject *self,PyObject *args) {
PyObject *input;
PyArrayObject *array
double **data;
double x;
int i,j;
PyArg_ParseTuple(args,"O",&input);
array = (PyArrayObject *) PyArray_ContiguousFromObject(input,
PyArray_DOUBLE,2,2);
data = (double **) array->data;
for (i=0;i<10;i++) {
for (j=0;j<10;j++) {
x = data[i][j];
}
}
Py_INCREF(Py_None);
return Py_None;
}
The data[i][j] line causes a seg fault. If I rewrite the line inside the
loops as:
x = *(double *) (array->data+i*array->strides[0]+j*array->strides[1]);
then everything is fine. Seems I don't understand the relationship between
pointers and arrays in C as well as I thought I did. Can anyone tell me
what I'm doing wrong?
Tom Fenn
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From dubois1@llnl.gov Mon Nov 1 16:00:04 1999
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Mon, 1 Nov 1999 08:00:04 -0800
Subject: [Matrix-SIG] Using contiguous arrays with normal C syntax
References: <02e001bf247e$70729560$14996382@mmm.com>
Message-ID: <000701bf2482$298e4000$3c810b18@plstn1.sfba.home.com>
> data = (double **) array->data;
Tom,
Your problem is that array->data is a double*, not a double**. C allows you
to create a two-dimensional array as an array of pointers, each pointing to
an array of data, but that isn't how Numerical does it, for efficiency
reasons.
You don't want to be multiplying by strides in your "solution". Having made
the data contiguous, treat it as if it were a one-dimensional array so the
i, j 'th component is
array->data[j + i * array->dimensions[0]]
(I'm doing this off the top of my head so I may not have remembered the name
of the dimension array correctly.)
From pearu@ioc.ee Mon Nov 1 17:32:01 1999
From: pearu@ioc.ee (Pearu Peterson)
Date: Mon, 1 Nov 1999 19:32:01 +0200 (EET)
Subject: [Matrix-SIG] Bug in generating .pyc files?
Message-ID: <Pine.HPX.4.05.9911011907520.9673-100000@egoist.ioc.ee>
Hi,
I have found the following problem:
I have created a Python program and it works correctly on the first run.
On the second (third,etc) run it works incorrectly.
When I delete the .pyc file or edit the program, the same behaviour
occurs: on the first run everything is OK, but on the following runs it
works incorrectly again.
So, I conclude that the code in .pyc file is incorrect (may be due to my
incorrect program, but it shouldn't run on the first run, either).
Unfortunately, I cannot give you much of details since my program is
rather large and I don't know where to start looking for my or .pyc file
bugs.
Any ideas?
I will sketch how my program works:
There is two python files: sub.py, main.py.
sub.py contains lots of useful functions that use global variables.
main.py imports sub.py and calls these useful functions.
Before the call, main.py changes the global variables in sub.py
(In main.py 'sub.global_var=value', for example).
My (pythons?) problem occures in the following:
> python main.py
Correct result
> python main.py
Incorrect result (meaning, strange behaviour)
> rm sub.pyc
> python main.py
Correct result
> python main.py
Incorrect result
etc.
Again, any ideas what could be the problem?
Thanks,
Pearu
Pearu Peterson <pearu@ioc.ee>, MSc, Researcher
Department of Mechanics and Applied Mathematics http://koer.ioc.ee/~pearu/
Institute of Cybernetics at Tallinn Technical University Phone: (+372) 6204168
Akadeemia Rd. 21, 12618 Tallinn ESTONIA Fax: (+372) 6204161
*** the nonvalidity of rigorous causality is necessary
and not just consistently possible (Heisenberg, 1925) ***
From pearu@ioc.ee Mon Nov 1 18:12:12 1999
From: pearu@ioc.ee (Pearu Peterson)
Date: Mon, 1 Nov 1999 20:12:12 +0200 (EET)
Subject: [Matrix-SIG] Bug in generating .pyc files!!!
Message-ID: <Pine.HPX.4.05.9911011958590.10147-100000@egoist.ioc.ee>
I was able to track down where is the bug and I will demonstrate it below.
Let main.py be:
#!/usr/bin/env python
import sub
sub.sub()
# EOF main.py
and let sub.py be:
def sub():
for l in ['1 2','3 4']:
if l[1] is ' ':
flag=1
else:
flag=0
print flag,`l`
#EOF sub.py
Here are the results of repeated calls of main.py:
> python main.py
1 '1 2'
1 '3 4'
> python main.py
0 '1 2'
0 '3 4'
> python main.py
0 '1 2'
0 '3 4'
etc
Note that program works correctly if line
if l[1] is ' ':
is replaced with
if l[1]==' ':
of course.
I am using
Python 1.5.2 (#4, Oct 26 1999, 18:40:59) [GCC egcs-2.91.66 19990314/Linux
(egcs- on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
So, it seems that 'is' is interpreted differently when .pyc file is used.
I think this is a serious problem and should be fixed.
With regards,
Pearu
Pearu Peterson <pearu@ioc.ee>, MSc, Researcher
Department of Mechanics and Applied Mathematics http://koer.ioc.ee/~pearu/
Institute of Cybernetics at Tallinn Technical University Phone: (+372) 6204168
Akadeemia Rd. 21, 12618 Tallinn ESTONIA Fax: (+372) 6204161
*** the nonvalidity of rigorous causality is necessary
and not just consistently possible (Heisenberg, 1925) ***
From just@letterror.com Mon Nov 1 18:38:00 1999
From: just@letterror.com (Just van Rossum)
Date: Mon, 1 Nov 1999 19:38:00 +0100
Subject: [Matrix-SIG] Bug in generating .pyc files!!!
In-Reply-To: <Pine.HPX.4.05.9911011958590.10147-100000@egoist.ioc.ee>
Message-ID: <l03102805b4438de83e50@[193.78.237.136]>
>So, it seems that 'is' is interpreted differently when .pyc file is used.
>I think this is a serious problem and should be fixed.
The 'is' operator tests for object identity, only use it when you know what
you're doing ;-). You need the '==' operator.
Just
From da@ski.org Mon Nov 1 18:54:35 1999
From: da@ski.org (David Ascher)
Date: Mon, 1 Nov 1999 10:54:35 -0800 (Pacific Standard Time)
Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!!
In-Reply-To: <Pine.HPX.4.05.9911011958590.10147-100000@egoist.ioc.ee>
Message-ID: <Pine.WNT.4.04.9911011040260.285-100000@rigoletto.ski.org>
On Mon, 1 Nov 1999, Pearu Peterson wrote: [in the MATRIX-SIG, although i
don't know why!]
> I was able to track down where is the bug and I will demonstrate it below.
> Let main.py be:
#!/usr/bin/env python
import sub
sub.sub()
# EOF main.py
(here's DA's minimal version of Pearu's code):
def sub():
l = ' '
print l[0] is l
Here are the results of repeated calls of main.py:
> python main.py
1
> python main.py
0
> python main.py
0
> So, it seems that 'is' is interpreted differently when .pyc file is used.
> I think this is a serious problem and should be fixed.
I agree. FWIW, IMO the right thing to do is to have the test return false
all the time, but I agree that there should not be a dependence on
byte-compilation.
Guido?
--david
From guido@CNRI.Reston.VA.US Mon Nov 1 19:51:09 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 01 Nov 1999 14:51:09 -0500
Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!!
In-Reply-To: Your message of "Mon, 01 Nov 1999 10:54:35 PST."
<Pine.WNT.4.04.9911011040260.285-100000@rigoletto.ski.org>
References: <Pine.WNT.4.04.9911011040260.285-100000@rigoletto.ski.org>
Message-ID: <199911011951.OAA06335@eric.cnri.reston.va.us>
> On Mon, 1 Nov 1999, Pearu Peterson wrote: [in the MATRIX-SIG, although i
> don't know why!]
>
> > I was able to track down where is the bug and I will demonstrate it below.
> > Let main.py be:
>
> #!/usr/bin/env python
> import sub
> sub.sub()
> # EOF main.py
>
> (here's DA's minimal version of Pearu's code):
>
> def sub():
> l = ' '
> print l[0] is l
>
> Here are the results of repeated calls of main.py:
>
> > python main.py
> 1
> > python main.py
> 0
> > python main.py
> 0
>
> > So, it seems that 'is' is interpreted differently when .pyc file is used.
> > I think this is a serious problem and should be fixed.
>
> I agree. FWIW, IMO the right thing to do is to have the test return false
> all the time, but I agree that there should not be a dependence on
> byte-compilation.
>
> Guido?
The result of the 'is' operator on immutable objects (like strings)
not well-defined. The Python VM is allowed but not required to cache
objects with certain values and reuse them as the outcome of certain
expressions (such as l[0] above) is it sees fit to optimize speed.
The solution is not to use 'is' here but always to use '==' when
comparing strings.
This is definitely not a bug and definitely does not need to be fixed.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From tim_one@email.msn.com Tue Nov 2 04:18:55 1999
From: tim_one@email.msn.com (Tim Peters)
Date: Mon, 1 Nov 1999 23:18:55 -0500
Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!!
In-Reply-To: <Pine.WNT.4.04.9911011040260.285-100000@rigoletto.ski.org>
Message-ID: <000601bf24e9$614428e0$0f2d153f@tim>
[David Ascher, whittles down Pearu Peterson's "bug", which boils down
to the unpredictability of "is" when applied to strings]
[PP]
> I think this is a serious problem and should be fixed.
[DA]
> I agree. FWIW, IMO the right thing to do is to have the test return false
> all the time, but I agree that there should not be a dependence on
> byte-compilation.
>
> Guido?
Since he doesn't seem to be around, I'll channel him <wink>. "is" tests
object identity, and so exposes accidents of the implementation if used in
ill-advised ways. For immutable objects (like strings!) in particular, the
implementation is free to reuse them *or* copy them at will, and whether
e.g.
"this works?"[-1] is "?"
returns true can vary from release to release, platform to platform, or even
from run to run.
OTOH, constructors for *mutable* objects always create fresh objects, so
[] is []
is guaranteed to return false everywhere. About the only guarantee you get
for immutable objects is that
x is y
will return true if it follows
x = y
and neither name is rebound between them. If x and y are *computed*
immutable values, nothing can be said a priori about the result of "x is y",
beyond that x != y implies x is not y.
IOW, the bug here was the use of "is" to begin with; object identity was
simply not what the program intended to test.
can't-remove-the-bug-without-removing-the-feature-too-ly y'rs - tim
From skaller@maxtal.com.au Tue Nov 2 13:24:46 1999
From: skaller@maxtal.com.au (skaller)
Date: Wed, 03 Nov 1999 00:24:46 +1100
Subject: [Matrix-SIG] Re: Bug in generating .pyc files!!!
References: <Pine.WNT.4.04.9911011040260.285-100000@rigoletto.ski.org> <199911011951.OAA06335@eric.cnri.reston.va.us>
Message-ID: <381EE61E.2CB58F2B@maxtal.com.au>
Guido van Rossum wrote:
>
> The result of the 'is' operator on immutable objects (like strings)
> not well-defined. The Python VM is allowed but not required to cache
> objects with certain values and reuse them as the outcome of certain
> expressions (such as l[0] above) is it sees fit to optimize speed.
>
> The solution is not to use 'is' here but always to use '==' when
> comparing strings.
>
> This is definitely not a bug and definitely does not need to be fixed.
FYI: Viper uses value comparisons on immutable objects; that is,
'is' and '==' are the same.
--
John Skaller, mailto:skaller@maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller
From olafb@pvv.org Tue Nov 2 12:57:02 1999
From: olafb@pvv.org (Olaf Trygve Berglihn)
Date: 02 Nov 1999 13:57:02 +0100
Subject: [Matrix-SIG] Optimization routines - anyone?
Message-ID: <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>
Has someone coded a collection of optimization routines, e.g. SQP, for
use with NumPy?
Olaf
janne@avocado.ps.helsinki.fi wrote 15 Mar 1999 23:09:22 +0200:
|"Paul F. Dubois" <dubois1@llnl.gov> writes:
|> The conjugate gradient algorithm is probably about twenty lines or
|> less of matrix/vector statements in Python, assuming you have a
|> preconditioner you can express that way. So just code it up in
|> Python. It will be fast enough, all the hard work is in the dot
|> products and matrix multiplies.
|I'm coding right now, just wanted to know if somebody has already
|done it.
|The hard work is often in the objective function, and from this
|viewpoing C is unnecessary unless the objective function is very
|fast. But a larger selection of optimization routines, either in
|Python or in C, would be nice (and probably emerges) sooner or later.
|--
|Janne
--
* Olaf Trygve Berglihn <olafb@pvv.org>
From janne@nnets.fi Tue Nov 2 13:32:42 1999
From: janne@nnets.fi (Janne Sinkkonen)
Date: 02 Nov 1999 15:32:42 +0200
Subject: [Matrix-SIG] Re: Optimization routines - anyone?
In-Reply-To: Olaf Trygve Berglihn's message of "02 Nov 1999 13:57:02 +0100"
References: <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>
Message-ID: <m366zlnhmt.fsf@kinos.nnets.fi>
Olaf Trygve Berglihn <olafb@pvv.org> writes:
> Has someone coded a collection of optimization routines, e.g. SQP, for
> use with NumPy?
Travis Oliphant has this: http://oliphant.netpedia.net/multipack.html
I have a simple conjugate gradient and line minimization routines coded
in Python (from Numeric Recipes).
I'd also be interested in Python bindings to SQP.
--
Janne
From robin@jessikat.demon.co.uk Tue Nov 2 13:36:43 1999
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Tue, 2 Nov 1999 13:36:43 +0000
Subject: [Matrix-SIG] Optimization routines - anyone?
In-Reply-To: <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>
References: <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>
Message-ID: <zqANdAArjuH4EwkK@jessikat.demon.co.uk>
In article <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>, Olaf Trygve Berglihn
<olafb@pvv.org> writes
>
>Has someone coded a collection of optimization routines, e.g. SQP, for
>use with NumPy?
>
>Olaf
>
I've just been playing with Burke & Xu's non-interior point method for
LCP's. I posted asking where this should be displayed/made available.
Got no response.
>janne@avocado.ps.helsinki.fi wrote 15 Mar 1999 23:09:22 +0200:
>|"Paul F. Dubois" <dubois1@llnl.gov> writes:
>
>|> The conjugate gradient algorithm is probably about twenty lines or
>|> less of matrix/vector statements in Python, assuming you have a
>|> preconditioner you can express that way. So just code it up in
>|> Python. It will be fast enough, all the hard work is in the dot
>|> products and matrix multiplies.
>
>|I'm coding right now, just wanted to know if somebody has already
>|done it.
>
>|The hard work is often in the objective function, and from this
>|viewpoing C is unnecessary unless the objective function is very
>|fast. But a larger selection of optimization routines, either in
>|Python or in C, would be nice (and probably emerges) sooner or later.
>
>|--
>|Janne
>
>
--
Robin Becker
From olafb@pvv.org Tue Nov 2 14:55:58 1999
From: olafb@pvv.org (Olaf Trygve Berglihn)
Date: 02 Nov 1999 15:55:58 +0100
Subject: [Matrix-SIG] Optimization routines - anyone?
In-Reply-To: Robin Becker's message of "Tue, 2 Nov 1999 13:36:43 +0000"
References: <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no> <zqANdAArjuH4EwkK@jessikat.demon.co.uk>
Message-ID: <dn1eme99c3l.fsf@kallesol.pvv.ntnu.no>
Hi, Robin.
I don't know much about the method you are referring to, but you could
possibly put it in ftp://ftp.python.org/pub/python/contrib/Math
Look at instructions in ftp://ftp.python.org/incoming-instructions
I guess that Travis Oliphant's multipack-site is a good place for
optimization stuff. But if it's not convenient to put it there, I
could make room for it at my place. It is not likely that I will make
major contrubutions in this field, though. Optimization alorithms is
not my speciality.
Olaf
* Robin Becker
| In article <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>, Olaf Trygve Berglihn
| <olafb@pvv.org> writes
| >
| >Has someone coded a collection of optimization routines, e.g. SQP, for
| >use with NumPy?
| >
| >Olaf
| >
|
| I've just been playing with Burke & Xu's non-interior point method for
| LCP's. I posted asking where this should be displayed/made available.
| Got no response.
--
* Olaf Trygve Berglihn <olafb@pvv.org>
From Oliphant.Travis@mayo.edu Tue Nov 2 18:35:49 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Tue, 2 Nov 1999 12:35:49 -0600 (CST)
Subject: [Matrix-SIG] Optimization algorithms, etc.
Message-ID: <Pine.LNX.4.10.9911021216200.2221-100000@us2.mayo.edu>
Robin,
I remember your posting about Burke and Xu's LCP method and was
interested, but October was a busy paper-writing month for me and so I
spent all my time using Python and very little developing and
communicating and none packaging.
My vision for multipack is that it would be a community effort and your
algorithm could find a very nice home there. Development of multipack
takes place on a CVS server graciously provided by Pearu Peterson who
has also contributed significantly to Multipack that I could get you
access to. Alternatively, you could just send a tarball to me. But I
have to admit that I'd prefer if authors took care of incorporating their
own packages, as it would be more likely to show up in future editions.
Multipack is very modular, so your wrapping could be dropped into the
overall umbrella quite easily. There is documentation about how to do it
in the release.
I haven't checked this recently but you should be able to check out
multipack from CVS anonymously (it's pretty big right now as it includes
some alpha wrappings of all of the lapack and blas -- auto generated by
Pearu's f2py code) so you might just want to get the tarball from my site.
I'm very willing to receive improvements to Multipack from individuals
anxious to see Numeric Python become a top-notch environment for
general-purpose number crunching and algorithm development.
I have not worked on Multipack actively for several months, and
so my plan of incorporating all of my modules (signaltools,
cephes, etc. into the multipack structure has not been
realized...perhaps this is not such a good plan anyway
(thoughts?) )
Sorry I did not get contact you sooner, it can be frustrating when you
make this really neat algorithm available to Python and nobody seems to
care. My experience is that people care quite a bit, but are pretty busy
and don't have time to help so they are reluctant to comment.
--Travis Oliphant
P.S.
For those on matrix-sig interested in the sparse matrix development:
Currently, I'm improving the sparse matrix package that I discussed on
this list several months ago so that it is actually useful to solve
partial differential equations using finite elements and finite
differences. I'm working on incorporating the package SuperLU for
directly solving a sparse linear system and implementing at least the
conjugate gradient algorithm (in Python) for iteratively solving the
system.
From robin@jessikat.demon.co.uk Tue Nov 2 16:31:34 1999
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Tue, 2 Nov 1999 16:31:34 +0000
Subject: [Matrix-SIG] Optimization routines - anyone?
In-Reply-To: <dn1eme99c3l.fsf@kallesol.pvv.ntnu.no>
References: <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>
<zqANdAArjuH4EwkK@jessikat.demon.co.uk>
<dn1eme99c3l.fsf@kallesol.pvv.ntnu.no>
Message-ID: <Vlj0uIAmHxH4EwRa@jessikat.demon.co.uk>
In article <dn1eme99c3l.fsf@kallesol.pvv.ntnu.no>, Olaf Trygve Berglihn
<olafb@pvv.org> writes
>Hi, Robin.
>I don't know much about the method you are referring to, but you could
>possibly put it in ftp://ftp.python.org/pub/python/contrib/Math
>Look at instructions in ftp://ftp.python.org/incoming-instructions
>
>I guess that Travis Oliphant's multipack-site is a good place for
>optimization stuff. But if it's not convenient to put it there, I
>could make room for it at my place. It is not likely that I will make
>major contrubutions in this field, though. Optimization alorithms is
>not my speciality.
>
>Olaf
>
others suggest I package it up and put it on my home page. I just
thought there have been a few questions like yours recently.
>* Robin Becker
>| In article <dn1puxt9hlt.fsf@kallesol.pvv.ntnu.no>, Olaf Trygve Berglihn
>| <olafb@pvv.org> writes
>| >
>| >Has someone coded a collection of optimization routines, e.g. SQP, for
>| >use with NumPy?
>| >
>| >Olaf
>| >
>|
>| I've just been playing with Burke & Xu's non-interior point method for
>| LCP's. I posted asking where this should be displayed/made available.
>| Got no response.
>
--
Robin Becker
From robin@jessikat.demon.co.uk Tue Nov 2 18:57:36 1999
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Tue, 2 Nov 1999 18:57:36 +0000
Subject: [Matrix-SIG] Optimization algorithms, etc.
In-Reply-To: <Pine.LNX.4.10.9911021216200.2221-100000@us2.mayo.edu>
References: <Pine.LNX.4.10.9911021216200.2221-100000@us2.mayo.edu>
Message-ID: <RG4p8DAgQzH4EwTb@jessikat.demon.co.uk>
In article <Pine.LNX.4.10.9911021216200.2221-100000@us2.mayo.edu>,
Travis Oliphant <Oliphant.Travis@mayo.edu> writes
this particular algorithm is pure pyton+NumPy so I'll just post it to
Travis. I have a C QP algorithm which I would like to package a bit more
neatly before hacking that out.
>
>Robin,
>
>I remember your posting about Burke and Xu's LCP method and was
>interested, but October was a busy paper-writing month for me and so I
>spent all my time using Python and very little developing and
>communicating and none packaging.
>
>My vision for multipack is that it would be a community effort and your
>algorithm could find a very nice home there. Development of multipack
>takes place on a CVS server graciously provided by Pearu Peterson who
>has also contributed significantly to Multipack that I could get you
>access to. Alternatively, you could just send a tarball to me. But I
>have to admit that I'd prefer if authors took care of incorporating their
>own packages, as it would be more likely to show up in future editions.
>Multipack is very modular, so your wrapping could be dropped into the
>overall umbrella quite easily. There is documentation about how to do it
>in the release.
>
>I haven't checked this recently but you should be able to check out
>multipack from CVS anonymously (it's pretty big right now as it includes
>some alpha wrappings of all of the lapack and blas -- auto generated by
>Pearu's f2py code) so you might just want to get the tarball from my site.
>
>I'm very willing to receive improvements to Multipack from individuals
>anxious to see Numeric Python become a top-notch environment for
>general-purpose number crunching and algorithm development.
>
>I have not worked on Multipack actively for several months, and
>so my plan of incorporating all of my modules (signaltools,
>cephes, etc. into the multipack structure has not been
>realized...perhaps this is not such a good plan anyway
>(thoughts?) )
>
>Sorry I did not get contact you sooner, it can be frustrating when you
>make this really neat algorithm available to Python and nobody seems to
>care. My experience is that people care quite a bit, but are pretty busy
>and don't have time to help so they are reluctant to comment.
>
>
>--Travis Oliphant
>
>P.S.
>
>For those on matrix-sig interested in the sparse matrix development:
>
>Currently, I'm improving the sparse matrix package that I discussed on
>this list several months ago so that it is actually useful to solve
>partial differential equations using finite elements and finite
>differences. I'm working on incorporating the package SuperLU for
>directly solving a sparse linear system and implementing at least the
>conjugate gradient algorithm (in Python) for iteratively solving the
>system.
>
>
>
>
>_______________________________________________
>Matrix-SIG maillist - Matrix-SIG@python.org
>http://www.python.org/mailman/listinfo/matrix-sig
--
Robin Becker
From siegel@eico.com" <siegel@eico.com Wed Nov 3 00:03:59 1999
From: siegel@eico.com" <siegel@eico.com (siegel)
Date: Tue, 2 Nov 1999 19:03:59 -0500
Subject: [Matrix-SIG] vecmath lib for Python
Message-ID: <01BF25DF.3D586080.siegel@eico.com>
Attached
Python vecmath Version .20
November 2, 1999
Done by Arthur Siegel, ajs@ix.netcom.com <mailto:ajs@ix.netcom.com>
Based on the following suppositions:
1- libraries are good for, among other things, helping
people d oing similar things stay on the same page, and
develop off one another
2-libraries without good documentation aren't very useful.
3-writing code is more fun than writing documentation
4-writing Python is more fun than writing Java.
5-I would like more company in writing 3d OpenGL stuff off of Python
and there might be a population of folks who are interested in 3d but
not particularly interested in wading into the Numeric library directly.
the following arrangement was (wink) reached with the folks at
Sun MicroSystems:
I allowed them to port my vecmath library extension to Numeric as a
Java3d extension in exchange for their services in writing documentation
They have done a credible job. It is available as part of the Java3d
documentation at <http://java.sun.com/products/java-media/3D/>
I am looking for feedback, suggestions, help. My quaternion understanding sucks.
I also have some PyOpenGL stuff ('dynamic geometry') written off of the vecmath library that I will be
trying to talk David Ascher into including in the demos of the distribution, once I scale it down a bit to demo size.
I would be happy to have anyone take a look but am without a site presence.
Email me if interested.
begin 600 pythonx.zip
M4$L#!!0````(``:28B?PZ_\NNA4``"YS```*````=F5C;6%T:"YP>>4]_6_C
MQK$_.X#_!^(.@4F9THFDV[XZ48!KFP(')$&;!$6;JR'0$N5C(%(R2?ET_NL[
MN[,?L\LE1<FZOO8]((&IW=GYVMF9V=TA;U5M"N^'79%5^<++B^VF:KS1Y1<K
MUOQ=7F9I]7;]D-U7*>F\_$(\UTV5EP_ZYZ>:=2[6:5U[\S^D=?:VJM)/MY=?
M7"RSE3>?YV7>S.=^G:U78<JZUEGYT'P(FT_;;+%99F'](=UFLQ\V91:.TNJA
M#MC8"P8_J;)MY<T$R4F]7>>-#S\XLLE\SHG.YT%X-;D*WH^C.S60$)J19]4O
MB<_D`^O)5QZCS\E?7+#'&0?>E57ZE*U]SAQV`B@;R9O>3^^"&4=43]Z5S<_P
MX&TJ=_^?UYN40P@B#!&PAJAGE%4)0.3!;A^!E?X$1Q?9NE98+[*J`CV!ZJ[R
M]3I[2-=>N2ONL\K;K+QEVJ1,4)C_LJEOO7^6WI>U5V6/N[S*:O:L.LT?#_E3
M5EYY7_IJ;D);V:$21K)U4:5YG7D_?:J;K/BVJC95B,QA?[;N5F7=I.4BH]KB
MY.JL^3-8JNRGTT)UL 6;:;3\BPW 5[M%`U.S@O\YTU<"ML4C:]?(@$4E\FQV
M]7:?UV_+AW5VL[P2U-J3-)U,0_9_A'_M^2*<DK'/6;6I?=<J"93ISF436QAJ
MJ+)H/Q"FC'W%_!Z6Y"0O<+$PY67K#&>>DT><I-G7I'!E$B*\@2UWOK;ENN!+
M^RE;X,+]^"%?9UY>YW)^H ?F-<19_7FW7?,I#=@:Z8+Z+J\;!<06/+<0! G
M0EY]S1J\*YS$;UZA*- _0QA/BR:99/RQUBIK=E7IK8&":%.>BDVO\%0HBH#5
MKNC:8W]\K9'@/3/X5_SY57![1[#Q-NGX&N[?$"LS^%OD4!!(:S0:C3=L*+/M
M?LKVBOD4%]^\PW<,QM&O/>ZI`3M(^+C+8!843I!*8?2DRD!2-P</69/#RI'"
M>GFYS/8!RDAUR >^Y[UWYO!ZG2\R/3[T?NT>?OLK'5R[:(=/Z7H'ZFZ3A47#
M^TP,;?*AYT(!I &!U"B'",U%2=6RS-;&M'"WTS3 HK?,*](!\&OHJ$20;'#R
M+UXOQ>*B2-/[NC4SR$*U\*%SL]XUF3798FB9/70/';NG-ETNE5XVS8>L:J\,
M-EH/OI;:06C$!6N+(P+E"914_[M[FT1KZDT:XQ:-"[V(AZ(S<72(7^S6@Y !
M7)-OU\82MIAD7+X&_CA*K@C^1.TE?QI$#.#R97: E-#&D3A-1"2\!U0KV\U'
MB;0/)X!EU3 VC\(XC,GZL=)>T6U0`-%VBVQTL\&4T[58..Q$01#C:S8\JN 8
MFZ <QD'((%@-*'<3A4ULA8F8Q&AP4WX3<\_05)](!\=,HO1U$^$#`\GVBVS;
M>&_!N^3WX!EX=H.#,0V;74&.A]G[<@/I7[F!G'ZWY;D]\)8W^:9D66.]2-=I
M!=D?)\3"($?2E]V]. DA^F,_A<9@@;LUIM1"5$=5)/4R;F*MH(Y,3#^._V^J
M4R@38D(JX@7HTS*_R#:_2.>&J";B-C_#C L>[S\U6?TQW6ZS95?T(DN,0BL7
MD]8\@^1B>BI6]^)):Y:!^@H84'F>)_"I;-O!#PY7&8$8P9*4.G_N&:$@)--Y
M#9N6)G_8;79USS *11R@D";T4C6A/(-C*;R?!H$WFWE3*P_E)L[6`TF@U38;
M!LG5-7"2NV;9],0&?L$]I(0#_:@84(L!H4?.$'JV\&?:P)O;=\V@L8<GZP4#
M%P/'L&5MXHF$9.\E=EVFK[*VMUW;^RN<TN&;;+G8W5OL%RYP,5G9ML[7F_+;
MQUVZKDG4#T6'<.<94$>MM=/:,1^@$C;D;%-DL,7/_(<J`Z<&NT:)02$6^;8P
MJ*FR=]H:L1^24YM%PR!YB_?U-QYSFUY:+HF)SF:$0W)"QC? OCXHXPCS&MMG
MC#;1&?^-Z<S!8S1J]UN6BFH:$SD\?-\]GLEP=XT;8WF"(ZB+V28K<@NR7"H'
M#:(56V1M'WYB<61Z3!!9K/,M31,!AYQ25,O@\$'Y^3['[6I8Y*7%$O?KT8!%
MX& 6L.7%KJ#\%NG^'/RF>\%ONC\GO^G^!'[;[=370NZ2R>GN31J0!7\_DCE4
M,"&1V/1^>AV:0_6OGL%'JYZ*\E:FX/N#27A+H&N92[Y(LNL!^CE51 @3&>RO
MUB3-"_=1^$P,[-EM11?W69/.HO%SBW?]/&(PU\^C_3$3+/#NHQ9BUD/ULH^&
MF,XI"X^ZX\3'OX8O3CJ<;X_#11XL9YNH$;9WE3-DL,?&D!N0/4DJ('"K=KI#
M>4\N/IYI>WQG$N&M-@74/':A;O>8FWS"/\]!>+6\"FBF9>0&7,C!21<Y\16Y
M2"C4+4+SZS93`I#!RL=(/\9W@7RVTBD#$P+P7Z8QBD0*F? D=\9]0;&K&^\^
M\Q &+PV<5P;'&J(T0S[FQK1";#N3$=[\+QLAMG^D[0DYQ3W9-O'/1VFBRJV?
MVT9Q,H*6%T?6))33#'GR?=#L.ZU>:3TT&R*[(;X+HXZ5X#;VF^4`:_<`"MJ0
MU^7G,OUDZ5-UM.V]P\P3V\[!#%H&?F&26IV+U.H@J?MSD:I;I+BM4^>Q](F-
M2N^Q[' ?+<((?KPV;U:4[.F$VKHTR=R?AXQ+CRH5^%O&S)\A>0TY`/YB^A,4
MEQMQPO 4(26Q"2S2ILKWK@N )YFY:,=4;JHB7<MC(( P<\TGD3SK5.P)4[$E
M>BO<LV$*8QX"R_,/I/AFB>L>3RM_R:K-G_(G\$&PY]8'EN@+7BW2DAU2*LZ\
MU&/7T![2\IZX'EZ=LL2ET(CI)]A*5^H$;Y "]6,+6QN-/LTWZ=%]++NT-R=Q
M4<UPIL$%!=@P652;NE9@V @M,^BB$R /S>3A1%HMP)G&/@=&WIG-``IJSX*:
M+PS,# /#`GV_L^@,]'R[B?M-*F#X% >6(?F^-%T(,Z.G6$48;^RIGICT1)"#
M^<Z>J3%F:F"C8Z8&-CHF,K %@>O@K,<R^Z./FGOQ,-2_"/ !#M.BM#H7I;[H
M(\;<GXM6VVW:M"#\2(,^BZ,^I$>(.V>E=UB;$(+.2M$5BI#>'S=K;B@B7>GR
M#&V'( ;8I/KIB,B:W!]+Y_X0G0NM0DY*Y0K'BG1SG$@J63A6I)N#(JE<X2\;
MB)T,`60*_%DE6LL<4VH:[L*MB#9+>J^X)?>*[E"X#)?"$@W4)LY6^+,Y`$ 7
MEN\B)YYTN9S J!W;J3B.W273=.NH,.;ERHFS2/>'D2ECX?J$`,G_AOT9]*%]
M\.#H*+!OJ\VOL,A-*5S7[9+U][?)W1OU(^%[W?ZTZQ7F73S'6HIN#_[;,G$E
M`]#VRC:W&ZF27O_3K1&W(SJ30I@>>I5"80$T^BR*0M-9^OAWJ(=&Z"-B$ Y8
MG8=,7^C!(??G(>2(X@8=%L/Q82@A`7ZLYECP/@^A@[IC4?L\I'JWCM]SO^VX
MU<..UK7>U,D+7QS.ZO@77^YQ+&U=\34I;IKE);->IW8/R[)1H",W@(?N#V$8
M\P&DGWA:K(G6G#KR_^,9(Y3?+:$U;SK.'G/:BPRP74C_7<11O&A.?MQ\1$.H
M-A_IC"MW"TK+JL9UF,A8,"\&`TT1G2Y#>GLG3\(OM?M]R[&:OE>1E#1EE0,6
M#R38UXN]#[UCI'F(*D\W89.H.<6QX@CSG2A\0%W?+">H0%7Y<."H\L0I@@1S
M5XA[Y<5F??Y9NF5H/]LLM;$/G24Q\C]YELB:_A:;]6IB<R4*NB^_L,WO[CV7
M3=2%GTA9$(?<':GNP\(ZW",&L5>FH%]S<'2K8B.Q5P$D1>N$L(AL(R*;C-&>
M3PQ]DZ6-`:L!# S=9W(%.=3L*I[L'KTG@T\/)R>4S!+NR'#)!_:>LZZRLTB5
M\#BHM(-R?DP!*X%MF<!Q5/6C40H[I'#VLZD7;.L'\RB]B,+"TG-!;8$M3("!
MQL#4!^G5EC+_Z6]_PH3@)$O57/Y<I66]W=39'S;BT!HYU7YHUD@0WUHW10RP
MP<O6"F7ANVS5N%FP"!..HB 4&CL+"S_F#Q^&\0#=A(WXA6K0J 1MRU+L(C5B
M"S-S[,OX*&VC'<Z'99,VPC_^Q4+I#<&I^<$V;^:)=RSN:W\),E1%7J:E^9I$
MZ(VCR?1-,IEJ1#SNO6BQ<#6O@!^4@U],6+=C8CT_Q2A'S\5;8"WRIVC@$'X)
MUV8<VCK8SLNGK&H&3*?83S!POK!()'06B$E(HOD7F9X]F\BE<*X=4ZU'/[1S
MW[TI[!YY,&I%,&O$=E<=^'ZR*Z&5[X<5+U;*TBK^%EC;-> /UA:J@\%6H!);
MD'.SB5B=;+KR4V,^3#28H%($/ZD2S/8P[2<\NG710T)>]4@R8=.S$!O4CR,^
MYD4&",ONQTV3LDV&X,5D@Q\ARH>7T1,4JTWS=Y08KWZ1U@*<W(*]9LV;.'7V
M*G5>TA:M_VDX92]]1I-6>\3:IY-IJR-V=T2(R=7!42U:S1S1N+;:XRX\,>)I
MP\<*_<FS![K\Q[ET:0NJ5<GCFD.9MDB'5!DY.CIF16C3H>6.^7V1.EF/UN@O
MGUFC+:$.V69;SWV6V:G,3M/LU*:8L)/-D[6SDC_U;0;4;"I>?BJ9;.R&S,H`
MTE2P`2XGI#\P&V##HC<E>VPB;Y:FK$X!?\;\9R1_)OQG+'ZJ202,[7FDC9MB
M@=)[8\<DXMQZUU[#ZJ!'`-PQ/PPD'L%_;1!IK@PD&<%_`J0IMB 2QQR3MIBU
M):.VX7!"?-"8_8G=!L0!KA4`(9+81&('D=B!HVU>%A>22.P@$K6(1(2(4Y*8
MB"JYL*SLK[M4!.]'>-(F9ED7ZT0(8=NE]XTW%=8\BR&'YM9"TK^96"!/V2*:
ML9$8"T53S#YO$8UX.]ZJP>^$-$YEXPUIQ,+<YV?$QXISH(N6Y6IKF_G1F'T5
MXP8&73\_!VUO$]TQS GTCQE#+C2Q`(GOKCF(_5D>;BH2R[4;"[-KR4P"8KF8
MB02E&QB.S$QM-+&B)$%:S,1"I!O%KP,+$"*\" 7IC$[E3V$AK:&>P5)_V*W3
M:L[/%>?+;+$I8!?)WP"VDWH8AK]:1V?LK%4=L/9Y1X:B^^P$V'V/GT6Q[JP2
M7SP$M\J5#KUA%ZQ8]T^_UT/\)$R"CHOEOGKS8CKMJ#@OIA&FB,P226LL6XDE
M%1%BX?9&6B/92C%$L6RE&&*!(38PQ)%LI1CB6+;&QU:V^U+J4 HI'^(@]*4P
MH>1?/NC.6';&LC..@\]>%"]-*&CM75$N`4?LO+,6GCE4H[S>\+3R2J,7A?XJ
MDPN/S@M,9-+SZJL4'"9?2IZDN[W4F"B95%HQ+CSL&X\O:UU=#SSH&P_[E7_W
M[8=6IKB%Y6OI\H 34");*9*QY&_TDK\DE]0GO&KB=@#1;XD'N EO6A[ )1V#
M4SV\S3,^;V5^>>H8YQ$ZW <)9Z0O-ONH(Y@F9E_2=C,DN)&^R.QSN!P2S4A?
M8O91>K%!S^F:2&PC?;'99SBZQ.RC]!*#7F+02R*SC])+8K./TDL2LP_I79[)
M:<J'I-=[R@=<5GVN5#YH?(F$2B14(J&2Q%6C?*E\L'4&DO%S0UM(2/M"=AQ2
M1,9OHB3 Q$_5UZE**/0WV$Q$"4]P\#<]$3IO-."P^IN,_3'A7-% >%UZH6UY
M\M:I$[VQ-C4%BN)G4.)N6RI,.7KO'?N$&+T@%V4LW9(X(F1-2DX"H]G!IQ0S
M-[XSD1PKH&4L0L"V"D !K#9O,NT5JA5I%9&^2.M&AE6:2QN1I:%N*?AKH<%7
M"$6UQ#YO(K\!U*<H_C+IV9,!\3&@P^G [9>U^45-C;#W8T!ZTJP(>MEW].E6
MKXSC>HP^G^C/-EQ;#LV X[SP( /_>#D#A /'^=I!#GXY"P>8<8GEO_1-1]!.
MLAQO]X@1@XHK+7JK<])SO9IGTKM1\MT<36]8\:A%;W5.>MVO'F(<,M^KQ+:!
MWVDY5RVVMEJ#(+8VT0RQ^33?$'VQLX]9-)?CA$/6KK3[O^X=\0%%J?^Q"1+9
MOUD9TO=V@F1]0^\S;9^/W/R6:8$?M'+M?87^%YORUYW^.-VC=;?^:)<U//:4
M-63B=G$LGTY:!9(S5>/W&(6/5HW"(ZTY:B+*F5R2V.8L0Q(#N$FVAQ !V6\Z
M#&9D)&!AT7C7GFQ/=/N4MD>ZG;_6*=MCW1[=A0:)Z#")B+;'!FE-8DI)FR3B
MPR1BVCXU2(]=TDTM$HE!PLG5M -5U*$H]%X7+W*M8%/O2,$',RW/L*U2GH?,
MF7'[DEC)/C\VG8A+!7)?]>^W18<F#0TGAS4<=]@/NV8+*8WH,(VNV9IV&%!L
MTX@/TX@[+"CJ6&I3FX9IC4Z^NI9MUUJ3=Y GF:-9UE2[?"]UOBWOZW2_VO_*
MA]$XDJBZV#O@@ZU"NB,X5%?!2 !7$W99^SX,R_H1%]:!M]8Z7UOC<BZU;CS8
M@RY>G:8&,DW6Q[T\?N?H[;W0^\15XJG09!28(S?6N82O[BJQB6*7'^6SO(0]
MU64DU<MP3=S:?61 O%_H-1JB6/&]"E.Q&0,@ZB4LHVY%`H0<>#/Y%0^D'$JC
M`/7X[!+^:_:M2;^1WXFT!D,>LV#7^E)'>3EOQ*5^H_&(9E[LX, CRP`8O?$^
M!&SY"$F%]>[.56N-(_[AN1H\GKB/6U;K5[JB=T 3Q=(Q42;#NKM(*N=9#
M^2!V,D+\Z>0W(U4)@2NK[2;4W3WSCEA288S[2ICVD3[..&F663.7N9#WM_P?
M3VFJ=,&KLJ4O]:'Y&SJQM12^8?\X1"0J8@G+]0@85J#P_*;6$+R8@>''FH,Q
MJQ_@%P'!B$!%"HK71R 4._8WH&(%Q2LQ$(I=< @HO6Z+=,]+%?8^_M_P.Y)0
M$&>?\A 48GWXZ/-!,T]"B_)BH@#9`Y1]B0E4HC!1]1#IM7XL!;5E5_@B(KLM
M/*\0N?:DMDRPY)"^^>Z(RLKU<:OY`T/Y,%'R1HC%ET(JPE.7O-$`>>DLQEI_
MD27(=)A:$@+FM!SZ"@>=R!C!]:1>:VVT!8N58%]9DGWEY+EWCJ)A&D@(F,O<
M7Q!3,25@,#CSLD3:C!SZ,= G1AB$?'*!T7LT)4ZFD,WA+U%S^-5YJ/2=[I$S
M`<>KS:K3=1CFY*GG)KGS;6;]X4+G!XHO5.YBGHRQV=?<#P\,_ZY3+AZ^[),N
MT4=JS0E'+SG[PF#Y__+\ZRP5)Y_QE,N=@?#@"ME.,_-U#L)>N@E&&#T8*'K4
M0F;1)*9).R17[NA7=9\."&JT-F?TZ!31U 26A1/,4\Z.2?Z8_GAL&+&ABA[W
MYO+[:0PH9+E>HQ:XD16^D4.-17[\&N\JY&1Y=QK+<,C<OMZJ<)G,G[2BA3$"
M`^/)=$2D`6RX+YM\U!+QR6.-Q(W@)/'&R)H,WAC?M<0>[MO0IY-_N\ZWSWR'
M1!%">'C TH-6YR;JBE],07.V^-B_LS3SKN;S(H59F/-_K.]I)JZ<?5@>6%)5
MS+Z7]W2\#8+.;\+?AK\+_R?\/?3_"U!+`P04````" "5F#XG'IGT>S\```!$
M````"P```%]?:6YI=%]?+G!Y4\[,+<@O*E$HKBS6R2_F4@;2>@6))1EZF7G%
MJ44E&@8Z"O'Q(('X^&B#6.W\8KWBU )ML*J<Q)*T_*)<32X`4$L#!!0````(
M`+*13"<P7Z(>VP<``% E```.````5F5C;6%T:%1E<W0N<'GE6NMOVS80_^P`
M^1\X%T6DC%+U2M$VRX=B2($`;=,M1;&MZP?59A)U>MB2DMG^ZW='4A(IT8^D
MKPU+XL0\W>/'N^.1/.>R+#)RRR997%^3))L594T.]_?DNWHY8U4[0IYV4"WA
MP?X>FU5)6N3DA/BNQYPCI$W9)6'SFSBMK")GM*BO66D_V]\;)9=<(U+MDQ.N
MW'V1%G']%MXB`W+$'[D8<8@0)#\1:81SC&9Q5>$;EE9,4LHDKTEK"FDEJV_*
M?(,NQ DJP%Y2)7E5Q_F$XZ+/%TGU/+]*632U&TB6!X+PT%T<<CWN@OS(QTLY
M7LKQ2HY70K2!877>:$56"$H165+BV23.IUQPI$BL6J..!F*U5F+1PG(TF(NU
M$C'.F HOB8%MZT[^=T_%&L[%42=#BI+T63!F'0LEP2$FN#M+D-OLH;Z(T\EP
M?YD22J3YF21AIHODD Y%W3(G3Z4UM$";1!5J911V2.O12+QP$3Z_N#C]]:TU
M*?)I4B=%3B=%EK&\/GF-*U"NR+RH2<LAK,1)Q<C%LJI9=EJ6PAG *:7513=^
M)TO'6U;5Y$6<I&SZ`WE8C<E#R<V9H5BX;)'4EM?+*J'EX"RO69G'*;=F&96.
M#X::]O<F*50#(OF1'=6^?@GEB!S\F:,(_/!ZA#(52R^%\X5=ZV"VK*^+?.$V
M%3!.4U*C5:PR;$JJF\F$5=7E39HNW0,.OH> :\_B))?:2:<>YU$793@EKNN.
MN2RPN T5X5JVPE[\);CX<#1^%==EL@#IOQ- ]LM-7$=32I3Z1,F;`C@?M682
M=&,\P4#J)AM5G<D'TDAC\X%F-/I,HP\4J]$&JYR-.]/N0J7YIPO9BI6%> 31
M;7B$VEM?)04TI)&@!SK]B#I/[&/^)!PJ"=U)6525=>M3<AMPFEQ L@P`Q[2H
MX;F-Q6<#0] QW/JZUF.#E$];)$X4T2 "^$;U@9NR_*J^OH!QR0`W)4_#C9S(
MPBM4-2]K"YD;5!7C0(6;W+PHLSA-5LS:ILWOSRN@X!#SM$@7,UOZ71CV*01)
M4@).<7SJ/*9.R)5#=87P`"\OLY8Y&'X+ZE !*.KQI*@LD 6XP"9#HB-H0C$T
M99@*/.,!-<[RLV ,'<$IK@=?_AI?? L4&(X`PB&![.ZJ^R'9%RM?*U/=RC_'
M<MX\$PEZ9B A\+,I;#E)O;0$M@P+@\Z6!0/2+5"@.O@T@O3&>8>PLX<4?"!"
M< DE)X$Z1TH`SZQ0'NZ0_$DC\]J/5A'*:<IP_[,22CY1DAP&AY_@^!#>3:-0
MJ+L8U%_IZFU5OYBES'+#E#-?$MWL)K7.#4LK"R@YMU6N#-;RV1K.S#=5( `P
M9; Q9$D>`TH;/?JXU9FSJ[AF"I1XV@+;A*4G%YKF%;K5S4>0:T:(WW./C!@!
M?>.PT$WR6P9%4I?,3+4G"]$=_,$,,XSOB !!K".>4KT="==3) 7DDO.HUX2J
M+.H_+'F0?/2XH=:0!16D1&;-3)Z9^;0UW*ZN3@D=B;H/!Q.%Z-GV)A2_M[SA
MET 1@D'J#'#@+L15Q>@EY6QA>101Z1A,4)$0^]\"XAPABF.0988SU^&(^CDW
MYC+F6] FLPJ;DGM")QO=VU9W*&>Z5YL#6CC%R;4Q:*:AB+:2=Y)S^<_=)4'H
M_I)<^#YH\;N]RG6YK\35E(7;\ZZ)'<]KVS8*&C9131)D[R4IH-J&N6RKU.L*
M.NPZ%Y,8W-?QR'3ODG_C0;*W`-9(_OQ&O2R0V%<&F38(^&"]C0K1POJ%8XPT
MPBNMTP0Z:FQCI>?,)M!!WS^<\U#Y;?17H/E+X=OJI8%!<T""-0&!.?[6K^/?
M<8I-.)N8Z::^]/3[Q;C9U/7-8E94TO7KLV>_/9/VJP=6%0HFG@F5NQPQXZ"W
MTW'J8'.9!WV"-I]8VUQ$,VCHF1CF$,L5@ IU`T*?Z50S![EY(]??8Q6[4H?Q
MN*;J:+9"XPE*K02F.4KM#]9/32\@Z]5#D5^ 5_'/82 )2T%8MH25(*P$05<M
M%3CX5Y''\5(1Q_%*CD6S4-#X^V-=K:%R-Y"UVU TW+?$)4/)NFB8==%7S+K-
MN=;3^]]*MB^5:_U4ZV?:UTRTW='NJW?N2+US\PP[U[)IA*2S08+U[MS"P1J7
M3/PAK7<%CLQ7X(9\]SOU-H6FT\VV.[4Z"]$OD.T".%[[O%\`YV6XL'KT"1][
MAH6YZ_6;DC&&`(07Y'RLRFRYC(,@MPAP%^2LE;S7E9MW1L@1GZK'[P).A//L
MWLEO=97<KC$9FMQPS]NZYE+W2(N%Q/64^AYB=@+\#>/&1'?//U:,9L9VEG+3
MU\//G>!1T26BLEO$[?!S-S^UH]2Z_H!'-C>Q.]9W71,[:EL)5 L<'FN*"T"6
M7UFV*Z&/WX\A=U^_A%_C]X[O>J,`7AZ\X#C\`9^)A:!_J?SXPA;@"$<HL4&@
MT2_EMNGW)!1/LI,/X[8^[W#':3WZF#I/(;+RN(^W/4W!NX"^,^T(0.]<"@Y]
MPE?PYM[(E^_09/_'!LT].QUD<ZOCN[=IODZ7YI7Q"-B3TALT.X@,>S-;A4QM
MF5V$!AV9'>!]SV;,YL14FS'#8K/-[O=HR-SU.KQ^)>3#>VZN:<\-'ZP(!BBV
M4&/AI6+*??P4"-:UVW9A3&3](USA>7ZXP<E;>;#FHUI4DP<FMU5"M^&)_(1V
MHQ_V]_"_`TZ4?SA 3$AS^?\`V/\`4$L!`A0`% ````@`!I)B)_#K_RZZ%0``
M+G,```H``````````0`@`+:!`````'9E8VUA=&@N<'E02P$"% `4````" "5
MF#XG'IGT>S\```!$````"P`````````!`" `MH'B%0``7U]I;FET7U\N<'E0
M2P$"% `4````" "RD4PG,%^B'ML'``!0)0``#@`````````!`" `MH%*%@``
D5F5C;6%T:%1E<W0N<'E02P4&``````,``P"M````41X`````
`
end
From jbaddor@sca.uqam.ca Thu Nov 4 22:00:43 1999
From: jbaddor@sca.uqam.ca (Jean-Bernard ADDOR)
Date: Thu, 4 Nov 1999 17:00:43 -0500 (EST)
Subject: [Matrix-SIG] FFT derivative
Message-ID: <Pine.A41.4.05.9911041648400.46866-100000@maia.sca.uqam.ca>
Hey Numerical people!
I wrote a python code for derivation in Fourrier space, and it gives very
bad results. The idea is to multiply the transform of the data by -ik.
Do you have any hint? Do you know about any code in any language which do
that, and I could just translate into python? Are any books with detailled
example of the use of the FFT to compute derivatives?
Jean-Bernard
def FFTderivative(a, order=1, axis=-1):
from Numeric import arange
from FFT import fft, inverse_fft
a = Numeric.asarray(a) # works on arbitrary python sequence
l = a.shape[axis]/2
m = a.shape[axis] - 2*l
if axis != -1: a = Numeric.swapaxes(a, axis, -1)
b = fft(concatenate((a, a[...,::-1]), -1)) # JD trick, could be made
nicer
c =
(1j*concatenate((arange(a.shape[-1]),arange(-a.shape[-1],0))))**order
#c = (1j*concatenate((arange(l+m),arange(-l,0))))**order # was before
fourier space doubling
# from the FT theory it should be -1j instead of 1j, why?
d = b*c
r = inverse_fft(d)[...,:a.shape[-1]]
if a.typecode() != 'D' and a.typecode() != 'F': # not complex type
r = r.real
if axis != -1: r = Numeric.swapaxes(r, axis, -1)
return r
From warren@pfiesteria.gsfc.nasa.gov Thu Nov 4 22:37:47 1999
From: warren@pfiesteria.gsfc.nasa.gov (Warren B. Focke)
Date: Thu, 4 Nov 1999 17:37:47 -0500 (EST)
Subject: [Matrix-SIG] FFT derivative
In-Reply-To: <Pine.A41.4.05.9911041648400.46866-100000@maia.sca.uqam.ca>
Message-ID: <Pine.LNX.3.96.991104172035.5276A-100000@pfiesteria.gsfc.nasa.gov>
On Thu, 4 Nov 1999, Jean-Bernard ADDOR wrote:
> Do you have any hint? Do you know about any code in any language which do
> that, and I could just translate into python? Are any books with detailled
> example of the use of the FFT to compute derivatives?
Try this:
--------------------------
import FFT, Numeric, umath
def deriv(series, num=None, axis=-1):
fspace = FFT.fft(series, num, axis)
fspace = fderiv(fspace, num, axis)
return(FFT.inverse_fft(fspace, num, axis))
def fderiv(fspace, num=None, axis=-1):
if num == None:
num = fspace.shape[axis]
n2 = (num - 1) / 2
iomega = ((Numeric.arange(num) + n2) % num) - n2
iomega = iomega.astype('D') * 2.0 * Numeric.pi * 1.0j / num
dims = len(fspace.shape)
if dims > 1:
newshape = [1] * dims
newshape[axis] = num
iomega.shape = newshape
dspace = fspace * iomega
# if the length is even, zero out the value at nyquist
nyq = num / 2
if (nyq*2 == num):
if dims > 1:
sly = [slice(None)] * dims
sly[axis] = nyq
else:
sly = nyq
dspace[sly] = 0.0
return(dspace)
------------------------------
Note that the results will still look "bad" if the sequence you are taking
the derivative of is not continuous at high order across its endpoints.
> # from the FT theory it should be -1j instead of 1j, why?
Probably because some people put the minus sign on the forward transform,
and others on the reverse, and FFTPACK does the opposite of what you
expected.
Warren Focke
From Oliphant.Travis@mayo.edu Fri Nov 5 08:53:01 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Fri, 5 Nov 1999 02:53:01 -0600 (CST)
Subject: [Matrix-SIG] First official release of (general purpose) Sparse matrix packagefor Python
Message-ID: <Pine.LNX.4.10.9911050240440.3573-100000@us2.mayo.edu>
I've finally released Version 0.1 of a general purpose Sparse matrix
package. It is available at
http://oliphant.netpedia.net/packages/SparsePy.tgz
RPMS for Linux may be available soon.
The package requires a FORTRAN compiler, a C compiler, and a copy of the
BLAS for your system.
Currently the makefiles only work for a UNIX system using gcc and g77,
they can be modified to work for any compiler.
Features:
* Initialization of Sparse Matrices using diagonal or coordinate
convention.
* Matrix-vector multiplies
* Matrix-Matrix add, subtract, multiply, conjugate, transpose
* Direct inversion of Sparse Linear Systems.
The first three features are due Yousef Saad's SPARSEKIT2 package while
the last feature is due to SuperLU by Demmel, Gilbert, and Li.
The implementation is a Python class which has methods that call on
wrapped versions of these libraries.
There are other Sparse Matrix implementations available but this one is
trying to be general purpose. Any suggestions and improvements are
appreciated.
Travis Oliphant
Oliphant.Travis@altavista.net
From parkw@better.net Fri Nov 5 12:05:00 1999
From: parkw@better.net (William Park)
Date: Fri, 5 Nov 1999 07:05:00 -0500
Subject: [Matrix-SIG] FFT derivative
In-Reply-To: <Pine.A41.4.05.9911041648400.46866-100000@maia.sca.uqam.ca>
References: <Pine.A41.4.05.9911041648400.46866-100000@maia.sca.uqam.ca>
Message-ID: <19991105070500.A6998@better.net>
On Thu, Nov 04, 1999 at 05:00:43PM -0500, Jean-Bernard ADDOR wrote:
> Hey Numerical people!
>
> I wrote a python code for derivation in Fourrier space, and it gives very
> bad results. The idea is to multiply the transform of the data by -ik.
>
> Do you have any hint? Do you know about any code in any language which do
> that, and I could just translate into python? Are any books with detailled
> example of the use of the FFT to compute derivatives?
Do you want h'(t) or H'(f)? For your reference,
h'(t) <==> j2\pi f H(f)
-j2\pi t h(t) <==> H('f)
so the discrete version can be found by substituting
f = n/(NT), t = kT
where T is time sampling interval.
>
>
> Jean-Bernard
>
> def FFTderivative(a, order=1, axis=-1):
> from Numeric import arange
> from FFT import fft, inverse_fft
> a = Numeric.asarray(a) # works on arbitrary python sequence
> l = a.shape[axis]/2
> m = a.shape[axis] - 2*l
> if axis != -1: a = Numeric.swapaxes(a, axis, -1)
> b = fft(concatenate((a, a[...,::-1]), -1)) # JD trick, could be made
> nicer
> c =
> (1j*concatenate((arange(a.shape[-1]),arange(-a.shape[-1],0))))**order
> #c = (1j*concatenate((arange(l+m),arange(-l,0))))**order # was before
> fourier space doubling
> # from the FT theory it should be -1j instead of 1j, why?
The usual engineering convention is to use e^{-j2\pi ft} to go from time
domain to frequency domain. But, there are people who still use
e^{j2\pi ft} or, even worse, e^{j\omega t}.
> d = b*c
> r = inverse_fft(d)[...,:a.shape[-1]]
> if a.typecode() != 'D' and a.typecode() != 'F': # not complex type
> r = r.real
> if axis != -1: r = Numeric.swapaxes(r, axis, -1)
> return r
>
>
>
> _______________________________________________
> Matrix-SIG maillist - Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
From robin@jessikat.demon.co.uk Fri Nov 5 14:11:09 1999
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Fri, 5 Nov 1999 14:11:09 +0000
Subject: [Matrix-SIG] First official release of (general purpose) Sparse matrix packagefor Python
In-Reply-To: <Pine.LNX.4.10.9911050240440.3573-100000@us2.mayo.edu>
References: <Pine.LNX.4.10.9911050240440.3573-100000@us2.mayo.edu>
Message-ID: <ULg4$BA9VuI4EwbC@jessikat.demon.co.uk>
In article <Pine.LNX.4.10.9911050240440.3573-100000@us2.mayo.edu>,
Travis Oliphant <Oliphant.Travis@mayo.edu> writes
...
>There are other Sparse Matrix implementations available but this one is
>trying to be general purpose. Any suggestions and improvements are
>appreciated.
>
...
Of particular interest to optimisers and structural engineers are
special solution methods for symmetric matrices. Ng & Peyton's method is
widely used as part of the package PCx. It is originally coded in
fortran, but is easy to move to C. I think it unlikely that the sparse
matrix storage can easily be made fully dynamic as it uses parallel
vectors representing super nodes etc. The strategy I have used in the
past when converting fortran is to try and preserve the original
assertions as elements are added/removed from the sparse matrix. I think
for a Python module implementing various sparse matrix kinds there ought
to be a standard API we can plug into.
--
Robin Becker
From robin@jessikat.demon.co.uk Fri Nov 5 14:48:25 1999
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Fri, 5 Nov 1999 14:48:25 +0000
Subject: [Matrix-SIG] First official release of (general purpose) Sparse matrix packagefor Python
In-Reply-To: <Pine.LNX.4.10.9911050240440.3573-100000@us2.mayo.edu>
References: <Pine.LNX.4.10.9911050240440.3573-100000@us2.mayo.edu>
Message-ID: <5LxzvBA54uI4Ew+A@jessikat.demon.co.uk>
I downloaded SparesPy.tgz, but my winzip falls over with it. Should I
try under Linux?
--
Robin Becker
From kern@its.caltech.edu Sun Nov 7 08:58:38 1999
From: kern@its.caltech.edu (Robert Kern)
Date: Sun, 7 Nov 1999 00:58:38 -0800 (PST)
Subject: [Matrix-SIG] First official release of (general purpose) Sparse
matrix packagefor Python
In-Reply-To: <5LxzvBA54uI4Ew+A@jessikat.demon.co.uk>
Message-ID: <Pine.GSO.4.05.9911070052360.20775-100000@inky>
On Fri, 5 Nov 1999, Robin Becker wrote:
> I downloaded SparesPy.tgz, but my winzip falls over with it. Should I
> try under Linux?
Try downloading under Linux. I've had this problem with downloading any
TGZ from Travis' site from a Windows browser. It may be a
misconfiguration of the server.
To Someone-In-The-Know: Could it be a problem with Travis' .htacces file?
On a related note, I'm away from my Windows development environment for
the nonce. Can someone else use mingw32 (or MSVC if you have it) to
compile up Windows binaries? I'll put them up on the Starship.
> --
> Robin Becker
--
Robert Kern
kern@caltech.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
From robin@jessikat.demon.co.uk Mon Nov 8 17:18:02 1999
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Mon, 8 Nov 1999 17:18:02 +0000
Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #318 - 4 msgs
In-Reply-To: <Pine.LNX.4.10.9911081105020.10064-100000@us2.mayo.edu>
References: <199911060602.BAA18489@python.org>
<Pine.LNX.4.10.9911081105020.10064-100000@us2.mayo.edu>
Message-ID: <WlMY0CAKXwJ4Ewwn@jessikat.demon.co.uk>
In article <Pine.LNX.4.10.9911081105020.10064-100000@us2.mayo.edu>,
Travis Oliphant <Oliphant.Travis@mayo.edu> writes
>> ...
>
...
>
>I actually rather like using Fortran as a low-level language as it is much
>easier to wrap (despite SWIG) --- arguments are always pointers to basic
>data types in FORTRAN.
>
Is modern Fortran dynamic? I have heard so, but few of the old timers
like me seem to believe.
>> I downloaded SparesPy.tgz, but my winzip falls over with it. Should I
>> try under Linux?
>
>I'm not sure what this problem is. I've heard this before off and on. I
>think there may be a problem with WinZip understanding *.tgz files. I've
>heard that simply renaming the file may help. But I don't know.
>
>If somebody knows what's up I'd appreciate hearing about it.
>
>Travis
>
>
I tried to decode the .tgz with my rh 6.1 tar tzvf, but that also fails.
I will have to try and download under Linux. Win32/Unix downloads don't
seem to work sometimes.
--
Robin Becker
From Oliphant.Travis@mayo.edu Mon Nov 8 17:09:23 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Mon, 8 Nov 1999 11:09:23 -0600 (CST)
Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #318 - 4 msgs
In-Reply-To: <199911060602.BAA18489@python.org>
Message-ID: <Pine.LNX.4.10.9911081105020.10064-100000@us2.mayo.edu>
> ...
> Of particular interest to optimisers and structural engineers are
> special solution methods for symmetric matrices. Ng & Peyton's method is
> widely used as part of the package PCx. It is originally coded in
> fortran, but is easy to move to C. I think it unlikely that the sparse
> matrix storage can easily be made fully dynamic as it uses parallel
> vectors representing super nodes etc. The strategy I have used in the
> past when converting fortran is to try and preserve the original
> assertions as elements are added/removed from the sparse matrix. I think
> for a Python module implementing various sparse matrix kinds there ought
> to be a standard API we can plug into.
I actually rather like using Fortran as a low-level language as it is much
easier to wrap (despite SWIG) --- arguments are always pointers to basic
data types in FORTRAN.
> I downloaded SparesPy.tgz, but my winzip falls over with it. Should I
> try under Linux?
I'm not sure what this problem is. I've heard this before off and on. I
think there may be a problem with WinZip understanding *.tgz files. I've
heard that simply renaming the file may help. But I don't know.
If somebody knows what's up I'd appreciate hearing about it.
Travis
From olafb@pvv.org Tue Nov 9 14:48:31 1999
From: olafb@pvv.org (Olaf Trygve Berglihn)
Date: 09 Nov 1999 15:48:31 +0100
Subject: [Matrix-SIG] Wrapper for FSQP, anyone?
Message-ID: <dn13dufyb40.fsf@similan.chembio.ntnu.no>
I've obtained a licence for non-comercial, academic use of the SQP
optimizing routine FFSQP from Zhou, Tits and Lawrence, Univ. of
Maryland (http://www.isr.umd.edu/Labs/CACSE/FSQP/fsqp.html). I plan to
use this with python, with help from Pyforth. Has anyone made the
necessary modifications to the main sub-routine and written the .pyf
file?
Olaf
--
* Olaf Trygve Berglihn <olafb@pvv.org>
From olafb@pvv.org Tue Nov 9 15:02:16 1999
From: olafb@pvv.org (Olaf Trygve Berglihn)
Date: 09 Nov 1999 16:02:16 +0100
Subject: [Matrix-SIG] Wrapper for FSQP, anyone?
In-Reply-To: Olaf Trygve Berglihn's message of "09 Nov 1999 15:48:31 +0100"
References: <dn13dufyb40.fsf@similan.chembio.ntnu.no>
Message-ID: <dn1vh7bwvwn.fsf@similan.chembio.ntnu.no>
BTW: I'd also like to know if you successfully have used NAG E04UCF or
equivalent SQP routine with pyforth.
Olaf
* Olaf Trygve Berglihn
| I've obtained a licence for non-comercial, academic use of the SQP
| optimizing routine FFSQP from Zhou, Tits and Lawrence, Univ. of
| Maryland (http://www.isr.umd.edu/Labs/CACSE/FSQP/fsqp.html). I plan to
| use this with python, with help from Pyforth. Has anyone made the
| necessary modifications to the main sub-routine and written the .pyf
| file?
--
* Olaf Trygve Berglihn <olafb@pvv.org>
From olafb@pvv.org Tue Nov 9 17:17:23 1999
From: olafb@pvv.org (Olaf Trygve Berglihn)
Date: 09 Nov 1999 18:17:23 +0100
Subject: [Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #318 - 4 msgs
In-Reply-To: Robin Becker's message of "Mon, 8 Nov 1999 17:18:02 +0000"
References: <199911060602.BAA18489@python.org> <Pine.LNX.4.10.9911081105020.10064-100000@us2.mayo.edu> <WlMY0CAKXwJ4Ewwn@jessikat.demon.co.uk>
Message-ID: <dn1k8nrwpng.fsf@similan.chembio.ntnu.no>
* Robin Becker
| I tried to decode the .tgz with my rh 6.1 tar tzvf, but that also fails.
| I will have to try and download under Linux. Win32/Unix downloads don't
| seem to work sometimes.
| --
| Robin Becker
I also think there is a problem with the web-server configuration at
oliphant.netpedia.net. tgz-files are downloaded as text. The following
line in a .htaccess file on the server side (if Apache is used) will
do it: AddType application/x-gzip .tgz
--
* Olaf Trygve Berglihn <olafb@pvv.org>
From olafb@pvv.org Tue Nov 9 18:11:39 1999
From: olafb@pvv.org (Olaf Trygve Berglihn)
Date: 09 Nov 1999 19:11:39 +0100
Subject: [Matrix-SIG] Wrapper for FSQP, anyone?
In-Reply-To: Olaf Trygve Berglihn's message of "09 Nov 1999 15:48:31 +0100"
References: <dn13dufyb40.fsf@similan.chembio.ntnu.no>
Message-ID: <dn1hfivwn50.fsf@similan.chembio.ntnu.no>
Hmm... I guess it is not this simple (never worked with Pyfort
before). The fortran code needs a function on which to iterate, and I
want this to be a python function.
* Olaf Trygve Berglihn
| I've obtained a licence for non-comercial, academic use of the SQP
| optimizing routine FFSQP from Zhou, Tits and Lawrence, Univ. of
| Maryland (http://www.isr.umd.edu/Labs/CACSE/FSQP/fsqp.html). I plan to
| use this with python, with help from Pyforth. Has anyone made the
| necessary modifications to the main sub-routine and written the .pyf
| file?
--
* Olaf Trygve Berglihn <olafb@pvv.org>
From Raphael.Guerois@EMBL-Heidelberg.de Tue Nov 9 18:13:11 1999
From: Raphael.Guerois@EMBL-Heidelberg.de (Raphael Guerois)
Date: Tue, 9 Nov 1999 19:13:11 +0100 (MET)
Subject: [Matrix-SIG] MMTK and Surface Calculation
Message-ID: <Pine.SGI.3.96.991109190549.4252B-100000@starling.EMBL-Heidelberg.DE>
Hi
Does anyone tried the method surfaceAndVolume() in mmtk module? I don't
manage to to run it from this small script... Do you any idea ?... Thanks!
Raphael
from mmtk import *
import PDB,Units
seq=PDB.PDBFile('/data/pdb/1shg.brk').readSequence(1)
seq.deleteHydrogens()
prot = PeptideChain(seq[0],hydrogens=0)
surface,volume = prot.surfaceAndVolume(probe_radius=1.4 *
Units.Ang)
resulted in :
>>> ## working on region in file /usr/tmp/python-3...
Process Python segmentation violation (core dumped)
From kern@its.caltech.edu Tue Nov 9 19:49:01 1999
From: kern@its.caltech.edu (Robert Kern)
Date: Tue, 9 Nov 1999 11:49:01 -0800 (PST)
Subject: [Matrix-SIG] Wrapper for FSQP, anyone?
In-Reply-To: <dn1hfivwn50.fsf@similan.chembio.ntnu.no>
Message-ID: <Pine.GSO.4.05.9911091147330.21648-100000@inky>
On 9 Nov 1999, Olaf Trygve Berglihn wrote:
> Hmm... I guess it is not this simple (never worked with Pyfort
> before). The fortran code needs a function on which to iterate, and I
> want this to be a python function.
Travis Oliphant did this in his Multipack interface. Look at his code:
http://oliphant.netpedia.net/multipack
[snip]
> --
> * Olaf Trygve Berglihn <olafb@pvv.org>
--
Robert Kern
kern@caltech.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
From Oliphant.Travis@mayo.edu Tue Nov 9 22:34:00 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Tue, 9 Nov 1999 16:34:00 -0600 (CST)
Subject: [Matrix-SIG] New file names at http://oliphant.netpedia.net
Message-ID: <Pine.LNX.4.10.9911091632260.12900-100000@us2.mayo.edu>
I've changed the filenames for the files on http://oliphant.netpedia.net
to see if that helps the downloading problems for Windows users.
All *.tgz files have been renamed to *.tar.gz
I hope this helps the problem. If you get the chance, let me know if it
does or doesn't help.
Thanks,
Travis
From hinsen@dirac.cnrs-orleans.fr Fri Nov 12 16:35:44 1999
From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr)
Date: Fri, 12 Nov 1999 17:35:44 +0100
Subject: [Matrix-SIG] MMTK and Surface Calculation
In-Reply-To: <Pine.SGI.3.96.991109190549.4252B-100000@starling.EMBL-Heidelberg.DE>
(message from Raphael Guerois on Tue, 9 Nov 1999 19:13:11 +0100 (MET))
References: <Pine.SGI.3.96.991109190549.4252B-100000@starling.EMBL-Heidelberg.DE>
Message-ID: <199911121635.RAA08889@chinon.cnrs-orleans.fr>
> Does anyone tried the method surfaceAndVolume() in mmtk module? I don't
> manage to to run it from this small script... Do you any idea ?... Thanks!
It works in the most recent MMTK version (2.0), but it didn't work
in some earlier versions when used with newer releases of NumPy.
I recommend upgrading to the most recent versions, but if you want to
go on with what you have, replace the function init_surface in the
file _surface.c by this one:
init_surface()
{
PyObject *m;
/* Create the module and add the functions */
m = Py_InitModule("_surface", surface_methods);
/* Import the array module */
#ifdef import_array
import_array();
#endif
/* Check for errors */
if (PyErr_Occurred())
Py_FatalError("can't initialize module _surface");
}
I suppose that in your copy the line "import_array();" is missing, and
that causes an immediate crash with sufficiently new NumPy versions.
BTW, a better place for such questions is the MMTK mailing list!
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
From jbaddor@sca.uqam.ca Sat Nov 13 02:29:15 1999
From: jbaddor@sca.uqam.ca (Jean-Bernard ADDOR)
Date: Fri, 12 Nov 1999 21:29:15 -0500 (EST)
Subject: [Matrix-SIG] -1%2 = 1 and array([-1])%2 = array([-1]) Why?
Message-ID: <Pine.A41.4.05.9911122121520.37340-100000@maia.sca.uqam.ca>
Hey Numerical people!
I just tried the following:
>>> -1%2
1
>>> array([-1])%2
array([-1])
I would have expected array([+1]).
What is the philosophical reason Numerical should give another result than
nude python?
Jean-Bernard
Python 1.5.1 (#1, Dec 17 1998, 20:58:15) [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Debian python-numer 1.7-7.1
From hinsen@cnrs-orleans.fr Mon Nov 15 15:11:45 1999
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Mon, 15 Nov 1999 16:11:45 +0100
Subject: [Matrix-SIG] -1%2 = 1 and array([-1])%2 = array([-1]) Why?
In-Reply-To: <Pine.A41.4.05.9911122121520.37340-100000@maia.sca.uqam.ca>
(message from Jean-Bernard ADDOR on Fri, 12 Nov 1999 21:29:15 -0500
(EST))
References: <Pine.A41.4.05.9911122121520.37340-100000@maia.sca.uqam.ca>
Message-ID: <199911151511.QAA11403@chinon.cnrs-orleans.fr>
> I just tried the following:
>
> >>> -1%2
> 1
> >>> array([-1])%2
> array([-1])
>
> I would have expected array([+1]).
>
> What is the philosophical reason Numerical should give another result than
> nude python?
Python has a well-defined rule for the modulo operator. NumPy just
applies the C modulo operator, which if I remember correctly gives
different results on different machines, guaranteeing only that
b*(a/b) + (a%b) == a. I have pointed out the different outcome a while
ago, but noone else seemed to see this as a problem.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------