From hinsen@ibs.ibs.fr Tue Mar 3 09:41:20 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 3 Mar 1998 10:41:20 +0100
Subject: [MATRIX-SIG] Inconsistent mod behaviour
Message-ID: <199803030941.KAA18306@lmspc1.ibs.fr>
A colleague made me aware of an inconsistency in the modulo operation
for arrays and scalars:
>>> from Numeric import *
>>> -15%2
1
>>> array([-15])%2
array([-1])
Some further investigation shows that this is the result of different
truncation rules for integer division, i.e. division and modulo are
consistent in both cases:
>>> -15/2
-8
>>> array(-15)/2
-7
Nevertheless, it is an annoying problem. However, it was not really
introduced by NumPy. NumPy uses fmod() and therefore inherits its
documented behaviour. The same is true for math.fmod and Numeric.fmod.
I am not sure what to do about this. It seems reasonable to let arrays
behave like scalars for consistency, but of course leave the explicit
function fmod() as it is. Does anyone see a problem with that solution?
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 Paul F. Dubois" <dubois1@llnl.gov Thu Mar 5 00:19:58 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Wed, 4 Mar 1998 16:19:58 -0800
Subject: [MATRIX-SIG] Numerical Python Release 1.0
Message-ID: <002d01bd47cc$6eb81460$998a7380@pduboispc>
On ftp-icf.llnl.gov/pub/python there are two files:
NumPy10.exe -- Windows 95/NT installer (MSVC 5.0)
NumPy10.tgz -- Sources (NumPy/...)
The Windows installer gives you a choice of binary or full install. The full
install is needed only if you intend to make your own C extensions.
Please see the file release_notes.txt for details.
Guido-like, I hereby vanish until Tuesday. I rather expect problems, so I am
announcing this only to the sig. This will give me a chance to get some
feedback, make any necessary emergency repairs next week, and let CNRI get
these two files mirrored in an appropriate place on python.org.
I apologize apriori for the lack of full make/install support. That should
be available next.
Paul
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From KaliazinA@cardiff.ac.uk Thu Mar 5 18:58:52 1998
From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin)
Date: Thu, 5 Mar 1998 18:58:52 -0000
Subject: [MATRIX-SIG] Numerical Python Release 1.0
Message-ID: <000c01bd4868$c980c4e0$8f16fb83@nedo.engin.cf.ac.uk>
>On ftp-icf.llnl.gov/pub/python there are two files:
>
>NumPy10.exe -- Windows 95/NT installer (MSVC 5.0)
>NumPy10.tgz -- Sources (NumPy/...)
>
>The Windows installer gives you a choice of binary or full install.
The full
>install is needed only if you intend to make your own C extensions.
>
>Please see the file release_notes.txt for details.
>
Just installed NumPy 1.0 release (binaries only) on my Win'95,
and have problems:
1. Installation procedure do not update paths in registry;
2. Two files are missed - "FFt.py" and "RandomArray.py";
3. Mlab.by still have wrong import (Numeric.Random) and
reference (old?) - to Numeric.Random.random_sample()
(when I replace them for RandomArray.random() it is Ok)
4. Why tests for LA, FFT, RANLIB are not included into
test_all.py?
5. (optional) why diff() is not included into standard set of
numeric functions?
and maybe other common knowns as integ(), interp()
and so on, from Yorick for example are also good candidates?
Andy K.
_______________
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 Thu Mar 5 23:13:27 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 5 Mar 1998 15:13:27 -0800
Subject: [MATRIX-SIG] Numerical Python Release 1.0
Message-ID: <004e01bd488c$4ea501e0$998a7380@pduboispc>
Thanks for the reports.
Note that the release notes and one of the screens in the Windows installer
specifically mention that this version does not do the installation into the
path. You can just take the Lib/ and pyds/ contents and move them into your
path. The reason is that I have to take the time to learn how to do that and
I want to be sure I have it right before screwing up everyone's registry. Or
worse, *my* registry.
-----Original Message-----
From: Andrey Kaliazin <KaliazinA@cardiff.ac.uk>
To: Paul F. Dubois <dubois1@llnl.gov>; matrix-sig <matrix-sig@python.org>
Date: Thursday, March 05, 1998 11:00 AM
Subject: Re: [MATRIX-SIG] Numerical Python Release 1.0
>>On ftp-icf.llnl.gov/pub/python there are two files:
>>
>>NumPy10.exe -- Windows 95/NT installer (MSVC 5.0)
>>NumPy10.tgz -- Sources (NumPy/...)
>>
>>The Windows installer gives you a choice of binary or full install.
>The full
>>install is needed only if you intend to make your own C extensions.
>>
>>Please see the file release_notes.txt for details.
>>
>
>Just installed NumPy 1.0 release (binaries only) on my Win'95,
>and have problems:
>
>1. Installation procedure do not update paths in registry;
>2. Two files are missed - "FFt.py" and "RandomArray.py";
>3. Mlab.by still have wrong import (Numeric.Random) and
> reference (old?) - to Numeric.Random.random_sample()
> (when I replace them for RandomArray.random() it is Ok)
>4. Why tests for LA, FFT, RANLIB are not included into
> test_all.py?
>
>5. (optional) why diff() is not included into standard set of
>numeric functions?
>and maybe other common knowns as integ(), interp()
>and so on, from Yorick for example are also good candidates?
>
>
>Andy K.
>
>
>
>
>
_______________
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 Thu Mar 5 23:53:16 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 5 Mar 1998 15:53:16 -0800
Subject: [MATRIX-SIG] Fix to NumPy10
Message-ID: <000801bd4891$ded1ef80$998a7380@pduboispc>
I added the two missing files and made the change requested to Mlab.py. Both
Windows and tar files replaced (dated 3/5 instead of 3/4).
I forgot to answer one of Mr. Kaliazin's questions: I will be working to get
the rest of the LLNL stuff out as a separate package. Meantime, things like
yorick.py are currently available in the file Current_distribution.tgz on
ftp-icf.llnl.gov.
-----Original Message-----
From: Andrey Kaliazin <KaliazinA@cardiff.ac.uk>
To: Paul F. Dubois <dubois1@llnl.gov>; matrix-sig <matrix-sig@python.org>
Date: Thursday, March 05, 1998 11:11 AM
Subject: Re: [MATRIX-SIG] Numerical Python Release 1.0
>>On ftp-icf.llnl.gov/pub/python there are two files:
>>
>>NumPy10.exe -- Windows 95/NT installer (MSVC 5.0)
>>NumPy10.tgz -- Sources (NumPy/...)
>>
>>The Windows installer gives you a choice of binary or full install.
>The full
>>install is needed only if you intend to make your own C extensions.
>>
>>Please see the file release_notes.txt for details.
>>
>
>Just installed NumPy 1.0 release (binaries only) on my Win'95,
>and have problems:
>
>1. Installation procedure do not update paths in registry;
>2. Two files are missed - "FFt.py" and "RandomArray.py";
>3. Mlab.by still have wrong import (Numeric.Random) and
> reference (old?) - to Numeric.Random.random_sample()
> (when I replace them for RandomArray.random() it is Ok)
>4. Why tests for LA, FFT, RANLIB are not included into
> test_all.py?
>
>5. (optional) why diff() is not included into standard set of
>numeric functions?
>and maybe other common knowns as integ(), interp()
>and so on, from Yorick for example are also good candidates?
>
>
>Andy K.
>
>
>
>
>
>_______________
>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 KaliazinA@cardiff.ac.uk Fri Mar 6 17:59:59 1998
From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin)
Date: Fri, 6 Mar 1998 17:59:59 -0000
Subject: [MATRIX-SIG] Fix to NumPy10
Message-ID: <005701bd4929$c5d99620$8f16fb83@nedo.engin.cf.ac.uk>
>I forgot to answer one of Mr. Kaliazin's questions: I will be
working to get
>the rest of the LLNL stuff out as a separate package. Meantime,
things like
>yorick.py are currently available in the file
Current_distribution.tgz on
>ftp-icf.llnl.gov.
>
Thanks.
Is there any files or pages having information (plans) on future
development
of NumPy? I'd like to to read what features are to be included in or
excluded. That "TODO.TXT" file in distribution seems to be rather
short :-),
though Fortran direct support (at last) is a great idea!
Look - another bug? (I use Win'95, Python 1.5, Numpy10)
Maybe it is a supposed behaviour, but ...
>>> r = arange(13)
>>> r
array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12])
>>> ar=pow(10,r)
### ar=10**r produce the same
>>> ar
array([1, 10, 100,1000, 10000,100000,
1000000, 10000000, 100000000, 1000000000,
1410065408, 1215752192, -727379968])
How do you like it? I do not.
never can be 10**10 =1410065408
of course, 10.0**r gives "right" result.
Andy K.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From krodgers@tdyryan.com Fri Mar 6 20:32:56 1998
From: krodgers@tdyryan.com (Kevin Rodgers)
Date: Fri, 06 Mar 1998 12:32:56 -0800
Subject: [MATRIX-SIG] Fix to NumPy10
In-Reply-To: <005701bd4929$c5d99620$8f16fb83@nedo.engin.cf.ac.uk>
Message-ID: <3.0.1.32.19980306123256.00657da0@gate.tdyryan.com>
At 05:59 PM 3/6/98 -0000, Andrey Kaliazin wrote:
>Look - another bug? (I use Win'95, Python 1.5, Numpy10)
>Maybe it is a supposed behaviour, but ...
>>>> r = arange(13)
>>>> r
>array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12])
>>>> ar=pow(10,r)
>### ar=10**r produce the same
>>>> ar
>array([1, 10, 100,1000, 10000,100000,
> 1000000, 10000000, 100000000, 1000000000,
> 1410065408, 1215752192, -727379968])
>
>How do you like it? I do not.
>never can be 10**10 =1410065408
>
>of course, 10.0**r gives "right" result.
If you omit the "type" argument to array, it will pick the smallest type
that all of the array elements will fit in, so in your case it picked
32-bit signed integer. 10**10 overflows a 32-bit signed integer . . .
----------------------------------------------------------------------
Kevin Rodgers Teledyne Ryan Aeronautical krodgers@tdyryan.com
"This one goes up to eleven." -- Nigel Tufnel
----------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From busby@icf.llnl.gov Fri Mar 6 21:09:01 1998
From: busby@icf.llnl.gov (L. Busby)
Date: Fri, 6 Mar 98 13:09:01 PST
Subject: [MATRIX-SIG] Fix to NumPy10
Message-ID: <9803062109.AA20612@icf.llnl.gov.llnl.gov>
>Is there any files or pages having information (plans) on future
>development of NumPy? I'd like to to read what features are to be
>included in or excluded. That "TODO.TXT" file in distribution seems to
>be rather short :-), though Fortran direct support (at last) is a great
>idea!
TODO.TXT is all there is for now. If it seems short to you, what
else do you think should be there? I'm sure many of us would like to
read what features are to be included or excluded, but that's really
what this mailing list is for.
>Look - another bug? (I use Win'95, Python 1.5, Numpy10)
>Maybe it is a supposed behaviour, but ...
>>>> r = arange(13)
>>>> r
>array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12])
>>>> ar=pow(10,r)
>### ar=10**r produce the same
>>>> ar
>array([1, 10, 100,1000, 10000,100000,
> 1000000, 10000000, 100000000, 1000000000,
> 1410065408, 1215752192, -727379968])
>
>How do you like it? I do not.
>never can be 10**10 =1410065408
>
>of course, 10.0**r gives "right" result.
>
>Andy K.
When item 4 of TODO is finished, you'll be able to turn on a signal
handler for SIGFPE and catch the overflow you observed above. (Odd
though it may seem, integer divide by zero and overflow will generate
SIGFPE in most implementations.) For the moment, it's neither a bug
nor a feature. Until Python itself was capable of handling SIGFPE,
it was impossible to do much of anything about it in NumPy (unless
you were willing to give up most of NumPy's speed advantage by
checking all operands).
Note that many of the functions in the Standard math library do check
the domain and/or range of their arguments and/or results. (And they
will set errno to EDOM or ERANGE if an error occurs.) That's the
difference between fast_umath and umath modules. The first doesn't
check the value of errno after each call to a library math function,
the second does. This will trap some errors, but not integer
exponentiation, as you discovered.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From KaliazinA@cardiff.ac.uk Fri Mar 6 22:22:37 1998
From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin)
Date: Fri, 6 Mar 1998 22:22:37 -0000
Subject: [MATRIX-SIG] Fix to NumPy10
Message-ID: <001e01bd494e$620f79a0$8f16fb83@nedo.engin.cf.ac.uk>
> When item 4 of TODO is finished, you'll be able to turn on
> a signal handler for SIGFPE and catch the overflow you
> observed above. (Odd though it may seem, integer divide
> by zero and overflow will generate SIGFPE in most
> implementations.) For the moment, it's neither a bug
> nor a feature. Until Python itself was capable of handling
> SIGFPE, it was impossible to do much of anything about it
> in NumPy (unless you were willing to give up most of NumPy's
> speed advantage by checking all operands).
>
Sorry, if I was not clear enough.
(my english still have to be improved :-(
I just wanted to point out that pow() does not trap this error,
being applied to array, while it do it's best with single value:
>>> from Numeric import *
>>> pow(10,array([10]))
array([1410065408])
and
>>> pow(10,10)
Traceback (innermost last):
File "<stdin>", line 1, in ?
OverflowError: integer pow()
So, isn't it a bug?
Looking in TODO list (item 2), I would like to suggest to implement
"Inf" value (infinitive) additionally to a "NaN" .
(MATLAB shows elegant way and semantic to handle both)
Andy K.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Dirk.Engelmann@iwr.uni-heidelberg.de Sun Mar 8 11:09:23 1998
From: Dirk.Engelmann@iwr.uni-heidelberg.de (Dirk Engelmann)
Date: Sun, 8 Mar 1998 12:09:23 +0100 (CET)
Subject: [MATRIX-SIG] spline with NumPy ?
Message-ID: <Pine.LNX.3.95.980308115812.21279A-100000@klimt.iwr.uni-heidelberg.de>
Hi!
I'm interested in using spline interpolation.
Actually I want to fit spline (with gaussian function) by
a least square method to data points.
If someone has done somthing with NumPy and spline, please let me
know.
Thanks!
Cheers,
Dirk Engelmann
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Mon Mar 9 13:14:19 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Mon, 09 Mar 1998 14:14:19 +0100 (MET)
Subject: [MATRIX-SIG] RNG module for WinNT?
Message-ID: <Pine.PMDF.3.91.980309141236.650348910A-100000@Pap.UniVie.AC.AT>
Is there a precompiled version of Konrad's
RNG module for WinNT?
Thank you.
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From johann@leporello.berkeley.edu Tue Mar 10 02:48:54 1998
From: johann@leporello.berkeley.edu (Johann Hibschman)
Date: Mon, 9 Mar 1998 18:48:54 -0800
Subject: [MATRIX-SIG] spline with NumPy ?
In-Reply-To: <Pine.LNX.3.95.980308115812.21279A-100000@klimt.iwr.uni-heidelberg.de>
(message from Dirk Engelmann on Sun, 8 Mar 1998 12:09:23 +0100 (CET))
Message-ID: <199803100248.SAA19051@leporello.Berkeley.EDU>
> If someone has done somthing with NumPy and spline, please let me
> know.
>
> Thanks!
Hi,
I have done a little work like that (very little). I don't know much
about the constraints on the error of the approximation. I have made
a Python version of the NR in C spline routines, with all the
limitations and copyright issues of the original. It works well
enough for small projects.
Look at:
http://astro.berkeley.edu/~johann/python/numpy.html
Hope that helps,
- Johann
--
Johann Hibschman | Grad Student, UC Berkeley Astronomy
johann@physics.berkeley.edu | http://astro.berkeley.edu/~johann
_______________
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 Mar 10 15:05:08 1998
From: pas@xis.xerox.com (Perry Stoll)
Date: Tue, 10 Mar 1998 07:05:08 PST
Subject: [MATRIX-SIG] RNG module for WinNT?
Message-ID: <003201bd4c35$ea7e5f10$4a4df60d@stoll-pc.xis.xerox.com>
I have one. I don't have any place to post it on the web currently - would
anyone be interested/willing to host it? Dave? Paul?
In the mean time, I can send you the dll if you like. Drop me a line.
-Perry
-----Original Message-----
Is there a precompiled version of Konrad's
RNG module for WinNT?
Thank you.
Regards,
Rupert Mazzucco
_______________
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 lorenzo@argon.roma2.infn.it Wed Mar 11 19:01:31 1998
From: lorenzo@argon.roma2.infn.it (Lorenzo M. Catucci)
Date: Wed, 11 Mar 1998 20:01:31 +0100 (CET)
Subject: [MATRIX-SIG] NumPy external library wrapping help
Message-ID: <Pine.LNX.3.96.980311195158.11475A-100000@argon.roma2.infn.it>
First, I'm to beg your pardon if this comes out to be a double post; I
tried yesterday via findmail, but haven't seen anything till now...
Now, the questions: I'd like to wrap a couple of PORT least sqares
routines for use within Python's numeric framework, and therefore I'll
need to do a couple of things:
1. make fortran arrays - seems simple: make C ones, and then access them
`backwards' (read, via transposed indexes). The only problem will be
the malloc/free one.
2. Put in callback support - this is what I fear: on one hand, I'll need
to be able to call the python interpreter, then I'll have to validate
the called functions for output format and the like, and further make
sure the environment the callbacks will be executed in is the right one
(what happens if the user calls for `sin(x)'?)
Can please someone come out with a couple of guidelines? I can then
promise n e a r t o e t h e r n a l gratitude...
Yours,
lorenzo
_______________
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 Wed Mar 11 23:29:23 1998
From: johann@physics.berkeley.edu (Johann Hibschman)
Date: Wed, 11 Mar 1998 15:29:23 -0800
Subject: [MATRIX-SIG] NumPy external library wrapping help
In-Reply-To: <Pine.LNX.3.96.980311195158.11475A-100000@argon.roma2.infn.it>
(lorenzo@argon.roma2.infn.it)
Message-ID: <199803112329.PAA21352@leporello.Berkeley.EDU>
"Lorenzo M. Catucci" <lorenzo@argon.roma2.infn.it> wrote:
>
> Now, the questions: I'd like to wrap a couple of PORT least sqares
> routines for use within Python's numeric framework, and therefore I'll
> need to do a couple of things:
> 1. make fortran arrays - seems simple: make C ones, and then access them
> `backwards' (read, via transposed indexes). The only problem will be
> the malloc/free one.
Have you tried looking at modules like lapack_litemodule.c in the
distribution? They should give some examples.
> 2. Put in callback support - this is what I fear: on one hand, I'll need
> to be able to call the python interpreter, then I'll have to validate
> the called functions for output format and the like, and further make
> sure the environment the callbacks will be executed in is the right one
> (what happens if the user calls for `sin(x)'?)
This is tougher.
I haven't actually done this, but I have a few ideas. The most
obvious thing you could do is make a "trampoline" function like:
/* I forget all the actual python function calls---you'll have to
check the documentation. I tend to use Mark Lutz's Programming Python
book as a ref. */
/* global pointer to put the python object into: make this a python
LIST, so you can store multiple functions (use the list as a stack) */
PyObject *foo_function_list;
static double foo_trampoline(double x)
{
[convert x into a PyObject => py_x];
[get foo_function_list[0] => py_function] /* first item on stack */
[call py_function on py_x => py_answer];
[convert py_answer into a double => answer];
return answer;
}
static PyObject *wrap_foo(...)
{
[extract the python function object py_function to be passed to C];
/* set the global pointer */
[append py_function to foo_function_list (push onto stack)]
/* pass the C (or fortran) routine the trampoline function */
answer = foo(foo_trampoline, ...);
[pop py_function off foo_function_list]
[convert answer to c => py_answer]
return py_answer;
}
I hope that helps with the idea at least; I can't provide more details
at this point.
Calling the python function is likely to be slow slow slow, which is
why I've never actually done this. If you get it running, I'd like to
hear about how the performance is.
I'd like to hear what anyone else thinks about this.
- Johann
--
Johann Hibschman | Grad Student, UC Berkeley Astronomy
johann@physics.berkeley.edu | http://astro.berkeley.edu/~johann
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From dheister@jaguar1.usouthal.edu Thu Mar 12 02:20:56 1998
From: dheister@jaguar1.usouthal.edu (Douglas R. Heisterkamp)
Date: Wed, 11 Mar 1998 20:20:56 -0600 (CST)
Subject: [MATRIX-SIG] NumPy external library wrapping help
In-Reply-To: <199803112329.PAA21352@leporello.Berkeley.EDU>
Message-ID: <Pine.SOL.3.91.980311200641.28133A-100000@jaguar1.usouthal.edu>
On Wed, 11 Mar 1998, Johann Hibschman wrote:
<snip>
> I hope that helps with the idea at least; I can't provide more details
> at this point.
>
> Calling the python function is likely to be slow slow slow, which is
> why I've never actually done this. If you get it running, I'd like to
> hear about how the performance is.
>
> I'd like to hear what anyone else thinks about this.
If you would like to see an old try at it, look at
ftp://ftp.cse.unl.edu/pub/drh/python/drhfn.tar.gz
I never released the code, because I could see many better ways
of doing it. But I never had enough of a need to actually spend
the time try the other approaches. An example is include of using
either a python or a Fortran function as a callback in ODRPACK.
This worked with 1.4. I have not tried it with 1.5.
Doug Heisterkamp
drh@cis.usouthal.edu
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Thu Mar 12 19:17:12 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 12 Mar 1998 11:17:12 -0800
Subject: [MATRIX-SIG] NumPy-11
Message-ID: <000e01bd4deb$76bb94a0$998a7380@pduboispc>
Numerical Python release 1.1 is now on ftp-icf.llnl.gov/pub/python.
NumPy-11.exe is a Windows 95/NT installer. It gives you a choice of
runtime-only or complete installation. It adjusts the registry entries so
that Python will be able to able to find the new modules.
NumPy-11.tgz is a tarred and gzipped archive. It also contains the sources
for the Arrayfcns package which is something we might move into the
Numerical package at some point if people like it.
A new technology, the joint work of Konrad Hinsen and David Ascher, allows
even dummies to make from source on Unix or Windows/Microsoft Visual C++.
Naturally, there will be somebody's system out there for which it doesn't
work. Let us know. This version was tested on Winodws with MSVC 5.0 + Visual
Dev Studio Service Pack 3.
CNRI, you can set up pointers to this stuff on www.python.org and then
announce it.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From David.Buscher@durham.ac.uk Thu Mar 12 20:19:37 1998
From: David.Buscher@durham.ac.uk (David Buscher)
Date: Thu, 12 Mar 1998 20:19:37 +0000 (GMT)
Subject: [MATRIX-SIG] real_fft
Message-ID: <Pine.SOL.3.91-941213.980312195835.3956D-100000@duss0.dur.ac.uk>
There appears to be an off-by-one error in the real_fft() function in the
FFT module. The following is the output from a python session, with spacing
inserted for clarity:
Python 1.5 (#1, Mar 10 1998, 16:43:31) [GCC 2.7.2] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> from FFT import *
>>> fft([1,0,0,0])
array([ 1.+0.j, 1.+0.j, 1.+0.j, 1.+0.j])
>>> real_fft([1,0,0,0])
array([ 0.+0.j, 0.+0.j, 0.+0.j])
>>> real_fft([1,1,0,0])
array([ 1.+0.j, 1.+0.j, 1.+0.j])
>>> real_fft([0,1,0,0])
array([ 1.+0.j, 1.+0.j, 1.+0.j])
The first expression is just to check that the fft() function works as
expected. Note that the last two expressions show that the real_fft()
function is ignoring the first element of the array. Does anyone else see
this happening, or is it just a function of my installation? Or do I not
understand what the real_fft() function is supposed to do? I am using
python-1.5 with Konrad Hinsen's numpy.tar.gz.
David
----------------------------------------+-------------------------------------
David Buscher | Phone +44 191 374 7462
Dept of Physics, University of Durham, | Fax +44 191 374 3709
South Road, Durham DH1 3LE, UK | Email david.buscher@durham.ac.uk
----------------------------------------+-------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From singer@itl.atr.co.jp Thu Mar 12 07:19:57 1998
From: singer@itl.atr.co.jp (Harald Singer)
Date: Thu, 12 Mar 1998 16:19:57 +0900
Subject: [MATRIX-SIG] [Q] default NumPy installation
Message-ID: <3504E99D.AE9E90ED@itl.atr.co.jp>
Hi,
I just downloaded NumPy-11.tgz
[1] documentation is out of date
the compile instructions in Numerical don't fit the distribution.
[2] release naming incosistency
NumPy10.tgz
NumPy-11.tgz
[3]
What is the "preferred way" of installing NumPy in a multi-machine
environment? (Linux, OSF1, HP-UX, etc)
Just following the "new procedure", I did
python makethis.py
make install
bash$ ls /usr/local/lib/python1.5/site-packages
fast_umathmodule.so lapack_lite.so ranlib.so
_numpymodule.so fftpack.so multiarraymodule.so umathmodule.so
Where should I install the files in NumPy/Lib? I could
cp -r Lib /usr/local/lib/python1.5/NumPy
and then
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python1.5/NumPy
but somehow I don't like this too much, because it might clash
with what individual users do with their PYTHONPATH variable.
Another solution is to change Setup.in (or Setup???) from
# Site specific path components -- should begin with : if non-empty
SITEPATH=
to
# Site specific path components -- should begin with : if non-empty
SITEPATH=:Imaging:NumPy
--
Harald Singer, ATR ITL, tel +81-7749-5-1389 singer@itl.atr.co.jp
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From bsd@scripps.edu Fri Mar 13 09:23:37 1998
From: bsd@scripps.edu (Bruce Duncan)
Date: Fri, 13 Mar 1998 01:23:37 -0800 (PST)
Subject: [MATRIX-SIG] UserArray.py problems
Message-ID: <199803130923.BAA12203@riscfs2.scripps.edu>
Greetings,
UserArray.py seems to have some problems:
1) The constructor tries to set a "name" attribute which fails if the
input data is an array.
2) The __setitem__ method doesn't work if the item is NOT an array;
in this case the asarray call seems to fail.
I've also seen some other strange failures.
UserArray would be a good class to have working correctly.
I find that the standard python classes UserDict and UserList help quite a bit.
Does anyone use this class? How well does it work??
-bsd-
_______________
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 Mar 13 16:41:16 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 13 Mar 1998 17:41:16 +0100
Subject: [MATRIX-SIG] [Q] default NumPy installation
In-Reply-To: <3504E99D.AE9E90ED@itl.atr.co.jp> (message from Harald Singer on
Thu, 12 Mar 1998 16:19:57 +0900)
Message-ID: <199803131641.RAA16162@lmspc1.ibs.fr>
> [3]
> What is the "preferred way" of installing NumPy in a multi-machine
> environment? (Linux, OSF1, HP-UX, etc)
>
> Just following the "new procedure", I did
> python makethis.py
> make install
>
> bash$ ls /usr/local/lib/python1.5/site-packages
> fast_umathmodule.so lapack_lite.so ranlib.so
> _numpymodule.so fftpack.so multiarraymodule.so umathmodule.so
>
> Where should I install the files in NumPy/Lib? I could
> cp -r Lib /usr/local/lib/python1.5/NumPy
> and then
> export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python1.5/NumPy
> but somehow I don't like this too much, because it might clash
> with what individual users do with their PYTHONPATH variable.
I always add the NumPy to the standard library path. That does
create a problem when you try to figure out what modules comes
from where, but it ensures access from everywhere, assuming the
original Python installation was working.
--
-------------------------------------------------------------------------------
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 Fri Mar 13 16:46:24 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 13 Mar 1998 08:46:24 -0800
Subject: [MATRIX-SIG] [Q] default NumPy installation
Message-ID: <003101bd4e9f$92172980$998a7380@pduboispc>
I'll answer these to the sig because they may be of more general interest.
-----Original Message-----
From: Harald Singer <singer@itl.atr.co.jp>
To: matrix-sig@python.org <matrix-sig@python.org>
Cc: riwa@itl.atr.co.jp <riwa@itl.atr.co.jp>
Date: Thursday, March 12, 1998 7:22 PM
Subject: [MATRIX-SIG] [Q] default NumPy installation
>Hi,
>
>I just downloaded NumPy-11.tgz
>
>[1] documentation is out of date
>the compile instructions in Numerical don't fit the distribution.
The compile instructions are in the top-level README.htm. I didn't realize
there were compile instructions in the Doc subdirectory; I'll remove them.
>
>
>[2] release naming incosistency
> NumPy10.tgz
> NumPy-11.tgz
I changed my mind.
>
>[3]
>What is the "preferred way" of installing NumPy in a multi-machine
>environment? (Linux, OSF1, HP-UX, etc)
>
>Just following the "new procedure", I did
> python makethis.py
> make install
The documentation points out that at this point there is no support for the
installation; it is up to you to copy the .so's to where you want them, and
likewise the Lib/*. On Windows no "install" is required.
Obviously this isn't a good thing, but please be patient as I have an actual
job. Obviously Konrad and David must have done something close to correct
for Unix but I haven't had a chance to look at this part at all. Apparently
make install does part of the job, so that's good. Konrad had an
"install.py" to parallel "compile.py". What we want to do is make this work
on all the different packages that are going to be in the distribution.
There are quite a few already and it is going to get worse.
One question we've been kicking around is what form the installation should
take...Use the new package stuff? If we do that some existing import
statements will need fixing, but we might all be happier in the long run.
>
>bash$ ls /usr/local/lib/python1.5/site-packages
>fast_umathmodule.so lapack_lite.so ranlib.so
>_numpymodule.so fftpack.so multiarraymodule.so umathmodule.so
>
>Where should I install the files in NumPy/Lib? I could
> cp -r Lib /usr/local/lib/python1.5/NumPy
>and then
> export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python1.5/NumPy
>but somehow I don't like this too much, because it might clash
>with what individual users do with their PYTHONPATH variable.
>
>Another solution is to change Setup.in (or Setup???) from
> # Site specific path components -- should begin with : if non-empty
> SITEPATH=
>to
> # Site specific path components -- should begin with : if non-empty
> SITEPATH=:Imaging:NumPy
>--
>Harald Singer, ATR ITL, tel +81-7749-5-1389 singer@itl.atr.co.jp
>
>
>
>
>_______________
>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 Paul F. Dubois" <dubois1@llnl.gov Fri Mar 13 16:47:53 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 13 Mar 1998 08:47:53 -0800
Subject: [MATRIX-SIG] NumPy-11
Message-ID: <003601bd4e9f$c4abc540$998a7380@pduboispc>
I'll fix this when I get a chance. I'm unfamiliar with the file but it looks
like something simple.
-----Original Message-----
From: Perry Stoll <pas@xis.xerox.com>
To: Paul F. Dubois <dubois1@llnl.gov>
Date: Thursday, March 12, 1998 12:54 PM
Subject: Re: [MATRIX-SIG] NumPy-11
>>Numerical Python release 1.1 is now on ftp-icf.llnl.gov/pub/python.
>
>Glad to hear that.
>
>What is the status of MLab? Should it just be removed, since no one could
>possibly be using it?
>
>
>-Perry
>
>>>> import MLab
>>>> MLab.rand(1)
>Traceback (innermost last):
> File "<interactive input>", line 0, in ?
> File "D:\Python\Python-1.5\NumPy\Lib\MLab.py", line 22, in rand
> return RandomArray.random_sample(args)
>AttributeError: random_sample
>>>>
>
>
>
>
_______________
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 Fri Mar 13 19:27:53 1998
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Fri, 13 Mar 1998 20:27:53 +0100 (CET)
Subject: [MATRIX-SIG] UserArray.py problems
In-Reply-To: <199803130923.BAA12203@riscfs2.scripps.edu>
References: <199803130923.BAA12203@riscfs2.scripps.edu>
Message-ID: <m0yDa7V-000szwC@lisboa.ifm.uni-kiel.de>
There is a better (more consistent) version at the starship site of
Timothy Hochberg and also another class which use UserArray.
But be warned, that the class in its current intention is not really
generally appliciable, because functions need to now that they are
dealing with a userarray, if they should return a userarray. For me
it is questionable, if a function should return a userarray. If
something should look to the outside as an array, why should the
result be something else. Timothy tries to solve this with
shadowclasses. But one ends with a mixture of functions which return
an userarray and some which not. In the mentioned UserList and
UserDict, there are only very special methods, which return a
UserDict, and most handling with dicts and lists is done with
methods. This is not the case in NumPy.
So, I think the list should decide, if a ``replicating'' UserArray is
needed, than the UserArray class together with the shadow classes of
Timothy should be incorporated in the distribution, or a simpler
one which returns an array normaly (not in the case of slicing or
typeconversion).
__Janko
_______________
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 Mar 13 19:29:53 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 13 Mar 1998 11:29:53 -0800
Subject: [MATRIX-SIG] NumPy, RNG distributions available
Message-ID: <000301bd4eb6$665801e0$998a7380@pduboispc>
Distributions available on ftp-icf.llnl.gov/pub/python:
NumPy-11.tgz (Source for NumPy, tar.gz format)
NumPy-11.EXE (Windows runtime/source installer)
RNG-11.tgz (Source for RNG package, tar.gz format; requires NumPy)
RNG-11.EXE (Windows runtime source installer)
RNG is Perry Stoll's ANSI-fication and Windowsization of Konrad Hinsen's
extension of my URNG package. The URNG package is deprecated; users should
switch to RNG.
RNG/Demo/RNGDemo.py is now doing double-duty as a mild test routine for the
uniform and normal distributions. If someone would expand it to test the
exponential distribution that would be great.
Generators can be created so as to use an allegedly random seed. While this
uses microsecond clocks on Unix and is pretty trustworthy, such fine
accuracy is not available in the ANSI standard routines so for windows I
kludged together something using both clock() and time(). I have not
measured the independence of the streams if you create them rapidly one
after the other on Windows. I would recommend wasting some time between such
creations.
The generator in RNG is the same algorithm used by Cray's ranf() routine. My
suggestion to the community is that we dump the ranlib package currently in
NumPy and all use RNG.
_______________
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 Sat Mar 14 13:35:20 1998
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Sat, 14 Mar 1998 14:35:20 +0100 (CET)
Subject: [MATRIX-SIG] Simple UserArray and isarray()
Message-ID: <m0yDr5s-000szwC@lisboa.ifm.uni-kiel.de>
So here is a UserArray class which noirmaly returns an array, only the
slicing and inplace changing methods return an UserArray. I need to
change asarray from Numeric.py to deal with this class or subclasses
of this. The other functions should treat this as an array. There is
also an isarray() function which can handle UserArrays. This is only
to show the other possibility. And then there is a small typo in
Timothy's UserArray at line 205:
The line:
return arg_class(self.ufunc(a), a, b)
should be:
return arg_class(self.ufunc(a), a)
and another one at line 13:
self.__dict__['name'] = string.split(str(self.__class__))[1]
should be:
self.__dict__['name'] = string.split(str(self.__class__),'.')[-1]
with regards,
__Janko
### Simple UserArray
#!/usr/local/bin/python
from Numeric import *
import string
import copy
class UserArray:
def __init__(self, data, typecode=None, copy=0):
if typecode == None:
self.array = array(data,copy=copy)
else:
self.array = array(data, typecode, copy)
self.__dict__['shape'] = self.array.shape
self.name = string.split(str(self.__class__),'.')[-1]
def __setattr__(self,att,value):
# perhaps the name attribute should also be shielded
if att == 'shape':
self.__dict__['shape']=value
self.array.shape=value
else:
# This is normal class behavior
self.__dict__[att]=value
# As this is questionable, one can choose this
# raise AttributeError, "Attribute cannot be set"
def __repr__(self):
return self.name+"\n"+str(self.array)
def __array__(self, typec = 0, copy = 1):
if typec:
stype = typec
else:
stype = self.typecode()
if copy:
return self.array # this returns only the array
else:
return self._rc(self.array, stype) # this returns only the array
#return self._rc(self.array, typecode=stype)
# If array is used as a sequence
def __len__(self): return len(self.array)
def __getitem__(self, index):
return self._rc(self.array[index])
def __getslice__(self, i, j):
return self._rc(self.array[i:j])
def __float__(self):
return self._rc(self.array.astype(Float))
def __int__(self):
return self._rc(self.array.astype(Int))
def __setitem__(self, index, value):
self.array[index] = masarray(value, self.typecode())[...]
def __setslice__(self, i, j, value):
self.array[i:j] = masarray(value, self.typecode())[...]
def __del__(self):
for att in dir(self):
delattr(self, att)
del(self)
# These are changing the values, so make arrays
def __abs__(self): return absolute(self.array)
def __neg__(self): return -self.array
def __add__(self, other):
return self.array+masarray(other)
__radd__ = __add__
def __sub__(self, other):
return self.array-masarray(other)
def __rsub__(self, other):
return masarray(other)-self.array
def __mul__(self, other):
return multiply(self.array, masarray(other))
__rmul__ = __mul__
def __div__(self, other):
return divide(self.array,masarray(other))
def __rdiv__(self, other):
return divide(masarray(other),self.array)
def __pow__(self,other):
return power(self.array,masarray(other))
def __rpow__(self,other):
return power(masarray(other),self.array)
def __sqrt__(self):
return sqrt(self.array)
def tostring(self): return self.array.tostring()
def byteswapped(self): return self._rc(self.array.byteswapped())
def asType(self, typecode): return self._rc(self.array.asType(typecode))
def typecode(self): return self.array.typecode()
def itemsize(self): return self.array.itemsize()
def isContiguous(self): return self.array.isContiguous()
UserArray._rc=UserArray
def masarray(a, typecode=None):
"""
If a is an array of the right type return a, else build a new
array.
"""
if typecode == None:
if isarray(a):
return a
else:
return array(a)
else:
if isarray(a):
if a.typecode() == typecode:
return a
else:
return a.astype(typecode) # this is actually a copy
else:
return array(a, typecode) # this also
def isarray(a):
"""
Test for arrayobjects. Can also handle UserArray instances
"""
try:
sh = list(a.shape)
except AttributeError:
return 0
try:
sh[0] = sh[0]+1
a.shape = sh
except ValueError:
return 1
except IndexError:
return 1 # ? this is a scalar array
return 0
def st(line,comment=''):
import __main__
print '>>> '+line+' #'+comment
exec line in __main__.__dict__,__main__.__dict__
def test():
st('a=UserArray(arange(9))')
st('a.shape=(3,3)')
st('b=a','This should be without copy')
st('b[0,:]=array([1,2,2])')
st('print b;print a','Two refs to the same object')
st('d=array(a)','This should produce a new array')
st('dd=masarray(a)','No copy but a new UserArray')
st('print type(d); print type(dd)')
st('d=sin(a);print d;print type(d)')
st('print less(a,2)')
st('d=where(less(a,3),10,0); print d; print type(d)')
st('a[0,0]=1; print a')
st('a[0,1]=array(10); print a')
st('print repeat(a[NewAxis,:,:],(3,))')
st('print concatenate((a,a))')
#############################################################
# Test of class UserArray
#############################################################
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 Mar 16 23:00:20 1998
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Tue, 17 Mar 1998 00:00:20 +0100 (CET)
Subject: [MATRIX-SIG] two possible bugs?
Message-ID: <m0yEirk-000szwC@lisboa.ifm.uni-kiel.de>
Hello, during some tests of UserArray I have found these oddities:
>>> a=reshape(arange(9),(3,3))
>>> repeat(a,(2,))
zsh: 13051 segmentation fault python -i /home/hauser/SYNC/.python/Startup.py
~@sines >py
>>> a=reshape(arange(9),(3,3))
>>> repeat(a[NewAxis,:,:],(2,))
array([[[0, 1, 2],
[3, 4, 5],
[6, 7, 8]],
[[0, 1, 2],
[3, 4, 5],
[6, 7, 8]]])
>>> (repeat(a[NewAxis,:,:],(2,))).shape
(2, 3, 3)
This is with a Python and NumPy from the LLNL source tree on
Linux(libc6). Is this also the case on other platforms?
And then something I don't understand:
>>> a=array(10)
>>> a.shape
()
>>> a[0]
10
>>> b=array([10])
>>> b.shape
(1,)
>>> b[0]
10
>>> a[-1]
Traceback (innermost last):
File "<stdin>", line 1, in ?
IndexError: index out of bounds
>>> b[-1]
10
Shouldn't a and b not be the same?
__Janko
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From klm@python.org Tue Mar 17 02:26:50 1998
From: klm@python.org (Ken Manheimer)
Date: Mon, 16 Mar 1998 21:26:50 -0500 (EST)
Subject: [Matrix-SIG] Testing transition to mailman list processor
Message-ID: <199803170226.VAA11900@glyph.CNRI.Reston.Va.US>
The Matrix-SIG mailing list has just been migrated to mailman, a
python-based maillist management system.
Subscribers should have received a "welcome" message with information
about accessing your membership account. In summary, the crucial
piece of information is to visit:
http://www.python.org/mailman/listinfo/objc-sig
for the introductory page - you should be able to find your account
from there. In any case, postings to the maillist itself should work
pretty much as they did before.
If you have questions, feel free to contact me...
Thanks!
Ken Manheimer klm@python.org 703 620-8990 x268
(orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #
From klm@python.org Tue Mar 17 02:46:59 1998
From: klm@python.org (Ken Manheimer)
Date: Mon, 16 Mar 1998 21:46:59 -0500 (EST)
Subject: [Matrix-SIG] Re: Testing transition to mailman list processor
Message-ID: <199803170246.VAA12051@glyph.CNRI.Reston.Va.US>
Whoops - sending out multiple copies of the test message, i failed to
modify everything that i was supposed to from one copy to the next -
in particular:
> about accessing your membership account. In summary, the crucial
> piece of information is to visit:
>
> http://www.python.org/mailman/listinfo/objc-sig
the URL should be:
http://www.python.org/mailman/listinfo/matrix-sig
(as you might expect!-)
Ken
From hinsen@ibs.ibs.fr Tue Mar 17 18:03:47 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 17 Mar 1998 19:03:47 +0100
Subject: [MATRIX-SIG] two possible bugs?
In-Reply-To: <m0yEirk-000szwC@lisboa.ifm.uni-kiel.de> (message from Janko
Hauser on Tue, 17 Mar 1998 00:00:20 +0100 (CET))
Message-ID: <199803171803.TAA06952@lmspc1.ibs.fr>
> And then something I don't understand:
>
> >>> a=array(10)
> >>> a.shape
> ()
> >>> a[0]
> 10
> >>> b=array([10])
> >>> b.shape
> (1,)
> >>> b[0]
> 10
> >>> a[-1]
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> IndexError: index out of bounds
> >>> b[-1]
> 10
>
> Shouldn't a and b not be the same?
No. Your first example (array(10)) is a bit special. It represents an
array of rank zero, which is equivalent to a scalar. In fact, any
computation would return a scalar and never an array of rank zero; the
possibility to create a rank 0 object exists only because some code
might insist on receiving an array object under all circumstances.
There was some discussion about this a long time ago on the Matrix SIG.
Note also that a[0] should *in principle* raise an exception, because
the number of indices exceeds the rank. However, that would leave no
way at all to extract a "real" scalar from a rank 0 array object,
therefore the rules are "bent" a bit.
Moral: don't create rank 0 arrays unless you know very well what you
are doing.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
From pas@xis.xerox.com Tue Mar 17 20:31:51 1998
From: pas@xis.xerox.com (Perry Stoll)
Date: Tue, 17 Mar 1998 12:31:51 PST
Subject: [Matrix-SIG] bug in Numeric.diagonal?
Message-ID: <001e01bd51e3$b7aa9dc0$4a4df60d@stoll-pc.xis.xerox.com>
Looking through Numeric, I noticed what looks like a bug in diagonal. Can
anyone confirm this as a bug? (I'd be happier if someone who understands
higher dimensional diagonals tested this).
def diagonal(a, offset=0, axis1=-2, axis2=-1):
if axis1 != -2: a = swapaxes(a, axis1, -2)
if axis2 != -1: a = swapaxes(a, axis2, -1)
s = __diagonal(a, offset)
if axis1 != -2: s = swapaxes(s, axis1, -2)
if axis2 != -1: s = swapaxes(a, axis2, -1) <<-- replace a with s?
return s
-Perry
From hinsen@ibs.ibs.fr Wed Mar 18 16:18:42 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 18 Mar 1998 17:18:42 +0100
Subject: [Matrix-SIG] bug in Numeric.diagonal?
In-Reply-To: <001e01bd51e3$b7aa9dc0$4a4df60d@stoll-pc.xis.xerox.com>
(pas@xis.xerox.com)
Message-ID: <199803181618.RAA12119@lmspc1.ibs.fr>
> Looking through Numeric, I noticed what looks like a bug in diagonal. Can
> anyone confirm this as a bug? (I'd be happier if someone who understands
> higher dimensional diagonals tested this).
>
> def diagonal(a, offset=0, axis1=-2, axis2=-1):
> if axis1 != -2: a = swapaxes(a, axis1, -2)
> if axis2 != -1: a = swapaxes(a, axis2, -1)
> s = __diagonal(a, offset)
> if axis1 != -2: s = swapaxes(s, axis1, -2)
> if axis2 != -1: s = swapaxes(a, axis2, -1) <<-- replace a with s?
> return s
You are right, that should be s. How could this ever work?
Well, it works well for 2D arrays, which is the most important case...
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
From da@skivs.ski.org Wed Mar 18 18:17:55 1998
From: da@skivs.ski.org (David Ascher)
Date: Wed, 18 Mar 1998 10:17:55 -0800 (PST)
Subject: [Matrix-SIG] bug in Numeric.diagonal?
In-Reply-To: <199803181618.RAA12119@lmspc1.ibs.fr>
Message-ID: <Pine.SUN.3.96.980318101719.4362H-100000@skivs.ski.org>
> You are right, that should be s. How could this ever work?
> Well, it works well for 2D arrays, which is the most important case...
But only for small offsets. diagonal(abs(offset)>1) never worked, as far
as I remember. Anyone have a patch?
--david
From pcj+NOSPAM@primenet.com Thu Mar 19 05:43:20 1998
From: pcj+NOSPAM@primenet.com (pcj+NOSPAM@primenet.com)
Date: 18 Mar 1998 21:43:20 -0800
Subject: [Matrix-SIG] Re: [PYTHON MATRIX-SIG] FFT
In-Reply-To: Jim Hugunin's message of "Fri, 7 Mar 1997 11:04:01 -0500"
References: <01BC2AE7.43D84470@misha.lcs.mit.edu>
Message-ID: <oqbtv3jkw7.fsf@merlin.pcj.primenet.com>
A really, really long time ago, Jim Hugunin wrote:
> real_fft returns the left half of the fft of a real array (the fft of a
> real array is conjugate symmetric, so only half of it is needed).
Except it doesn't. fftpackmodule.c needs this patch:
*** fftpackmodule.c~ Fri Mar 21 13:10:00 1997
--- fftpackmodule.c Tue Mar 17 22:25:00 1998
***************
*** 132,138 ****
dptr = (double *)data->data;
for (i=0; i<nrepeats; i++) {
! memcpy((char *)rptr, dptr, npts*sizeof(double));
rfftf(npts, rptr+1, wsave);
rptr[0] = rptr[1];
rptr[1] = 0.0;
--- 132,138 ----
dptr = (double *)data->data;
for (i=0; i<nrepeats; i++) {
! memcpy((char *)(rptr+1), dptr, npts*sizeof(double));
rfftf(npts, rptr+1, wsave);
rptr[0] = rptr[1];
rptr[1] = 0.0;
As David Buscher correctly pointed out, real_fft currently ignores the
first point of the sequence.
> inverse_real_fft is not the inverse function of real_fft, but it instead
> returns the left half of the inverse fft of a real valued vector. This
> naming convention is from fftpack, and I don't think it's bad enough to
> fix.
This is not my understanding of fftpack's "real backwards" routine.
(Admittedly the documentation is a little misleading.) rfftb takes an
array of the left half of the real and imaginary components of the
fourier transform of a real sequence (in the same format as the output
of rfftf), and returns the real sequence. May I suggest instead the
following semantics for inverse_real_fft:
- accepts a complex sequence, assumed to be the left half of a
conjugate symmetric sequence
- returns a real sequence of length 2n-2 if the imaginary part of
the last value is equal to 0 and length 2n-1 otherwise.
This implementation would have the (IMHO desirable) property that
inverse_real_fft(real_fft(seq)) would in general equal seq. My only
concern is that if the imaginary part of the last point was not
precisely zero (due to roundoff error), you could get a sequence one
longer than the input. Offhand, I can't think of a robust algorithm
to decide if imag(seq[n]) was sufficently close to 0 to shorten the
returned sequence by 1.
--
Paul C. Janzen Research is what I'm doing when I
http://www.acs.psu.edu/users/pcj don't know what I'm doing.
- Wernher von Braun
From dars@soton.ac.uk Thu Mar 19 11:28:57 1998
From: dars@soton.ac.uk (Dave Stinchcombe)
Date: Thu, 19 Mar 1998 11:28:57 +0000 (GMT)
Subject: [Matrix-SIG] Power of trigs
Message-ID: <199803191128.LAA24519@oak.sucs.soton.ac.uk>
Hi again,
This morning I needed to write a quick and easy root finder, so obviously I
grabbed Numeric Python.
I have a problem though. I wrote the line:
Numeric.power(Numeric.cos(phi),1-2*nus)
where nus is a constant of 0.3. phi is an array holding a list of values
I'm searching through. The problem comes that this line fails when phi is
greater than pi/2.
Now obviously this is due to the fact I'm trying to calculate a complex (or
at the very least an imaginary) number. But I want to. Can any one give
some suggestions as to how to cope, or in some way make python also believe
in complex numbers.
Yours
Dave
From hochberg@wwa.com Thu Mar 19 15:17:08 1998
From: hochberg@wwa.com (Tim Hochberg)
Date: Thu, 19 Mar 1998 09:17:08 -0600
Subject: [Matrix-SIG] Power of trigs
Message-ID: <003e01bd534a$185a5360$a53cf1cf@oemcomputer>
From: Dave Stinchcombe <dars@soton.ac.uk>
>Hi again,
>This morning I needed to write a quick and easy root finder, so obviously I
>grabbed Numeric Python.
>
>I have a problem though. I wrote the line:
>Numeric.power(Numeric.cos(phi),1-2*nus)
>
>where nus is a constant of 0.3. phi is an array holding a list of values
>I'm searching through. The problem comes that this line fails when phi is
>greater than pi/2.
>
>Now obviously this is due to the fact I'm trying to calculate a complex (or
>at the very least an imaginary) number. But I want to. Can any one give
>some suggestions as to how to cope, or in some way make python also believe
>in complex numbers.
Power will return complex numbers if one of the arguments is complex,
otherwise it assumes you want a real answer and raises an exception. Two
things that should work to convince power that you mean business are:
power(cos(phi)+0j, 1-2*nus)
power(cos(phi).astype(Complex), 1-2*nus)
____
/im
From Paul F. Dubois" <dubois1@llnl.gov Thu Mar 19 15:25:51 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 19 Mar 1998 07:25:51 -0800
Subject: [Matrix-SIG] Power of trigs
Message-ID: <001601bd534b$4e677ea0$998a7380@pduboispc>
Complex literals are of the form n.nnnn j. In this case, Numeric needs you
to help it know that you want a complex power.
>>> import Numeric
>>> Numeric.power(2., .5)
1.41421356237
>>> Numeric.power(-2.0, .5)
Traceback (innermost last):
File "<stdin>", line 1, in ?
ValueError: math domain error
>>> Numeric.power(-2.0+0j, .5)
(8.65927457072e-017+1.41421356237j)
>>>
-----Original Message-----
From: Dave Stinchcombe <dars@soton.ac.uk>
To: matrix-sig@python.org <matrix-sig@python.org>
Date: Thursday, March 19, 1998 3:48 AM
Subject: [Matrix-SIG] Power of trigs
>Hi again,
>This morning I needed to write a quick and easy root finder, so obviously I
>grabbed Numeric Python.
>
>I have a problem though. I wrote the line:
>Numeric.power(Numeric.cos(phi),1-2*nus)
>
>where nus is a constant of 0.3. phi is an array holding a list of values
>I'm searching through. The problem comes that this line fails when phi is
>greater than pi/2.
>
>Now obviously this is due to the fact I'm trying to calculate a complex (or
>at the very least an imaginary) number. But I want to. Can any one give
>some suggestions as to how to cope, or in some way make python also believe
>in complex numbers.
>
>Yours
>Dave
>
>
>
>------------------------------------------------------
>Matrix-SIG maillist - Matrix-SIG@python.org
>http://www.python.org/mailman/listinfo/matrix-sig
>
From KaliazinA@cardiff.ac.uk Thu Mar 19 15:32:25 1998
From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin)
Date: Thu, 19 Mar 1998 15:32:25 -0000
Subject: [Matrix-SIG] Power of trigs
Message-ID: <001e01bd534c$50103020$8f16fb83@nedo.engin.cf.ac.uk>
-----Original Message-----
From: Dave Stinchcombe <dars@soton.ac.uk>
To: matrix-sig@python.org <matrix-sig@python.org>
Date: 19 March 1998 11:49
Subject: [Matrix-SIG] Power of trigs
>Hi again,
>This morning I needed to write a quick and easy root finder, so obviously I
>grabbed Numeric Python.
>
>I have a problem though. I wrote the line:
>Numeric.power(Numeric.cos(phi),1-2*nus)
>
>where nus is a constant of 0.3. phi is an array holding a list of values
>I'm searching through. The problem comes that this line fails when phi is
>greater than pi/2.
>
>Now obviously this is due to the fact I'm trying to calculate a complex (or
>at the very least an imaginary) number. But I want to. Can any one give
>some suggestions as to how to cope, or in some way make python also believe
>in complex numbers.
>
Decision seems to be simple in this case -
just convert explicitly first argument to a complex number format:
>>> pow(-1, 1.0)
Traceback (innermost last):
File "<stdin>", line 1, in ?
ValueError: negative number to float power
while:
>>> pow(complex(-1),1.0)
(-1+0j)
or
>>> pow(-2+0j,0.5)
(8.65927457072e-017+1.41421356237j)
But I am glad to rise again the question of weak argument's checking in
pow().
I do not want always to check validity of all possible combinations of input
arguments.
I just want pow() to return most suitable and valid result.
Andy K.
From Michal.Spalinski@fuw.edu.pl Thu Mar 19 22:21:44 1998
From: Michal.Spalinski@fuw.edu.pl (Michal.Spalinski@fuw.edu.pl)
Date: Thu, 19 Mar 98 23:21:44 +0100
Subject: [Matrix-SIG] Power of trigs
In-Reply-To: <001e01bd534c$50103020$8f16fb83@nedo.engin.cf.ac.uk> (message from Andrey Kaliazin on Thu, 19 Mar 1998 15:32:25 -0000)
Message-ID: <9803192221.AA23548@albert4.fuw.edu.pl>
Kiciuniu slodki, widze, ze Cie raczej nie ma. Ja jutro rano jade do Krakowa
i wracam w nocy a w sobote po poludniu jade do Poznania. Kiciuniu moj,
tutaj okazalo sie, ze ta sztuka Schwaba "Zaglada ludu czyli Moja watroba
jest bez sensu" idzie wlasnie w TV w rez. bajona, acha, to jest ta sztuka,
na ktorej bylam bylam w teatrze, wiec bede ogladac. Jest to zrobione
zupelnie, ale to zupelnie inaczej. Kitko, wobec tego ja tu zajrze jeszcze
po spektaklu (0.40). Caluje Cie najkochanszy J.
--
Michal Spalinski
http://info.fuw.edu.pl/~mspal/home.html
From hinsen@ibs.ibs.fr Fri Mar 20 11:42:53 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 20 Mar 1998 12:42:53 +0100
Subject: [Matrix-SIG] Power of trigs
In-Reply-To: <001e01bd534c$50103020$8f16fb83@nedo.engin.cf.ac.uk> (message
from Andrey Kaliazin on Thu, 19 Mar 1998 15:32:25 -0000)
Message-ID: <199803201142.MAA21678@lmspc1.ibs.fr>
> But I am glad to rise again the question of weak argument's checking in
> pow().
> I do not want always to check validity of all possible combinations of input
> arguments.
> I just want pow() to return most suitable and valid result.
There was some discussion about type checking in Numeric functions
in the early days of the Matrix SIG. There are two conflicting
points of view:
1) If there is a reasonable answer for my input values, I want
to get it.
2) A combination of input types that has a good chance of being
a mistake should cause an exception.
Depending on context, sqrt(-1) may be reasonable or an error,
so the compromise was to indicate the willingness to get complex
results by providing a complex argument.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
From Dirk.Engelmann@IWR.Uni-Heidelberg.De Sun Mar 22 12:34:12 1998
From: Dirk.Engelmann@IWR.Uni-Heidelberg.De (Dirk Engelmann)
Date: Sun, 22 Mar 1998 13:34:12 +0100 (CET)
Subject: [Matrix-SIG] data sharing
Message-ID: <Pine.LNX.3.95.980322130938.24460A-100000@klimt.iwr.uni-heidelberg.de>
Hi!
I'm using NumPy and a set of other python libraries.
Quite often, I've got to pass data between NumPy and
some other library.
Is there a way to pass data, without copying (fromstring/ tostring
method) ?
If not, is there more general interest ?
There is a nice mehtod by Jim Fulton for exporting
C API which could be used to do this.
Thanks!
Cheers,
Dirk Engelmann
From hinsen@ibs.ibs.fr Mon Mar 23 16:49:21 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 23 Mar 1998 17:49:21 +0100
Subject: [Matrix-SIG] data sharing
In-Reply-To: <Pine.LNX.3.95.980322130938.24460A-100000@klimt.iwr.uni-heidelberg.de>
(message from Dirk Engelmann on Sun, 22 Mar 1998 13:34:12 +0100 (CET))
Message-ID: <199803231649.RAA06744@lmspc1.ibs.fr>
> Is there a way to pass data, without copying (fromstring/ tostring
> method) ?
What exactly are you trying to do? The most obvious way of passing
data is to pass the NumPy arrays. They can be accessed as sequences
(even nested sequences), so many routines can handle them without
knowing it.
If you mean other C extension modules, it's a bit trickier. If the
C modules use the generic object interface, everything should be
fine again. If they are written for a specific data type, you'll need
to convert your arrays.
> There is a nice mehtod by Jim Fulton for exporting
> C API which could be used to do this.
The C API of the array and umath modules *is* exported. There are
already a couple of C extension modules that make use of this, e.g.
the LAPACK interface (in NumPy), the various random number modules, or
the netCDF module. But this won't help you if you are dealing with
another library that expects another data type.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
From lorenzo@argon.roma2.infn.it Mon Mar 23 17:58:54 1998
From: lorenzo@argon.roma2.infn.it (Lorenzo M. Catucci)
Date: Mon, 23 Mar 1998 18:58:54 +0100 (CET)
Subject: [Matrix-SIG] Anybody doing/having done FE PDE solving with NumPy?
Message-ID: <Pine.LNX.3.96.980323184646.29291A-100000@argon.roma2.infn.it>
So good... I managed to put two true acronyms and a false one on the same
subject line... maybe I'll do better some time... Now, I get serious: I'm
going to do some simulations, and part of my problem is to build the
static electric field inside a box, with some iregular shaped object
inside. I think that the best way to do this part, is to solve via finite
element method the Laplace equation $\nabla^2 \phi=0$ with
Dirichlet's boundary conditions on the fixed potential surfaces. Then,
I'll go to do some molecular dynamics for objects inside this field. Best
option would be to be able to describe the FEM basis directly within
python, but I still haven't managed to find a clear recipe for those
nasty functions, which need be (at least) derivable, since I'll need the
potential field gradient... Somebody could help me and tell which route
to go?
Servus,
lorenzo
From boyle@pcmdi.llnl.gov Tue Mar 24 17:32:33 1998
From: boyle@pcmdi.llnl.gov (James Boyle)
Date: Tue, 24 Mar 1998 09:32:33 -0800 (PST)
Subject: [Matrix-SIG] Feature of numeric slicing?
Message-ID: <199803241732.JAA13068@cobra.llnl.gov>
In playing with some slicing of Numeric
arrays I found the following:
(Python 1.5, the latest Numeric release 1.1?)
>>>a = Numeric.arrayrange(0,5)
>>>a
>>>array[0,1,2,3,4]
>>>c = a[1:3]
>>>c
>>>array[1,2]
>>>c[0] = 99
>>>a
>>>array[0, 99, 2, 3, 4]
>>>c
>>>array[99,2]
Is this a desired property, a feature or a bug? I have not seen
it documented, but I could have easily missed it.
It appears that c just points to a section of the array a.
If an operation such as c = a[1:3]*2.0 is carried out then
c is a new object but a plain slice retains a connection of
slicer and slicee.
In Python it is my understanding that a slice creates a new object, without
references to the slicee.
Any words of wisdom?
Jim Boyle
From hinsen@ibs.ibs.fr Tue Mar 24 17:56:22 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 24 Mar 1998 18:56:22 +0100
Subject: [Matrix-SIG] Optimized BLAS for Pentium Pros under Linux
Message-ID: <199803241756.SAA02752@lmspc1.ibs.fr>
As some of you may know, an optimized version of the BLAS library
for PentiumPro machines running Linux has been made available
recently. You can download it from
http://www.cs.utk.edu/~ghenry/distrib/
Obviously this can be used to speed up the LinearAlgebra module in
NumPy. Unfortunately the necessary compilation and linking steps are
not totally trivial, so for those who would rather not try, I have
prepared a binary release, i.e. the file lapack_lite.so statically
linked with the optimized BLAS (and in fact statically linked with
everything else, to avoid compatibility problems). You can get
it via my Web page at
http://starship.skyport.net/crew/hinsen/scientific.html
Be warned that I haven't tested this a lot, but for my applications it
works fine and given a speedup of roughly 30% for large matrices.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
From da@skivs.ski.org Tue Mar 24 18:10:22 1998
From: da@skivs.ski.org (David Ascher)
Date: Tue, 24 Mar 1998 10:10:22 -0800 (PST)
Subject: [Matrix-SIG] pickling of arrays
Message-ID: <Pine.SUN.3.96.980324100547.14657F-100000@skivs.ski.org>
FYI, The following addition to Numeric.py will allow arrays to pickle
without needing to subclass Pickler. Still inefficient, but helpful for
non-huge arrays.
--david
import copy_reg
def array_constructor(shape, typecode, thestr):
x = fromstring(thestr, typecode)
x.shape = shape
return x
def pickle_array(a):
return array_constructor, (a.shape, a.typecode(), a.tostring(),)
copy_reg.pickle(ArrayType, pickle_array, array_constructor)
From hinsen@ibs.ibs.fr Wed Mar 25 17:57:50 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 25 Mar 1998 18:57:50 +0100
Subject: [Matrix-SIG] Feature of numeric slicing?
In-Reply-To: <199803241732.JAA13068@cobra.llnl.gov> (message from James Boyle
on Tue, 24 Mar 1998 09:32:33 -0800 (PST))
Message-ID: <199803251757.SAA07560@lmspc1.ibs.fr>
> >>>a = Numeric.arrayrange(0,5)
> >>>a
> >>>array[0,1,2,3,4]
> >>>c = a[1:3]
> >>>c
> >>>array[1,2]
> >>>c[0] = 99
> >>>a
> >>>array[0, 99, 2, 3, 4]
> >>>c
> >>>array[99,2]
> Is this a desired property, a feature or a bug? I have not seen
Feature.
> It appears that c just points to a section of the array a.
> If an operation such as c = a[1:3]*2.0 is carried out then
> c is a new object but a plain slice retains a connection of
> slicer and slicee.
Exactly.
> In Python it is my understanding that a slice creates a new object, without
> references to the slicee.
True for lists, but not for NumPy arrays. It is simply very useful
to be able to share the array data space in this way. On the other
hand, it can lead to bad surprises, so it should probably be pointed
out somewhere clearly.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
From janne@avocado.pc.helsinki.fi Wed Mar 25 18:11:30 1998
From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen)
Date: 25 Mar 1998 20:11:30 +0200
Subject: [Matrix-SIG] Feature of numeric slicing?
In-Reply-To: Konrad Hinsen's message of "Wed, 25 Mar 1998 18:57:50 +0100"
References: <199803251757.SAA07560@lmspc1.ibs.fr>
Message-ID: <oan2eetzcd.fsf@avocado.pc.helsinki.fi>
Konrad Hinsen <hinsen@ibs.ibs.fr> writes:
> True for lists, but not for NumPy arrays. It is simply very useful
> to be able to share the array data space in this way. On the other
> hand, it can lead to bad surprises, so it should probably be pointed
> out somewhere clearly.
Yes indeed. :)
But I agree that it can be very useful, especially with large
matrices.
Another thing which is useful and should be documented is the optional
second or third argument to ufuncs.
--
Janne Sinkkonen <janne@iki.fi> <URL: http://www.iki.fi/~janne/ >
From da@skivs.ski.org Thu Mar 26 23:39:01 1998
From: da@skivs.ski.org (David Ascher)
Date: Thu, 26 Mar 1998 15:39:01 -0800 (PST)
Subject: [Matrix-SIG] general 2D convolution, again.
Message-ID: <Pine.SUN.3.96.980326153633.18585D-100000@skivs.ski.org>
This topic comes up repeatedly, but I haven't seen a good answer yet.
Problem: doing 2D convolutions with non-square and different shape arrays
is (from what I've read) not doable using FFT multiplication. Has anyone
coded such a convolution in either straight NumPy or using a C extension
module? Linear, circular, with sweet-spot setting, etc?
If not, I'll probably end up writing one, but it's likely to be buggy for
a while...
--david
From janne@avocado.pc.helsinki.fi Fri Mar 27 09:20:21 1998
From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen)
Date: 27 Mar 1998 11:20:21 +0200
Subject: [Matrix-SIG] general 2D convolution, again.
In-Reply-To: David Ascher's message of "Thu, 26 Mar 1998 15:39:01 -0800 (PST)"
References: <Pine.SUN.3.96.980326153633.18585D-100000@skivs.ski.org>
Message-ID: <oara3oqylm.fsf@avocado.pc.helsinki.fi>
David Ascher <da@skivs.ski.org> writes:
> Problem: doing 2D convolutions with non-square and different shape arrays
> is (from what I've read) not doable using FFT multiplication.
It depends on what kind of convolution you want. Gaussian kernel
factorizes into two components and can be implemented by FFT.
--
Janne Sinkkonen <janne@iki.fi> <URL: http://www.iki.fi/~janne/ >
From Dirk.Engelmann@IWR.Uni-Heidelberg.De Fri Mar 27 09:52:46 1998
From: Dirk.Engelmann@IWR.Uni-Heidelberg.De (Dirk Engelmann)
Date: Fri, 27 Mar 1998 10:52:46 +0100 (CET)
Subject: [Matrix-SIG] general 2D convolution, again.
In-Reply-To: <Pine.SUN.3.96.980326153633.18585D-100000@skivs.ski.org>
Message-ID: <Pine.LNX.3.95.980327104846.22135B-100000@klimt.iwr.uni-heidelberg.de>
On Thu, 26 Mar 1998, David Ascher wrote:
> This topic comes up repeatedly, but I haven't seen a good answer yet.
Some time ago I posed the same question.
>
> Problem: doing 2D convolutions with non-square and different shape arrays
> is (from what I've read) not doable using FFT multiplication. Has anyone
> coded such a convolution in either straight NumPy or using a C extension
> module? Linear, circular, with sweet-spot setting, etc?
I need it for image processing - and for large images (matrices)
FFT is quite usefull - but not for non-square shape.
If done it in my C++ library with swig interface to Python. But it's
not that flexible (Linear, circular, ...).
I would like to have it in NumPy very much!
> If not, I'll probably end up writing one, but it's likely to be buggy for
> a while...
>
Dirk Engelmann
From David.Buscher@durham.ac.uk Fri Mar 27 11:15:44 1998
From: David.Buscher@durham.ac.uk (David Buscher)
Date: Fri, 27 Mar 1998 11:15:44 +0000 (GMT)
Subject: [Matrix-SIG] general 2D convolution, again.
In-Reply-To: <Pine.SUN.3.96.980326153633.18585D-100000@skivs.ski.org>
Message-ID: <Pine.SOL.3.91-941213.980327111155.29058C-100000@duss0.dur.ac.uk>
On Thu, 26 Mar 1998, David Ascher wrote:
> Problem: doing 2D convolutions with non-square and different shape arrays
> is (from what I've read) not doable using FFT multiplication.
I believe this is something of an oversimplification. All convolutions
are doable using an FFT, providing you pad the arrays with zeros to a
mutually compatible size, and perhaps add extra padding to take care of
edge effects. The only question then is whether this is the most
efficient way to do the computation, which is clearly an
implementation-dependent topic. Someone please correct me if I'm wrong!
David
----------------------------------------+-------------------------------------
David Buscher | Phone +44 191 374 7462
Dept of Physics, University of Durham, | Fax +44 191 374 3709
South Road, Durham DH1 3LE, UK | Email david.buscher@durham.ac.uk
----------------------------------------+-------------------------------------
From janne@avocado.pc.helsinki.fi Fri Mar 27 15:31:03 1998
From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen)
Date: 27 Mar 1998 17:31:03 +0200
Subject: [Matrix-SIG] general 2D convolution, again.
In-Reply-To: David Buscher's message of "Fri, 27 Mar 1998 11:15:44 +0000 (GMT)"
References: <Pine.SOL.3.91-941213.980327111155.29058C-100000@duss0.dur.ac.uk>
Message-ID: <oad8f8tako.fsf@avocado.pc.helsinki.fi>
David Buscher <David.Buscher@durham.ac.uk> writes:
> I believe this is something of an oversimplification. All convolutions
> are doable using an FFT, providing you pad the arrays with zeros to a
> mutually compatible size, and perhaps add extra padding to take care of
> edge effects. The only question then is whether this is the most
> efficient way to do the computation, which is clearly an
> implementation-dependent topic. Someone please correct me if I'm wrong!
You are probably right (someone please correct me if I'm wrong! :))
My earlier note about 'separable' or factorizing kernels was a bit
irrelevant and incorrect. But convolutions by separable kernels are
nice anyway, because you can do them as successive 1D convolutions.
Gaussian and rectangular 2D kernels are separable, and therefore this
kind of convolutions can be done by doing 1D convolutions successively
over the two axis, something like:
convImage=convolution1d(convolution1d(image,kernel,axis=0),kernel,axis=1)
--
Janne Sinkkonen <janne@iki.fi> <URL: http://www.iki.fi/~janne/ >
From David Ascher <da@skivs.ski.org> Fri Mar 27 17:04:55 1998
From: David Ascher <da@skivs.ski.org> (David Ascher)
Date: Fri, 27 Mar 1998 09:04:55 -0800 (PST)
Subject: [Matrix-SIG] general 2D convolution, again.
In-Reply-To: <Pine.LNX.3.95.980327104846.22135B-100000@klimt.iwr.uni-heidelberg.de>
Message-ID: <Pine.SUN.3.96.980327090034.26704A-100000@skivs.ski.org>
On Fri, 27 Mar 1998, Dirk Engelmann wrote:
> > Problem: doing 2D convolutions with non-square and different shape arrays
> > is (from what I've read) not doable using FFT multiplication. Has anyone
> > coded such a convolution in either straight NumPy or using a C extension
> > module? Linear, circular, with sweet-spot setting, etc?
>
> I need it for image processing - and for large images (matrices)
> FFT is quite usefull - but not for non-square shape.
> If done it in my C++ library with swig interface to Python. But it's
> not that flexible (Linear, circular, ...).
>
> I would like to have it in NumPy very much!
Right, I'm doing image-processing-like sorts of things.
I got impatient and wrote one, but I have to finish the details It's not
smart at all, but someone who likes to optimize C code can feel free
to take my code and make it run like the wind. At this point having
*something* is more important to me than having the best.
I suspect that a smart FFT based implementation would be much faster, but
I don't have the confidence to know how to do it right. Once I'm
convinced that I have a working implementation, it can be used as a
reference implementation for checking an FFT-based implementation.
More news later...
--david
From da@skivs.ski.org Fri Mar 27 20:06:45 1998
From: da@skivs.ski.org (David Ascher)
Date: Fri, 27 Mar 1998 12:06:45 -0800 (PST)
Subject: [Matrix-SIG] 2D kernel convolution
Message-ID: <Pine.SUN.3.96.980327120200.26832F-200000@skivs.ski.org>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--1900032184-2002504639-891029205=:26832
Content-Type: TEXT/PLAIN; charset=US-ASCII
Well, I got circular convolution to apparently work, but I'm quite baffled
as to why linear convolution doesn't work.
For a simple yet sufficient description of these things, look at
http://tierra.ciens.ucv.ve/dipcourse/html/linear/convolution/front-page.html
I'm attaching the module here so that folks can
#1) use it if they only need circular convolution
#2) tell me why linear convolution doesn't work
#3) optimize it if they wish (I'd rather #2) happened first -- it's hard
to modify optimized code...
--david
--1900032184-2002504639-891029205=:26832
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="kconvmodule.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SUN.3.96.980327120645.26832G@skivs.ski.org>
Content-Description:
I2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPG1hdGguaD4NCiNpbmNs
dWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgIlB5dGhvbi5oIg0KI2luY2x1ZGUg
ImFycmF5b2JqZWN0LmgiDQoNDQpzdGF0aWMgUHlPYmplY3QgKkVycm9yT2Jq
ZWN0Ow0KDQojZGVmaW5lIFRSWShFKSBpZighIChFKSkgcmV0dXJuIE5VTEwN
CiNkZWZpbmUgQVNTRVJUKEUsTSkgaWYoIShFKSkgcmV0dXJuIEVycm9yUmV0
dXJuKE0pDQoNCnN0YXRpYyBjaGFyIGRvY19kY29udltdID0NDQoiZGNvbnYo
bSwgaywgKHgseSksfCBjaXJjKSB3aWxsIHJldHVybiBhIG1hdHJpeCBvZiB0
aGUgc2FtZSBcbiJcDQ0KImRpbWVuc2lvbnMgYXMgbSB3aGljaCBpcyB0aGUg
cmVzdWx0IG9mIHRoZSBjb252b2x1dGlvbiBvZiBtIHdpdGggdGhlXG4iXA0N
CiJrZXJuZWwgay4gIG0gYW5kIGsgbmVlZCB0byBiZSBhcnJheXMgb2YgZG91
Ymxlcy5cbiJcDQ0KIlRoZSB0aGlyZCBhcmd1bWVudCBpcyB0aGUgb3JpZ2lu
IG9mIHRoZSBrZXJuZWwgKGFrYSBzd2VldCBzcG90KS5cbiJcDQ0KIlRoZSBs
YXN0IG9wdGlvbmFsIGFyZ3VtZW50IGlzIGEgbnVtYmVyICgwIGJ5IGRlZmF1
bHQpLiAgSWYgdGhhdFxuIlwNDQoibnVtYmVyIGlzIG5vbi16ZXJvLCBhIGNp
cmN1bGFyIGNvbnZvbHV0aW9uIGlzIHBlcmZvcm1lZC5cbiJcDQ0KIk90aGVy
d2lzZSBhIGxpbmVhciBjb252b2x1dGlvbiBpcyBwZXJmb3JtZWQuXG4iXA0N
CiJcblxuTk9URTogQ3VycmVudGx5IG9ubHkgY2lyY3VsYXIgY29udm9sdXRp
b24gYXBwZWFycyB0byB3b3JrISEhXG4iOw0KDQpzdGF0aWMgUHlPYmplY3Qg
Kmtjb252X2Rjb252KFB5T2JqZWN0ICppZ25vcmVkLCBQeU9iamVjdCAqYXJn
cykgew0KDQ0KCVB5T2JqZWN0ICpvcCwgKmtwOw0KCVB5QXJyYXlPYmplY3Qg
KmltYWdlLCAqa2VybmVsLCAqY29udm9sdXRpb247DQoNCglkb3VibGUgKmlE
YXRhOw0KCWRvdWJsZSAqa0RhdGE7DQ0KCWRvdWJsZSAqY0RhdGE7DQ0KCWRv
dWJsZSBjdW12YWw7DQ0KDQoJaW50IHNYLCBzWTsgICAvKiBzd2VldCBzcG90
IGNvb3JkaW5hdGVzIGZvciB0aGUga2VybmVsICovDQoJaW50IGlXaWR0aCwg
aUhlaWdodCwga1dpZHRoLCBrSGVpZ2h0LCBjSGVpZ2h0LCBjV2lkdGg7DQoJ
aW50IGtYLCBrWSwgY1gsIGNZLCBpWCwgaVk7DQoJaW50IGNpcmN1bGFyID0g
MDsgIC8qIGJ5IGRlZmF1bHQgZG8gbGluZWFyIGNvbnZvbHV0aW9uICovDQoJ
aW50IGtJbmRleCwgaUluZGV4LCBjSW5kZXg7DQoNCglUUlkoUHlBcmdfUGFy
c2VUdXBsZShhcmdzLCAiT08oaWkpfGkiLCAmb3AsICZrcCwgJnNYLCAmc1ks
ICZjaXJjdWxhcikpOw0KCVRSWShQeUFycmF5X0NoZWNrKG9wKSk7DQoJaW1h
Z2UgPSAoUHlBcnJheU9iamVjdCAqKW9wOw0KCVRSWShQeUFycmF5X0NoZWNr
KGtwKSk7DQoJa2VybmVsID0gKFB5QXJyYXlPYmplY3QgKilrcDsNCglpZiAo
aW1hZ2UtPmRlc2NyLT50eXBlX251bSAhPSBQeUFycmF5X0RPVUJMRSB8fA0K
CSAgICBrZXJuZWwtPmRlc2NyLT50eXBlX251bSAhPSBQeUFycmF5X0RPVUJM
RSkgew0KCQlQeUVycl9TZXRTdHJpbmcoUHlFeGNfVmFsdWVFcnJvciwiYm90
aCBhcnJheXMgbXVzdCBiZSBhcnJheXMgb2YgZG91YmxlcyIpOyAgICAgIA0K
CQlyZXR1cm4gTlVMTDsNCgl9DQoJaWYgKGltYWdlLT5uZCAhPSAyIHx8DQoJ
ICAgIGtlcm5lbC0+bmQgIT0gMikgew0KCQlQeUVycl9TZXRTdHJpbmcoUHlF
eGNfVmFsdWVFcnJvciwiYm90aCBhcnJheXMgbXVzdCBiZSBhcnJheXMgb2Yg
cmFuayAyIik7ICAgICAgDQoJCXJldHVybiBOVUxMOw0KCX0NCglpZiAoY2ly
Y3VsYXIpIHsgLyogY2lyY3VsYXIgY29udm9sdXRpb24gKi8NCgkJY29udm9s
dXRpb24gPSAoUHlBcnJheU9iamVjdCAqKVB5QXJyYXlfRnJvbURpbXMoaW1h
Z2UtPm5kLCBpbWFnZS0+ZGltZW5zaW9ucywgaW1hZ2UtPmRlc2NyLT50eXBl
X251bSk7DQoJfSBlbHNlIHsgIC8qIGxpbmVhciBjb252b2x1dGlvbiAqLw0K
CQlpbnQgZGltc1syXTsNCgkJZGltc1swXSA9IGltYWdlLT5kaW1lbnNpb25z
WzBdICsga2VybmVsLT5kaW1lbnNpb25zWzBdIC0gMTsgDQ0KCQlkaW1zWzFd
ID0gaW1hZ2UtPmRpbWVuc2lvbnNbMV0gKyBrZXJuZWwtPmRpbWVuc2lvbnNb
MV0gLSAxOyANDQoJCWNvbnZvbHV0aW9uID0gKFB5QXJyYXlPYmplY3QgKilQ
eUFycmF5X0Zyb21EaW1zKGltYWdlLT5uZCwgZGltcywgaW1hZ2UtPmRlc2Ny
LT50eXBlX251bSk7DQoJfQ0KCWlmIChjb252b2x1dGlvbiA9PSBOVUxMKSB7
DQoJICBQeUVycl9TZXRTdHJpbmcoUHlFeGNfTWVtb3J5RXJyb3IsIkNvdWxk
bid0IGNyZWF0ZSByZXN1bHQgYXJyYXkiKTsgICAgICANCgkgIHJldHVybiBO
VUxMOw0KCX0NCglpV2lkdGggPSBpbWFnZS0+ZGltZW5zaW9uc1sxXTsgIA0N
CglpSGVpZ2h0ID0gaW1hZ2UtPmRpbWVuc2lvbnNbMF07ICANDQoJa1dpZHRo
ID0ga2VybmVsLT5kaW1lbnNpb25zWzFdOyAgDQ0KCWtIZWlnaHQgPSBrZXJu
ZWwtPmRpbWVuc2lvbnNbMF07ICANDQoJY1dpZHRoID0gY29udm9sdXRpb24t
PmRpbWVuc2lvbnNbMV07ICANDQoJY0hlaWdodCA9IGNvbnZvbHV0aW9uLT5k
aW1lbnNpb25zWzBdOyAgDQ0KDQ0KCWlEYXRhID0gKGRvdWJsZSAqKWltYWdl
LT5kYXRhOw0KCWtEYXRhID0gKGRvdWJsZSAqKWtlcm5lbC0+ZGF0YTsNDQoJ
Y0RhdGEgPSAoZG91YmxlICopY29udm9sdXRpb24tPmRhdGE7DQ0KDQ0KCS8q
IGl0ZXJhdGUgb3ZlciBldmVyeSBsaW5lIGluIHRoZSBjb252ICovDQogICAg
ICAgIGZvciAoY1kgPSAwOyBjWSA8IGNIZWlnaHQ7IGNZKyspIHsNDQoJCS8q
IGl0ZXJhdGUgb3ZlciBldmVyeSBwaXhlbCBpbiBlYWNoIGxpbmUgb2YgdGhl
IGNvbnYgKi8NCgkJZm9yIChjWCA9IDA7IGNYIDwgY1dpZHRoOyBjWCsrKSB7
DQ0KCQkJLyogaXRlcmF0ZSBvdmVyIGV2ZXJ5IGxpbmUgaW4gdGhlIGtlcm5l
bCAqLw0NCgkJCWN1bXZhbCA9IDAuMDsNDQoJCQlmb3IgKGtZID0gMDsga1kg
PCBrSGVpZ2h0OyBrWSsrKSB7DQoJCQkJLyogZmluZCB0aGUgcm93ICMgZm9y
IHRoYXQga2VybmVsIHJvdyBpbiB0aGUgaW1hZ2UgKi8NDQoJCQkJZm9yIChr
WCA9IDA7IGtYIDwga1dpZHRoOyBrWCsrKSB7DQ0KCQkJCQlpWSA9IGNZICsg
a1kgLSBzWTsNDQoJCQkJCWlYID0gY1ggKyBrWCAtIHNYOw0NCgkJCQkJaWYg
KGNpcmN1bGFyKSB7DQ0KCQkJCQkJaWYgKGlZID49IGlIZWlnaHQpIGlZID0g
aVkgLSBpSGVpZ2h0Ow0NCgkJCQkJCWVsc2UgaWYgKGlZIDwgMCkgICBpWSA9
IGlZICsgaUhlaWdodDsNDQoJCQkJCQlpZiAoaVggPj0gaVdpZHRoKSAgaVgg
PSBpWCAtIGlXaWR0aDsNDQoJCQkJCQllbHNlIGlmIChpWCA8IDApICAgaVgg
PSBpWCArIGlXaWR0aDsNDQoJCQkJCX0NDQoJCQkJCWlmIChjaXJjdWxhciB8
fCAoaVkgPj0gMCAmJiBpWSA8IGlIZWlnaHQgJiYgaVggPj0gMCAmJiBpWCA8
IGlXaWR0aCkpIHsNDQoJCQkJCQlrSW5kZXggPSBrWCArIGtZICoga1dpZHRo
Ow0NCgkJCQkJCWlJbmRleCA9IGlYICsgaVkgKiBpV2lkdGg7DQ0KCQkJCQkJ
aWYgKGlJbmRleCA+PSAwICYmIGlJbmRleCA8IGlXaWR0aCAqIGlIZWlnaHQg
JiYNDQoJCQkJCQkgICAga0luZGV4ID49IDAgJiYga0luZGV4IDwga1dpZHRo
ICoga0hlaWdodCkgew0NCgkJCQkJCQljdW12YWwgKz0gaURhdGFbaUluZGV4
XSAqIGtEYXRhW2tJbmRleF07DQ0KCQkJCQkJfQ0NCgkJCQkJfQ0KCQkJCX0N
CgkJCX0NDQoJCQljSW5kZXggPSBjWCArIGNZICogY1dpZHRoOw0NCgkJCWNE
YXRhW2NJbmRleF0gPSBjdW12YWw7DQ0KCQl9DQoJfQ0NCglyZXR1cm4gKFB5
T2JqZWN0ICopY29udm9sdXRpb247DQp9DQoNCnN0YXRpYyBzdHJ1Y3QgUHlN
ZXRob2REZWYga2NvbnZfbWV0aG9kc1tdID0gew0KICB7ImRjb252Iiwga2Nv
bnZfZGNvbnYsIDEsIGRvY19kY29udn0sDQogIHtOVUxMLAkJTlVMTCwgMH0J
CS8qIHNlbnRpbmVsICovDQp9Ow0KDQp2b2lkIGluaXRrY29udigpIHsNCiAg
UHlPYmplY3QgKm07DQogIC8qIENyZWF0ZSB0aGUgbW9kdWxlIGFuZCBhZGQg
dGhlIGZ1bmN0aW9ucyAqLw0KICBpbXBvcnRfYXJyYXkoKTsNCiAgbSA9IFB5
X0luaXRNb2R1bGUoImtjb252Iiwga2NvbnZfbWV0aG9kcyk7DQogIC8qIENo
ZWNrIGZvciBlcnJvcnMgKi8NCiAgaWYgKFB5RXJyX09jY3VycmVkKCkpDQog
ICAgUHlfRmF0YWxFcnJvcigiY2FuJ3QgaW5pdGlhbGl6ZSBtb2R1bGUga2Nv
bnYiKTsNCn0NCg==
--1900032184-2002504639-891029205=:26832--