From klm@CNRI.Reston.Va.US Mon Sep 2 19:09:28 1996
From: klm@CNRI.Reston.Va.US (Ken Manheimer)
Date: Mon, 2 Sep 1996 14:09:28 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] NumericalPython
In-Reply-To: <Pine.SOL.3.95.960830171727.16987A-100000@glyph>
Message-ID: <Pine.SOL.3.95.960902140201.21477B-100000@glyph>
Replying to my own message:
- Kevin maguire seemed to receive an incomplete matrix-sig archive when
he requested it from the majordomo list server
- When i tried it, i saw something that may have appeared to be an
incomplete archive - the last 1/3 of it was collected into a single
message (though the whole thing was there)
- I attributed the behavior to Pine, my MUA.
On further investigation, it looks like:
1) The mailing list archive is intact - i, at least, get the whole
thing, when i request it.
2) The message splitting is probably due to procmail, which i recently
started using. The problem doesn't happen with procmail out of the
loop. (My use of procmail should not, of course, have any affect on
anyone else, since i have procmail deployed in my own environment,
via .forward. I mention it only so others will be warned.)
Ken
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Mon Sep 2 21:54:46 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Mon, 2 Sep 1996 16:54:46 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Integrated Simulation Environment?
Message-ID: <199609022054.QAA04261@maigret>
Hi folks.
I keep working on simulations using NumPy, and I'd like to develop
some tools which make it easier to use. Here are some random thoughts
on the topic.
1) I'd like to have controlled persistency. For example, I would like
to have "project files" which maintain a state accross invocations,
including but not restricted to:
- configurable all/none/chosen intermediate variables
- function definitions in the interpreter
- graphs of data (using PIL or OpenGL or whatever else comes
along)
2) I need "smart simulation objects", which incorporate notions like
labeled, unit-ful, range-ful axes, a notion of dependency between
objects (so that if I change the definition of "input_set", then all
of the relevant dependencies can be updated).
3) I need graphing capabilities. This is pretty obvious, so I'll just
say that if 2) above is implemented, some parts of this are easy --
labeling the axes in the correct units, etc., should be trivial.
I have some old (outdated) preliminary work addressing the "axis" part
of 2), and I know that Konrad has thought about that issue as well,
both in terms of physical quantities and of labeled axes. I keep
thinking about 3), but I've been waiting for some settling on the
graphics front. I haven't thought hard about 1) much at all, but I know
from the discussions on this list that some have played with
pickle/dump, which would clearly be at the core of that functionality.
These tools are what I think will make Python have a chance when
compared to Matlab, S+, etc. I'll be working on them for my own good,
but I was wondering if others were thinking along the same lines.
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From dubois1@llnl.gov Tue Sep 3 17:59:23 1996
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 3 Sep 1996 09:59:23 -0700
Subject: [PYTHON MATRIX-SIG] Integrated Simulation Environment?
Message-ID: <9609031658.AA20801@icf.llnl.gov.llnl.gov>
David,
Some comments based on our experience.
a. For a system involving compiled code, we used a Perl script (Python
hadn't been invented yet!) to proceed from a small "project description
file" to create the
correct "make" files. For persistance from the code itself we used
"PDB", a self-describing file format available in the
public domain. We have made a basic interface from Python which is
freely available. (on our ftp site, ftp-icf.llnl.gov).
PDB is part of the "Pact" project, available from coral.llnl.gov.
b. Experience with "smart" simulation objects is not promising. Suppose,
for example, that you know something about
arrays y and x, and wish to plot y vs. x. You want the labels, units,
etc. to be right. Supposing that you have
accomplished this, the next thing that will happen is that someone wants
to plot ln(1 + y**2) vs. ln(x), or something
like that. There is no reasonable way to calculate the labels, units,
range, etc.
Therefore the standard approach to this is to make persistent files that
support these notions. The PDB library has
some support for this using a concept called mappings. There is also a more
elaborate interface named SILO which
contains a larger number of standard objects. (SILO is on top of PDB). LLNL
is almost done with a Python/SILO interface.
On the graphics front, we have a working interface to Gist (part of the
Yorick project) which supports curves, contour maps,
cell arrays, etc., and are testing our "nice" interface, including 3-D
stuff. Lee Taylor of LLNL is well along on an interface to
the Pact graphics (called PGS). Geoff Furnish of LLNL has a Tk/PLPLOT
widget. We also have an interface to Narcisse,
a good 3-d exploratory graphics server produced by the Centre d'Etudes de
Limeil-Valenton; a recent message from them
indicates they are planning to release Narcisse for general use.
----------
> From: David Ascher <da@maigret.cog.brown.edu>
> To: matrix-sig@python.org
> Subject: [PYTHON MATRIX-SIG] Integrated Simulation Environment?
> Date: Monday, September 02, 1996 1:54 PM
>
> Hi folks.
>
> I keep working on simulations using NumPy, and I'd like to develop
> some tools which make it easier to use. Here are some random thoughts
> on the topic.
>
> 1) I'd like to have controlled persistency. For example, I would like
> to have "project files" which maintain a state accross invocations,
> including but not restricted to:
> - configurable all/none/chosen intermediate variables
> - function definitions in the interpreter
> - graphs of data (using PIL or OpenGL or whatever else comes
> along)
>
> 2) I need "smart simulation objects", which incorporate notions like
> labeled, unit-ful, range-ful axes, a notion of dependency between
> objects (so that if I change the definition of "input_set", then all
> of the relevant dependencies can be updated).
>
> 3) I need graphing capabilities. This is pretty obvious, so I'll just
> say that if 2) above is implemented, some parts of this are easy --
> labeling the axes in the correct units, etc., should be trivial.
>
> I have some old (outdated) preliminary work addressing the "axis" part
> of 2), and I know that Konrad has thought about that issue as well,
> both in terms of physical quantities and of labeled axes. I keep
> thinking about 3), but I've been waiting for some settling on the
> graphics front. I haven't thought hard about 1) much at all, but I know
> from the discussions on this list that some have played with
> pickle/dump, which would clearly be at the core of that functionality.
>
> These tools are what I think will make Python have a chance when
> compared to Matlab, S+, etc. I'll be working on them for my own good,
> but I was wondering if others were thinking along the same lines.
>
> --david
>
>
> =================
> MATRIX-SIG - SIG on Matrix Math for Python
>
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Tue Sep 3 19:27:15 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 3 Sep 96 19:27:15 +0100
Subject: [PYTHON MATRIX-SIG] Integrated Simulation Environment?
In-Reply-To: <199609022054.QAA04261@maigret> (da@maigret.cog.brown.edu)
Message-ID: <199609031730.TAA29024@ibs.ibs.fr>
> 1) I'd like to have controlled persistency. For example, I would like
> to have "project files" which maintain a state accross invocations,
> including but not restricted to:
> - configurable all/none/chosen intermediate variables
> - function definitions in the interpreter
> - graphs of data (using PIL or OpenGL or whatever else comes
> along)
Sounds a lot like APL workspaces... Yes, I miss those too. However,
this is hardly specific for numerical applications. It ought to be
considered for interactive use in general. Isn't there a SIG on
development environments?
My personal solution is to use Emacs as my work environment. This makes
typing into a (permanent) file and executing from it easy enough that
the lack of real interactivity hardly matters. What I would like to have
is a key combination that kills the Python buffer and starts a fresh session
with the current buffer as input, but that shouldn't be too hard...
That still doesn't take care of persistence, for which I have adopted a
standard command sequence (based on pickling, of course) that I might
one day turn into a module. Basically, it saves all relevant objects
into a file, and the next time loads this file and recalculates all
objects that were not in it.
> 2) I need "smart simulation objects", which incorporate notions like
> labeled, unit-ful, range-ful axes, a notion of dependency between
> objects (so that if I change the definition of "input_set", then all
> of the relevant dependencies can be updated).
Sounds like a simple matter of a few Python classes. Go ahead...
> 3) I need graphing capabilities. This is pretty obvious, so I'll just
> say that if 2) above is implemented, some parts of this are easy --
> labeling the axes in the correct units, etc., should be trivial.
Indeed, but it's still a lot of work.
> These tools are what I think will make Python have a chance when
> compared to Matlab, S+, etc. I'll be working on them for my own good,
> but I was wondering if others were thinking along the same lines.
Definitely. My problem is just an accute lack of time. Not that I am
not doing Python programming, I am doing lots of it. But I have to
concentrate on what I need for my real job, which right now involves
doing molecular modelling in Python. Works beautifully until now, but
there remains a lot to be done...
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 cgw@pgt.com Tue Sep 3 16:26:07 1996
From: cgw@pgt.com (Charles G Waldman)
Date: Tue, 03 Sep 1996 11:26:07 -0400
Subject: [PYTHON MATRIX-SIG] Default Axes revisited
In-Reply-To: Your message of "Fri, 30 Aug 1996 17:39:13 EDT."
<9608302137.AA18483@goldilocks.LCS.MIT.EDU>
Message-ID: <9609031526.AA18847@reactor.pgt>
Jim wrote:
> However, because I don't think it's always obvious what's a structural
and
> what's a numeric operation, all numeric operations will have a "_"
after
> their name.
Just to put in my $0.02:
I think that using names ending in underscores to distinguish structural
from numeric_ operations lacks elegance.
How about making another module, called Structural?
Then:
from Numeric import argsort
from Structural import concatenate
Use the already-existing Python notion of modules to make it clear which
operations are numeric and which are structural. Don't introduce any new
and arbitrary convention about trailing underscores.
> I will also probably define functions of the form:
>
> def argmax(x,y=None):
> raise AttributeError, "argmax is a Numeric function, use argmax_"
I second Konrad's and Guido's comments that this is not a good idea!
=============================
| Charles G. Waldman |
| Princeton Gamma-Tech, Inc.|
| cgw@pgt.com |
=============================
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From tim@lassi.ece.uiuc.edu Tue Sep 3 21:01:10 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Tue, 3 Sep 1996 15:01:10 -0500
Subject: [PYTHON MATRIX-SIG] Default Axes revisited
In-Reply-To: <9609031526.AA18847@reactor.pgt> (message from Charles G Waldman
on Tue, 03 Sep 1996 11:26:07 -0400)
Message-ID: <199609031958.PAA27068@python.org>
>How about making another module, called Structural?
>
>Then:
>
>from Numeric import argsort
>from Structural import concatenate
This sounds like a great idea to me!
--
-tim
+--------------------------------------------------------------------+
| Tim Hochberg Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu University of Illinois |
| http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 |
+--------------------------------------------------------------------+
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Wed Sep 4 14:15:32 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 4 Sep 1996 09:15:32 -0400
Subject: [PYTHON MATRIX-SIG] Default Axes revisited
Message-ID: <9609041313.AA28790@goldilocks.LCS.MIT.EDU>
> Jim wrote:
> > However, because I don't think it's always obvious what's a structural
and
> > what's a numeric operation, all numeric operations will have a "_"
after
> > their name.
>
> Just to put in my $0.02:
>
> I think that using names ending in underscores to distinguish structural
> from numeric_ operations lacks elegance.
I don't think anyone will argue with you here, including myself :-)
> How about making another module, called Structural?
>
> Then:
>
> from Numeric import argsort
> from Structural import concatenate
>
> Use the already-existing Python notion of modules to make it clear which
> operations are numeric and which are structural. Don't introduce any new
> and arbitrary convention about trailing underscores.
I like this basic idea, but as usual I'm having some problems with the
details (and therein lies the devil)...
Current situation:
There is a package called Numeric Python.
If you do import Numeric, you get all of the functions in that package.
This includes many functions which are axis independent:
sin, choose, zeros, greater, arrayrange, ...
Some which are structural:
take, repeat, ...
Some which are numeric (well sort of):
sort, argmax, ...
I assume that the new proposal would be to put all of these in seperate
modules? What would you name these three modules (or would you combine
some of them together?)
My other major concern is extensibility.
fft will not come in the basic package of functions.
Neither will inverse, svd, or others.
These will all come in seperate modules with their own unique names. I
myself have a module for speech recognition that has both structural
(framing operations) and numeric (mfcc's) functions in it. Would you
suggest that this be broken up into two modules?
> > I will also probably define functions of the form:
> >
> > def argmax(x,y=None):
> > raise AttributeError, "argmax is a Numeric function, use argmax_"
>
> I second Konrad's and Guido's comments that this is not a good idea!
Guido rarely needs seconding on this sort of thing. Forget I ever
mentioned this foolish idea.
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From mclay@eeel.nist.gov Wed Sep 4 11:51:35 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Wed, 4 Sep 1996 10:51:35 GMT
Subject: [PYTHON MATRIX-SIG] Default Axes revisited
In-Reply-To: <9609041313.AA28790@goldilocks.LCS.MIT.EDU>
References: <9609041313.AA28790@goldilocks.LCS.MIT.EDU>
Message-ID: <199609041051.KAA08734@fermi.eeel.nist.gov>
Charles G. Waldman writes:
>
> Jim wrote:
> > However, because I don't think it's always obvious what's a structural
> and
> > what's a numeric operation, all numeric operations will have a "_"
> after
> > their name.
>
> Just to put in my $0.02:
>
> I think that using names ending in underscores to distinguish structural
> from numeric_ operations lacks elegance.
>
> How about making another module, called Structural?
>
> Then:
>
> from Numeric import argsort
> from Structural import concatenate
>
> Use the already-existing Python notion of modules to make it clear which
> operations are numeric and which are structural. Don't introduce any new
> and arbitrary convention about trailing underscores.
>
This solution is much better than using a naming convention. It uses
modules to classify functions into different catagories rather than
forcing everything into a single one size fits all containter. The
docstring at the begining of the module could be used to explain the
convension used for the axis definition within the module.
There is a problem with calling the module Structural. Like Tkinter,
the name is too long a name for something that must be used as a
qualifier many times within a file. This encourages importing the
name into the local namespace. Another option on usage convension
would be:
import Structural; S = Structural
S.concatenate(...)
This notation make the usage of the names short, but allows someone
reading the file to see that the full name is Structural.
Perhaps packages could also be used to further subdivide the Numerics into
more specialized collections of objects. For instance Different
packages baed on the Numeric module could be added as specializations
of that module:
import ni
import Numeric.MolecularModeling; MM = Numeric.MolecularModeling
The Numeric.MolecularModeling module contains all the object
definitions used by a computational chemist. Notations in the module
could be shortened by adding alias names for objects, not by defining the
objects using sort cryptic names. This approach preserves the general
readability of a module, but still allows a shorter notation to be used by
the expert in the field.
Michael
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From tim@lassi.ece.uiuc.edu Wed Sep 4 16:17:16 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Wed, 4 Sep 1996 10:17:16 -0500
Subject: [PYTHON MATRIX-SIG] Default Axes revisited
In-Reply-To: <9609041313.AA28790@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609041514.LAA29792@python.org>
>I like this basic idea, but as usual I'm having some problems with the
>details (and therein lies the devil)...
Ouch! A beautiful proposal marred by an ugly fact ;)
>Current situation:
>
>There is a package called Numeric Python.
>
>If you do import Numeric, you get all of the functions in that package.
>
>This includes many functions which are axis independent:
> sin, choose, zeros, greater, arrayrange, ...
>
>Some which are structural:
> take, repeat, ...
>
>Some which are numeric (well sort of):
> sort, argmax, ...
>
>
>I assume that the new proposal would be to put all of these in seperate
>modules? What would you name these three modules (or would you combine
>some of them together?)
If it were up to me, I would probably lump the numeric and indepenant
functions together. If there were two modules, Numerical and
Structural, it could be aranged so that "import Numeric" grabs them
both. So, if Numeric.py was just "import Structural, Numerical". Then
"from Numeric import Structural, Numerical" would be nice and clear.
>My other major concern is extensibility.
>
>fft will not come in the basic package of functions.
>
>Neither will inverse, svd, or others.
>
>These will all come in seperate modules with their own unique names. I
>myself have a module for speech recognition that has both structural
>(framing operations) and numeric (mfcc's) functions in it. Would you
>suggest that this be broken up into two modules?
Two ideas come to mind. One is to (please don't hit me ;) use both
methods. For large packages where the gain in elegance/esthetics is
worth the trouble, use the module naming convention
(Structural.concatenate, etc), while for smaller projects where it
just isn't worth the time and effort to maintain multiple modules, use
the underscore naming convention.
As an example, condsider the current Numeric module. For starters, let
rename the current module Numeric_raw. And in Numeric_raw, we name all
the functions according to the underscore convention. Then we define
two modules Structural and Numerical which just are.
Structural.py:
import Numeric_raw
concatenate = Numeric_raw.concatenate_
take = Numeric_raw.take_
etc...
Numerical.py:
import Numeric_raw
sort = Numeric_raw.sort
multiply = Numeric_raw.multiply
etc...
This allows (fairly) simple migration from one naming scheme to the
other. Of course this still leaves the question of what to name modules
like Jim's speech recognition module if he decides to break it apart
(speech_struct, Struct_speech, erk! ugly!!).
The second idea is to add hooks in Structural and Numerical for the
standard non-standard functions. So, for example:
In Numerical:
try: from fftpack import fft
except: pass
In fact (watch out! I'm on a roll!;) one could even have a
Numerical_site.py which lists all the local Numeric extensions and
what functions are structural and which Numerical. Then Structural and
numerical could import Numerical_site and figure out what other files
to include. Of course this only is good for functions that make sense
in Numeric if they're around (fft). So maybe this isn't worth the
trouble.
That's enough rambling for now I think!
--
-tim
+--------------------------------------------------------------------+
| Tim Hochberg Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu University of Illinois |
| http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 |
+--------------------------------------------------------------------+
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From klm@CNRI.Reston.Va.US Wed Sep 4 16:46:06 1996
From: klm@CNRI.Reston.Va.US (Ken Manheimer)
Date: Wed, 4 Sep 1996 11:46:06 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Default Axes revisited
In-Reply-To: <199609041514.LAA29792@python.org>
Message-ID: <Pine.SOL.3.95.960904112650.21477V-100000@glyph>
On Wed, 4 Sep 1996 tim@lassi.ece.uiuc.edu wrote:
> Someone who is Not Attributed wrote:
> >I assume that the new proposal would be to put all of these in seperate
> >modules? What would you name these three modules (or would you combine
> >some of them together?)
>
> If it were up to me, I would probably lump the numeric and indepenant
> functions together. If there were two modules, Numerical and
> Structural, it could be aranged so that "import Numeric" grabs them
> both. So, if Numeric.py was just "import Structural, Numerical". Then
> "from Numeric import Structural, Numerical" would be nice and clear.
I'd like to point out that 'Structural' is too general a name to put in
the top-level Python module space. 'Structural' could refer to any
number of things - general datastructure mutators, building-architecture
utilities, post-neo-moderne-classical sculpture visualization tools, i
dunno. One option, which michael mclay mentioned, is to put the whole
shebang in a package, using 'ni'. I think this is just the sort of
thing for which ni is intended, particularly in guido's design.
If i was to do that, i'd look for short names for the submodules, eg
'Num', 'Struct', etc.
This whole idea presumes that it's a good idea to segregate the
structural and non-structural routines - i'm a non-matrix-savvy lurker,
not informed enough to have a clue on that...-) In particular, i don't
know whether you'd encounter problems segregating, eg, the contents of
an 'fft' module into the structural and non-structural categories.
...
Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268
(orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From dubois1@llnl.gov Wed Sep 4 21:35:53 1996
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Wed, 4 Sep 1996 13:35:53 -0700
Subject: [PYTHON MATRIX-SIG] Structural, etc.
Message-ID: <9609042056.AA15218@icf.llnl.gov.llnl.gov>
I think this whole discussion has been a hammer meant to kill an ant. There
isn't really any serious
problem to be solved here. Apparently some facilities in the Numeric module
have a different
set of operating procedures than others-- not surprising. Aha, good luck,
we can even categorize
them into two distinct (so far!) cases. Great. So in the documentation put
two sections
explaining the two cases and documenting the corresponding functions.
If you imagine that the third or fourth "case" comes up, the proposed
solution becomes absurd.
import Numerical
import Structural
import Gzenoidal
import FFT_Numerical
import FFT_Structural
import FFT_Gzenoidal
import LAPACK_Numerical
...
etc.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Thu Sep 5 02:40:21 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 4 Sep 1996 21:40:21 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] pickling...
Message-ID: <199609050140.VAA27265@maigret>
I seem to be pickling and restoring well using DumpArray and LoadArray.
I guess all that's missing is the pickle glue. I can live without for
now.
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Thu Sep 5 02:34:48 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 4 Sep 1996 21:34:48 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] pickling...
Message-ID: <199609050134.VAA25964@maigret>
My latest version of Numeric.py refers to "my version of pickle", I
assume jjh's. Is that available?
--da
=================
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 Thu Sep 5 09:38:39 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 5 Sep 96 09:38:39 +0100
Subject: [PYTHON MATRIX-SIG] Structural, etc.
In-Reply-To: <9609042056.AA15218@icf.llnl.gov.llnl.gov> (dubois1@llnl.gov)
Message-ID: <199609050741.JAA06612@ibs.ibs.fr>
> If you imagine that the third or fourth "case" comes up, the proposed
> solution becomes absurd.
> import Numerical
> import Structural
> import Gzenoidal
> import FFT_Numerical
> import FFT_Structural
> import FFT_Gzenoidal
> import LAPACK_Numerical
> ...
> etc.
I agree completely. Even worse, it's probably going to be
from Numerical import *
from Structural import *
from Gzenoidal import *
from FFT_Numerical import *
from FFT_Structural import *
from FFT_Gzenoidal import *
from LAPACK_Numerical import *
...
And that, at least for the reader, totally annihilates the "helpful"
distinction between the different types of functions. The underscore
solution, however esthetically unpleasing, is more useful and easier
to apply in practice.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 barrett@compass.gsfc.nasa.gov Thu Sep 5 14:01:47 1996
From: barrett@compass.gsfc.nasa.gov (Paul Barrett)
Date: Thu, 5 Sep 1996 09:01:47 -0400
Subject: [PYTHON MATRIX-SIG] Structural, etc.
Message-ID: <199609051301.JAA00210@compass.gsfc.nasa.gov>
> If you imagine that the third or fourth "case" comes up, the proposed
> solution becomes absurd.
> import Numerical
> import Structural
> import Gzenoidal
> import FFT_Numerical
> import FFT_Structural
> import FFT_Gzenoidal
> import LAPACK_Numerical
> ...
> etc.
Well, it doesn't become absurd, just annoying.
Many of us may prefer to use ours or others Numerical packages instead
of the Numerical Python default, resulting in the inclusion of similar
Python code anyway in order to differentiation between the two
implementations.
An example is the FFT, discussion so far has assumed 1-D FFTs, but a
general FFT algorithm would be multi-dimensional. This would be
faster in the long run, especially for someone that wanted such
behaviour. To get this I will have to write my own and explicitly
including it everytime in my code.
I like to know and would like others to know explicitly which
algorithm and implementation of code that I am using. The above few
lines does that. We are talking precision here, so let's please be
precise.
-- Paul
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Paul Barrett - Astrophysicist - Universities Space Research Association |
| Compton Observatory Science Support Center |
| NASA/Goddard SFC phone: 301-286-1108 "Guk a 'mzimba, sala 'nhliziyo" |
| Code 660.1, FAX: 301-286-1681 (body grow old, but heart |
| Greenbelt,MD 20771 barrett@compass.gsfc.nasa.gov remain behind) |
| http://lheawww.gsfc.nasa.gov/users/barrett/CV.html |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From phil@geog.ubc.ca Thu Sep 5 20:24:20 1996
From: phil@geog.ubc.ca (Phil Austin)
Date: Thu, 5 Sep 1996 12:24:20 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] Integrated Simulation Environment?
In-Reply-To: <199609031730.TAA29024@ibs.ibs.fr>
References: <199609022054.QAA04261@maigret>
<199609031730.TAA29024@ibs.ibs.fr>
Message-ID: <199609051924.MAA27647@coot.geog.ubc.ca>
>>>>> "Konrad" == Konrad Hinsen <hinsen@ibs.ibs.fr> writes:
Konrad> My personal solution is to use Emacs as my work
Konrad> environment. This makes typing into a (permanent) file and
Konrad> executing from it easy enough that the lack of real
Konrad> interactivity hardly matters. What I would like to have is
Konrad> a key combination that kills the Python buffer and starts
Konrad> a fresh session with the current buffer as input, but that
Konrad> shouldn't be too hard...
Python users who know some elisp might want to look at modifying a
very comprehensive Splus emacs mode that allows multiple interpreter
sessions, formats functions, parses errors and sends you to the
correct line, etc.
The current version with texinfo documentation is at:
ftp://wingra.stat.wisc.edu/pub/src/emacs-lisp/S-mode-4.8.tar.gz
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Thu Sep 5 22:46:15 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 5 Sep 1996 17:46:15 -0400
Subject: [PYTHON MATRIX-SIG] More naming/module issues
Message-ID: <9609052143.AA20877@goldilocks.LCS.MIT.EDU>
First, let me say that I've become convinced that the Numerical/Structural
module system is out of control (thanks for the touch of sanity Paul).
There will continue to be a module named Numeric which will contain all the
basic functions (both numeric and structural).
Now I'm working out the standard library. My questions is: How many
modules should I make and what should they be called?
Solutions:
1) Add it all to Numeric.py (at least in appearance):
Numeric.inverse(matrix), Numeric.fft(waveform), Numeric.random(100)
2) Add it to a single library module:
NumLib.inverse(matrix), NumLib.fft(waveform), NumLib.random(100)
3) Add them to seperate modules:
Lapack.inverse(matrix), Fftpack.fft(waveform), Ranlib.random(100)
Does anybody have any comments on these various choices or the specific
names I'm using? If there are no strong sentiments expressed I'll probably
go with the third option and the names as shown.
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Thu Sep 5 22:54:10 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 5 Sep 1996 17:54:10 -0400
Subject: [PYTHON MATRIX-SIG] 2D fft
Message-ID: <9609052151.AA20970@goldilocks.LCS.MIT.EDU>
I've been looking into providing a 2d fft routine in the standard library
and noticed that matlab uses the following to get a 2d fft given a 1d fft
routine (with broadcasting). Does anybody who knows more about this care
to comment (horribly inaccurate/inefficient)? Otherwise I'll use roughly
this code in the standard library:
def fft2d(x):
return fft(fft(x, axis=-1), axis=-2)
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Thu Sep 5 22:54:10 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 5 Sep 1996 17:54:10 -0400
Subject: [PYTHON MATRIX-SIG] 2D fft
Message-ID: <9609052151.AA20970@goldilocks.LCS.MIT.EDU>
I've been looking into providing a 2d fft routine in the standard library
and noticed that matlab uses the following to get a 2d fft given a 1d fft
routine (with broadcasting). Does anybody who knows more about this care
to comment (horribly inaccurate/inefficient)? Otherwise I'll use roughly
this code in the standard library:
def fft2d(x):
return fft(fft(x, axis=-1), axis=-2)
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From jac@gandalf.llnl.gov Thu Sep 5 23:32:04 1996
From: jac@gandalf.llnl.gov (James Crotinger)
Date: Thu, 5 Sep 96 15:32:04 PDT
Subject: [PYTHON MATRIX-SIG] 2D fft
In-Reply-To: <9609052151.AA20970@goldilocks.LCS.MIT.EDU>
References: <9609052151.AA20970@goldilocks.LCS.MIT.EDU>
Message-ID: <9609052232.AA15912@gandalf.llnl.gov>
Jim Hugunin writes:
>
> I've been looking into providing a 2d fft routine in the standard library
> and noticed that matlab uses the following to get a 2d fft given a 1d fft
> routine (with broadcasting). Does anybody who knows more about this care
> to comment (horribly inaccurate/inefficient)? Otherwise I'll use roughly
> this code in the standard library:
>
> def fft2d(x):
> return fft(fft(x, axis=-1), axis=-2)
>
Correct - the 2D fft kernal is just the product of the 1D kernals
because exp(a x + b y) = exp(a x) * exp(b y).
However, doing this in the above manner is not necessarily the most
efficient. Most multidimensional FFT routines put the innermost loop
over the number of vectors being transformed. This is done because the
1D fft algorithm has a rather complicated memory access pattern, and,
at least on vector machines, you get a huge speedup by vectorizing in
the other direction(s). On RISC workstations things are considerably
less clear, depending on cache size versus problem size, etc.
Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Thu Sep 5 23:48:39 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Thu, 5 Sep 1996 18:48:39 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] 2D fft
In-Reply-To: <9609052232.AA15912@gandalf.llnl.gov> from "James Crotinger" at Sep 5, 96 03:32:04 pm
Message-ID: <199609052248.SAA04068@maigret>
> > I've been looking into providing a 2d fft routine in the standard library
> > and noticed that matlab uses the following to get a 2d fft given a 1d fft
> > routine (with broadcasting). Does anybody who knows more about this care
> > to comment (horribly inaccurate/inefficient)? Otherwise I'll use roughly
> > this code in the standard library:
> >
> > def fft2d(x):
> > return fft(fft(x, axis=-1), axis=-2)
> >
>
> Correct - the 2D fft kernal is just the product of the 1D kernals
> because exp(a x + b y) = exp(a x) * exp(b y).
>
> However, doing this in the above manner is not necessarily the most
> efficient. Most multidimensional FFT routines put the innermost loop
> over the number of vectors being transformed. This is done because the
> 1D fft algorithm has a rather complicated memory access pattern, and,
> at least on vector machines, you get a huge speedup by vectorizing in
> the other direction(s). On RISC workstations things are considerably
> less clear, depending on cache size versus problem size, etc.
Right. However I'd say that the first goal is to have *an* fft out the
door soon, and the standard way would do for 90% of users. Then, if
someone wants to incorporate a very fancy fft (which special cases
on multiples of 2, architecture, etc. etc.), then it could just be a
drop in replacement).
--da
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From cgw@pgt.com Fri Sep 6 00:00:49 1996
From: cgw@pgt.com (Charles G Waldman)
Date: Thu, 05 Sep 1996 19:00:49 -0400
Subject: [PYTHON MATRIX-SIG] Two things
In-Reply-To: Your message of "Thu, 05 Sep 1996 17:46:15 EDT."
<9609052143.AA20877@goldilocks.LCS.MIT.EDU>
Message-ID: <9609052300.AA15068@reactor.pgt>
Jim Hugunin wrote:
>First, let me say that I've become convinced that the Numerical/Structural
>module system is out of control (thanks for the touch of sanity Paul).
Well, I initially thought it was a nice idea, but I can see why there are
problems with it. I concede on this issue.
>def fft2d(x):
> return fft(fft(x, axis=-1), axis=-2)
>Does anybody who knows more about this care
>to comment (horribly inaccurate/inefficient)?
I've spent a bunch of time optimizing 2D FFT's for image processing
applications. The above code is not terrible, but I would like to
offer a few comments.
First of all, I don't think it will give the traditional normalization.
(See, for example, Gonzalez&Wintz, "Digital Image Processing", Addison-Wesley,
1977, page 45)
Secondly, it won't be the fastest thing in the world, particulary on large
arrays - the efficient way is to take a 1d FFT of each row in a given array,
then transpose the array, then do FFT's again down each row - this eliminates
a lot of page-faults which you get when doing FFT's down the columns. (There
is an efficient recursive algorithm for matrix transpose.) Then of course
you have to transpose again. But in my experience, the two transposes
are faster than all the column-wise accesses - - remember that in an FFT
you're not always just handling adjacent elements.
I have some C code I could contribute if you're interested - don't know how
well it would integrate into the FFT code you already have, but I'll send it
along to you if you want.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From Rob.Hooft@embl-heidelberg.de Fri Sep 6 00:11:45 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Fri, 6 Sep 1996 01:11:45 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] 2D fft
In-Reply-To: <9609052232.AA15912@gandalf.llnl.gov>
References: <9609052151.AA20970@goldilocks.LCS.MIT.EDU>
<9609052232.AA15912@gandalf.llnl.gov>
Message-ID: <199609052311.BAA12507@nu>
>>>>> "JH" == Jim Hugunin writes:
JH> def fft2d(x):
JH> return fft(fft(x, axis=-1), axis=-2)
>>>>> "JC" == James Crotinger <jac@gandalf.llnl.gov> writes:
JC> However, doing this in the above manner is not necessarily the
JC> most efficient. Most multidimensional FFT routines put the
JC> innermost loop over the number of vectors being transformed.
If the direction appears to make a big difference, you could put a
number of "physical transposes" in there to try and make it faster.
Rob.
--
=== Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux! Free Software Rules The World! =============
=================
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 Sep 6 09:37:27 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 6 Sep 96 09:37:27 +0100
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <9609052143.AA20877@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609060740.JAA12748@ibs.ibs.fr>
> Now I'm working out the standard library. My questions is: How many
> modules should I make and what should they be called?
My preference is:
> 3) Add them to seperate modules:
> Lapack.inverse(matrix), Fftpack.fft(waveform), Ranlib.random(100)
However, I'd prefer other names for the modules, and maybe also a
somewhat wider scope. For example, I'd like to have one module for
linear algebra. The standard version would contain the LAPACK
interface, but conceivable someone else could write a compatible
version using a special Cray library or whatever. There could also be
other functions (added later) that are not part of LAPACK. Therefore
the module should not be *called* LAPACK, but LinearAlgebra.
As for FFT, I'd propose to make it part of a general library for
dealing with signal procession. It could later contain other
transforms (Laplace, wavelet, etc.) and whatever else people need in
this business. Again, the module should not be named after the
package it is initially based on.
Konrad
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 mclay@eeel.nist.gov Fri Sep 6 10:03:47 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Fri, 6 Sep 1996 09:03:47 GMT
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <199609060740.JAA12748@ibs.ibs.fr>
References: <9609052143.AA20877@goldilocks.LCS.MIT.EDU>
<199609060740.JAA12748@ibs.ibs.fr>
Message-ID: <199609060903.JAA13261@fermi.eeel.nist.gov>
Konrad Hinsen writes:
> > Now I'm working out the standard library. My questions is: How many
> > modules should I make and what should they be called?
>
> My preference is:
>
> > 3) Add them to seperate modules:
> > Lapack.inverse(matrix), Fftpack.fft(waveform), Ranlib.random(100)
>
> However, I'd prefer other names for the modules, and maybe also a
> somewhat wider scope. For example, I'd like to have one module for
> linear algebra. The standard version would contain the LAPACK
> interface, but conceivable someone else could write a compatible
> version using a special Cray library or whatever. There could also be
> other functions (added later) that are not part of LAPACK. Therefore
> the module should not be *called* LAPACK, but LinearAlgebra.
I agree that new names should be used. I propose the following convention
be followed so the library that is created makes it easy to find
general resources, but still retain the ease of use of short hand
notations.
The names selected for modules,classes, and functions should be
spelled out in full for a general package called Numeric.
Numeric.LinearAlgebra
Numeric.FourierTransform
Numeric.RandomNumbers
I dropped the term Fast from FourierTransform because it seems obvious
that you would want to do it fast and I don't recall ever hearing
about anyone using something other than an FFT. The nature of the
algorithm used could be incorporated into a docstring, rather than
encoded in the name.
Each discipline can now import the fully spelled out name and
shorten it so it fits the conventional notation for that industry.
For instance ComputationalChemistry.fft module might contain the line:
from Numeric.FourierTransform import *
fft = FourierTransform
fft2d = FourierTransform2D
This notation will make it easier for new users to grasp the
organization of the language and the library. Using names like LAPACK
is not intuitive to a new student. It will become even less intuitive
as high level language take over in the role of teaching linear
algebra.
Michael
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Fri Sep 6 16:43:22 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 6 Sep 1996 11:43:22 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <199609060903.JAA13261@fermi.eeel.nist.gov> from "Michael McLay" at Sep 6, 96 09:03:47 am
Message-ID: <199609061543.LAA08790@maigret>
> The names selected for modules,classes, and functions should be
> spelled out in full for a general package called Numeric.
>
> Numeric.LinearAlgebra
> Numeric.FourierTransform
> Numeric.RandomNumbers
>
> I dropped the term Fast from FourierTransform because it seems obvious
> that you would want to do it fast and I don't recall ever hearing
> about anyone using something other than an FFT. The nature of the
> algorithm used could be incorporated into a docstring, rather than
> encoded in the name.
I agree with the package idea, but I think that Konrad's point about
signal processing is good as well.
Numeric.SignalProcessing instead of Numeric.FourierTransform.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From dubois1@llnl.gov Fri Sep 6 17:29:43 1996
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 6 Sep 1996 09:29:43 -0700
Subject: [PYTHON MATRIX-SIG] More naming/module issues
Message-ID: <9609061628.AA22176@icf.llnl.gov.llnl.gov>
As usual, let me be different.
As elegant as it sounds, Numeric.LinearAlgebra is redundant. There is no
un-Numeric LinearAlgebra unless Python suddenly supports symbolic
computation.
LAPACK represents a certain quality assurance for me. When choosing a
routine from a module called LAPACK, I know I'm getting the right answer.
If other
stuff is mixed in, maybe I'm getting a FastButWrong amateur effort.
On the other hand, I see the virtue of having a tree-like path to find
stuff in that great big catalog of the future. Say,
LinearAlgebra.LAPACK
LinearAlgebra.NAG
LinearAlgebra.Sparselib
FFT.FFTPACK
FFT.IMSL
FFT.NAG
I don't understand the implications of the package nesting, however. One
wouldn't want to load all of the LinearAlgebra children just because you
wanted one of them.
----------
> From: Michael McLay <mclay@eeel.nist.gov>
> To: matrix-sig@python.org
> Subject: Re: [PYTHON MATRIX-SIG] More naming/module issues
> Date: Friday, September 06, 1996 2:03 AM
>
> Konrad Hinsen writes:
> > > Now I'm working out the standard library. My questions is: How many
> > > modules should I make and what should they be called?
> >
> > My preference is:
> >
> > > 3) Add them to seperate modules:
> > > Lapack.inverse(matrix), Fftpack.fft(waveform), Ranlib.random(100)
> >
> > However, I'd prefer other names for the modules, and maybe also a
> > somewhat wider scope. For example, I'd like to have one module for
> > linear algebra. The standard version would contain the LAPACK
> > interface, but conceivable someone else could write a compatible
> > version using a special Cray library or whatever. There could also be
> > other functions (added later) that are not part of LAPACK. Therefore
> > the module should not be *called* LAPACK, but LinearAlgebra.
>
> I agree that new names should be used. I propose the following
convention
> be followed so the library that is created makes it easy to find
> general resources, but still retain the ease of use of short hand
> notations.
>
> The names selected for modules,classes, and functions should be
> spelled out in full for a general package called Numeric.
>
> Numeric.LinearAlgebra
> Numeric.FourierTransform
> Numeric.RandomNumbers
>
> I dropped the term Fast from FourierTransform because it seems obvious
> that you would want to do it fast and I don't recall ever hearing
> about anyone using something other than an FFT. The nature of the
> algorithm used could be incorporated into a docstring, rather than
> encoded in the name.
>
> Each discipline can now import the fully spelled out name and
> shorten it so it fits the conventional notation for that industry.
> For instance ComputationalChemistry.fft module might contain the line:
>
> from Numeric.FourierTransform import *
> fft = FourierTransform
> fft2d = FourierTransform2D
>
> This notation will make it easier for new users to grasp the
> organization of the language and the library. Using names like LAPACK
> is not intuitive to a new student. It will become even less intuitive
> as high level language take over in the role of teaching linear
> algebra.
>
>
> Michael
>
> =================
> 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 guido@CNRI.Reston.Va.US Fri Sep 6 17:43:58 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Fri, 06 Sep 1996 12:43:58 -0400
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: Your message of "Fri, 06 Sep 1996 09:29:43 PDT."
<9609061628.AA22176@icf.llnl.gov.llnl.gov>
References: <9609061628.AA22176@icf.llnl.gov.llnl.gov>
Message-ID: <199609061643.MAA03606@monty.CNRI.Reston.Va.US>
> I don't understand the implications of the package nesting, however. One
> wouldn't want to load all of the LinearAlgebra children just because you
> wanted one of them.
And you don't get them. If your code says
import FFT.NAG
then FFT.FFTPACK and others are not loaded. So this sounds about right.
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From jac@gandalf.llnl.gov Fri Sep 6 17:53:58 1996
From: jac@gandalf.llnl.gov (James Crotinger)
Date: Fri, 6 Sep 96 09:53:58 PDT
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <199609061543.LAA08790@maigret>
References: <199609060903.JAA13261@fermi.eeel.nist.gov>
<199609061543.LAA08790@maigret>
Message-ID: <9609061653.AA17449@gandalf.llnl.gov>
David Ascher writes:
> > The names selected for modules,classes, and functions should be
> > spelled out in full for a general package called Numeric.
> >
> > Numeric.LinearAlgebra
> > Numeric.FourierTransform
> > Numeric.RandomNumbers
> >
> > I dropped the term Fast from FourierTransform because it seems obvious
> > that you would want to do it fast and I don't recall ever hearing
> > about anyone using something other than an FFT. The nature of the
> > algorithm used could be incorporated into a docstring, rather than
> > encoded in the name.
>
> I agree with the package idea, but I think that Konrad's point about
> signal processing is good as well.
>
> Numeric.SignalProcessing instead of Numeric.FourierTransform.
>
Except that FFT's are used for a lot more than just signal processing.
Also, "Fourier Transform" usually refers to the continuous
transform. The FFT is an algorithm for efficiently performing the
Discrete Fourier Transform. It is so commonly used that I'd
just call it FFT.
Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From pas@lems.brown.edu Fri Sep 6 18:07:11 1996
From: pas@lems.brown.edu (Perry A. Stoll)
Date: Fri, 6 Sep 1996 13:07:11 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <199609061543.LAA08790@maigret>
Message-ID: <Pine.SUN.3.91.960906123858.22933B-100000@lems61>
On Fri, 6 Sep 1996, David Ascher wrote:
> > The names selected for modules,classes, and functions should be
> > spelled out in full for a general package called Numeric.
> >
> > Numeric.LinearAlgebra
> > Numeric.FourierTransform
> > Numeric.RandomNumbers
> >
> > I dropped the term Fast from FourierTransform because it seems obvious
> > that you would want to do it fast and I don't recall ever hearing
> > about anyone using something other than an FFT. The nature of the
> > algorithm used could be incorporated into a docstring, rather than
> > encoded in the name.
FFT deserves it's own function name, perhaps in the SignalProcessing
module. Try telling an engineer that the designers of PyNumeric decided
that the user has no control over which algorithm is used to implement the
discrete Fourier transform.
>
> I agree with the package idea, but I think that Konrad's point about
> signal processing is good as well.
>
> Numeric.SignalProcessing instead of Numeric.FourierTransform.
Is everything going to hang off the name Numeric?
Numeric.SignalProcessing.Transforms.Fourier.FFT()
Numeric.SignalProcessing.FilterDesign.Analog.Bessel.create_filter()
Numeric.PDE.Solvers.Upwind.FluxLimiter.Godunov()
It's consistent, but it may be a maze to navigate.
-Perry
<pas@lems.brown.edu>
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From mclay@eeel.nist.gov Fri Sep 6 13:29:31 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Fri, 6 Sep 1996 12:29:31 GMT
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <9609061628.AA22176@icf.llnl.gov.llnl.gov>
References: <9609061628.AA22176@icf.llnl.gov.llnl.gov>
Message-ID: <199609061229.MAA00509@fermi.eeel.nist.gov>
Paul F. Dubois writes:
> As usual, let me be different.
>
> As elegant as it sounds, Numeric.LinearAlgebra is redundant. There is no
> un-Numeric LinearAlgebra unless Python suddenly supports symbolic
> computation.
> LAPACK represents a certain quality assurance for me. When choosing a
> routine from a module called LAPACK, I know I'm getting the right answer.
> If other
> stuff is mixed in, maybe I'm getting a FastButWrong amateur effort.
>
> On the other hand, I see the virtue of having a tree-like path to find
> stuff in that great big catalog of the future. Say,
> LinearAlgebra.LAPACK
> LinearAlgebra.NAG
> LinearAlgebra.Sparselib
> FFT.FFTPACK
> FFT.IMSL
> FFT.NAG
>
> I don't understand the implications of the package nesting, however. One
> wouldn't want to load all of the LinearAlgebra children just because you
> wanted one of them.
It can be structured to only load what you ask to have loaded. The
nesting is just a convenient mechansim for nesting the modules in
subdirectories. This means that everything that eventually will be
included in the huge and wonderful Numeric library can fit into just
one name in the list of modules in sys.path. This technique will
actually make it easier to chop the library up into very fine pieces.
The trade-off is that you have to stick the code into a bunch of
smaller files and you end up opening up one file for each of the
mini-size module that are imported. The organization gained by this
approach should outweigh the miliseconds that will be added at
application startup time.
Michael
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From klm@CNRI.Reston.Va.US Fri Sep 6 18:36:29 1996
From: klm@CNRI.Reston.Va.US (Ken Manheimer)
Date: Fri, 6 Sep 1996 13:36:29 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <9609061628.AA22176@icf.llnl.gov.llnl.gov>
Message-ID: <Pine.SOL.3.95.960906130937.21477w-100000@glyph>
On Fri, 6 Sep 1996, Paul F. Dubois wrote:
> As elegant as it sounds, Numeric.LinearAlgebra is redundant. There is no
> un-Numeric LinearAlgebra unless Python suddenly supports symbolic
> computation.
"No one expects the spanish inquisition."
Python is suddenly supporting advance numeric computation, why shouldn't
it, eventually, suddenly support symbolic algebra? 'import
mathematicb.LinearAlgebra' (Mathematicb would be like mathematica, but
Better:-)
(I have to confess, i may be overly dedicated to tree-structuring the
Python modules namespace. I have the feeling, though, that it would be
much easier for everyone to get a handle on what's available if
fundamentally related stuff were collected together in packages. I'm
nearly sure we'd get fewer question in the newsgroup seeking cgi and
http tools if the web stuff were gathered together in a package.)
If that doesn't grab you, consider another benefit of the nesting -
someone looking for the numeric-related item, that they knew they'd seen
around, looks in the Numeric package for it, rather than having to
browse through the the entire collection of python packages.
> On the other hand, I see the virtue of having a tree-like path to find
> stuff in that great big catalog of the future. Say,
> LinearAlgebra.LAPACK
> LinearAlgebra.NAG
> LinearAlgebra.Sparselib
> FFT.FFTPACK
> FFT.IMSL
> FFT.NAG
Yes. I'd like to go the one step further, and put it all in Numeric.
And if you're concerned about seeing something like the following
crowding your code:
Numeric.LinearAlgebra.SparseLib.array((1, 1), (1e6, 2), (1e12, 3))
you could do:
from Numeric.LinearAlgebra import SparseLib
[...]
SparseLib.array((1, 1), (1e6, 2), (1e12, 3))
I believe this will work the current implementation of ni.
> I don't understand the implications of the package nesting, however. One
> wouldn't want to load all of the LinearAlgebra children just because you
> wanted one of them.
As guido indicated, only the specified components are loaded.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Fri Sep 6 18:46:36 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 6 Sep 1996 13:46:36 -0400
Subject: [PYTHON MATRIX-SIG] Re: Two things
Message-ID: <9609061743.AA01849@goldilocks.LCS.MIT.EDU>
> From: Charles G Waldman <cgw@pgt.com>
> I've spent a bunch of time optimizing 2D FFT's for image processing
> applications. The above code is not terrible, but I would like to
> offer a few comments.
>
> First of all, I don't think it will give the traditional normalization.
> (See, for example, Gonzalez&Wintz, "Digital Image Processing",
Addison-Wesley,
> 1977, page 45)
Could you give me the right function to normalize this with?
> Secondly, it won't be the fastest thing in the world, particulary on
large
> arrays - the efficient way is to take a 1d FFT of each row in a given
array,
> then transpose the array, then do FFT's again down each row - this
eliminates
> a lot of page-faults which you get when doing FFT's down the columns.
(There
> is an efficient recursive algorithm for matrix transpose.) Then of
course
> you have to transpose again. But in my experience, the two transposes
> are faster than all the column-wise accesses - - remember that in an FFT
> you're not always just handling adjacent elements.
This is in fact what will happen here. The fftpack code only works on
packed vectors, so the fft along the -2 axis will result in the two
expected transpositions. The transpositions will add a little extra python
overhead, but I'd bet this will be minimal.
> I have some C code I could contribute if you're interested - don't know
how
> well it would integrate into the FFT code you already have, but I'll send
it
> along to you if you want.
I really like the idea of using the standard fftpack code, so lets see how
well my version works for people. If there are many speed problems I might
take you up on this offer.
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From tim@lassi.ece.uiuc.edu Fri Sep 6 18:54:59 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Fri, 6 Sep 1996 12:54:59 -0500
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <9609061653.AA17449@gandalf.llnl.gov> (message from James
Crotinger on Fri, 6 Sep 96 09:53:58 PDT)
Message-ID: <199609061752.NAA06283@python.org>
James Crotinger <jac@gandalf.llnl.gov> writes:
> Except that FFT's are used for a lot more than just signal processing.
True - I can allready see this discussion wandering down the road of the last
few naming discussions....;)
> Also, "Fourier Transform" usually refers to the continuous
>transform. The FFT is an algorithm for efficiently performing the
>Discrete Fourier Transform. It is so commonly used that I'd
>just call it FFT.
Yeah, FFT is the name what gets used by matlab, for example. It's a
little bit of a misnomer, since FFT refers to a method of performing a
fast Discrete Fourier Transforms (DFTs) on a sequence of a certain
lengths. As I discovered when playing around with the (currently
missing) FFT module you can do FFT's of a kind on sequences with any
non-prime length - but if the length is prime your back to the vanilla
DFT algorithm. A more accurate name would be DFT, or
DFT_using_the_fastest_algorithm_we_can ( ;) ), but everyone else knows
this as FFT, so we might was well call it that too.
--
-tim
+--------------------------------------------------------------------+
| Tim Hochberg Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu University of Illinois |
| http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 |
+--------------------------------------------------------------------+
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From mclay@eeel.nist.gov Fri Sep 6 13:52:45 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Fri, 6 Sep 1996 12:52:45 GMT
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <9609061653.AA17449@gandalf.llnl.gov>
References: <199609060903.JAA13261@fermi.eeel.nist.gov>
<199609061543.LAA08790@maigret>
<9609061653.AA17449@gandalf.llnl.gov>
Message-ID: <199609061252.MAA00638@fermi.eeel.nist.gov>
James Crotinger writes:
> David Ascher writes:
> > > The names selected for modules,classes, and functions should be
> > > spelled out in full for a general package called Numeric.
> > >
> > > Numeric.LinearAlgebra
> > > Numeric.FourierTransform
> > > Numeric.RandomNumbers
> > >
> > > I dropped the term Fast from FourierTransform because it seems obvious
> > > that you would want to do it fast and I don't recall ever hearing
> > > about anyone using something other than an FFT. The nature of the
> > > algorithm used could be incorporated into a docstring, rather than
> > > encoded in the name.
> >
> > I agree with the package idea, but I think that Konrad's point about
> > signal processing is good as well.
> >
> > Numeric.SignalProcessing instead of Numeric.FourierTransform.
> >
>
> Except that FFT's are used for a lot more than just signal processing.
Yes, it's used in surface roughness calculations.
Of course you could have Numeric.SignalProcessing include the line:
from Numeric.FourierTransform import *
Now anyone who reads the Numeric.SignalProcessing will learn that it
uses the general purpose FourierTransform. Everyone can use their
own favorite name for the same object, but the obscure names can
be traced back to a sensible name.
> Also, "Fourier Transform" usually refers to the continuous
> transform. The FFT is an algorithm for efficiently performing the
> Discrete Fourier Transform. It is so commonly used that I'd
> just call it FFT.
Good point. I guess we need a DiscreteFourierTransform and a
ContinuousFourierTransform module. That capture more of the
algorithm's intent than the name FFT.
Thanks for helping demonstrate that historic names are often not
intuitive:-)
Now I do see a downside to this grand plan. It will make writing
browsers for the library a bit trickier and it adds an additional step
to the process of tracing back the meaning of a name. Is the improved
precision worth the added work?
Michael
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From barrett@compass.gsfc.nasa.gov Fri Sep 6 18:39:43 1996
From: barrett@compass.gsfc.nasa.gov (Paul Barrett)
Date: Fri, 6 Sep 1996 13:39:43 -0400
Subject: [PYTHON MATRIX-SIG] More naming/module issues
Message-ID: <199609061739.NAA00837@compass.gsfc.nasa.gov>
> The names selected for modules,classes, and functions should be
> spelled out in full for a general package called Numeric.
>
> Numeric.LinearAlgebra
> Numeric.FourierTransform
> Numeric.RandomNumbers
>
> I dropped the term Fast from FourierTransform because it seems obvious
> that you would want to do it fast and I don't recall ever hearing
> about anyone using something other than an FFT. The nature of the
> algorithm used could be incorporated into a docstring, rather than
> encoded in the name.
Well, there are people out there who do use transforms other than
FFTs, I being one. I use discrete Fourier Transforms all the time. In
fact I hardly ever use an FFT. My data is either unevenly sampled or
has data gaps. So my suggestion is 'Don't assume anything!'. This
goes back to my previous message of being precise and explicit.
Though it is not often noted, objected-oriented programming, in some
sense, allows and encourages explicit naming conventions. I therefore
suggest using Fast in the definition, if you mean a fast Fourier
Transform, alla the Cooley-Tukey algorithm.
-- Paul
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Paul Barrett - Astrophysicist - Universities Space Research Association |
| Compton Observatory Science Support Center |
| NASA/Goddard SFC phone: 301-286-1108 "Guk a 'mzimba, sala 'nhliziyo" |
| Code 660.1, FAX: 301-286-1681 (body grow old, but heart |
| Greenbelt,MD 20771 barrett@compass.gsfc.nasa.gov remain behind) |
| http://lheawww.gsfc.nasa.gov/users/barrett/CV.html |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Fri Sep 6 20:03:19 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 6 Sep 1996 15:03:19 -0400
Subject: [PYTHON MATRIX-SIG] Modules and Naming issues
Message-ID: <9609061900.AA02833@goldilocks.LCS.MIT.EDU>
Lots of good comments here, so I'll try and summarize a new position based
on them all:
Numeric should be a package. The top level of the package will have what
everyone is used to from import Numeric.
There will also be the following subpackages(?) in the base distribution:
Numeric.LinearAlgebra
Numeric.Random
Numeric.FFT
will all be in the basic distribution and will define the expected
functions. One nice thing about the package system is that I don't have to
worry about conflicts with builtin module names like random.py.
I have to admit that I don't consider Numeric.LinearAlgebra to be at all
redundant, one of these years I'm definately going to add symbolic math to
python if nobody beats me to it. I also don't see the need to say import
Numeric.LinearAlgebra.LAPACK, as Paul has said before (on other issues)
this sort of thing doesn't need a naming convention, just a note in the
documentation explaining that LAPACK is used for the underlying routines in
Numeric.LinearAlgebra.
My question for everyone is what should the reccommended usage of these
functions be?
I've finally gotten used to typing things like:
>>> Numeric.array([1,2,3], Numeric.Float32)
I can't imagine ever getting used to typing:
>>> Numeric.LinearAlgebra.inverse(a)
Is there something I'm missing here?
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From mclay@eeel.nist.gov Fri Sep 6 15:31:50 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Fri, 6 Sep 1996 14:31:50 GMT
Subject: [PYTHON MATRIX-SIG] Modules and Naming issues
In-Reply-To: <9609061900.AA02833@goldilocks.LCS.MIT.EDU>
References: <9609061900.AA02833@goldilocks.LCS.MIT.EDU>
Message-ID: <199609061431.OAA00971@fermi.eeel.nist.gov>
Jim Hugunin writes:
>
> My question for everyone is what should the reccommended usage of these
> functions be?
>
> I've finally gotten used to typing things like:
>
> >>> Numeric.array([1,2,3], Numeric.Float32)
>
> I can't imagine ever getting used to typing:
>
> >>> Numeric.LinearAlgebra.inverse(a)
>
> Is there something I'm missing here?
from Numeric import LinearAlgebra
and then if you want to save lots of typing add the line
LA = LinearAlgebra
LA.inverse(a)
or possibly
import Numeric.LinearAlgebra ; LA = Numeric.LinearAlgebra
While this notation will preserve unique within the module, it may get
messy if lots of modules are imported into a single file. It would be
helpful to have a consistent abbreviation convension. Maybe the
preferred abbreviation should be included in the docstring. While
this notation isn't idea it is better than having the standard useage
deteriorate to:
from Numeric import *
inverse(a)
Michael
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From guido@CNRI.Reston.Va.US Fri Sep 6 20:36:06 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Fri, 06 Sep 1996 15:36:06 -0400
Subject: [PYTHON MATRIX-SIG] Modules and Naming issues
In-Reply-To: Your message of "Fri, 06 Sep 1996 15:03:19 EDT."
<9609061900.AA02833@goldilocks.LCS.MIT.EDU>
References: <9609061900.AA02833@goldilocks.LCS.MIT.EDU>
Message-ID: <199609061936.PAA05006@monty>
> My question for everyone is what should the reccommended usage of these
> functions be?
>
> I've finally gotten used to typing things like:
>
> >>> Numeric.array([1,2,3], Numeric.Float32)
>
> I can't imagine ever getting used to typing:
>
> >>> Numeric.LinearAlgebra.inverse(a)
>
> Is there something I'm missing here?
The package system allows you to do a few things here:
>>> from Numeric import LinearAlgebra
>>> LinearAlgebra.inverse(a)
>>> from Numeric.LinearAlgebra import *
>>> inverse(a)
You could also abbrev LinearAlgebra to LA.
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From cgw@pgt.com Fri Sep 6 21:03:19 1996
From: cgw@pgt.com (Charles G Waldman)
Date: Fri, 06 Sep 1996 16:03:19 -0400
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: Your message of "Fri, 06 Sep 1996 12:52:45 GMT."
<199609061252.MAA00638@fermi.eeel.nist.gov>
Message-ID: <9609062003.AA25514@reactor.pgt>
mclay@eeel.nist.gov said:
> Good point. I guess we need a DiscreteFourierTransform and a
> ContinuousFourierTransform module. That capture more of the
> algorithm's intent than the name FFT.
Was this intended humorously?
What computer manipulations are *ever* continuous?? It's *all* discrete
once you leave the blackboard behind and start hacking code...
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From mclay@eeel.nist.gov Fri Sep 6 16:26:13 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Fri, 6 Sep 1996 15:26:13 GMT
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <9609062003.AA25514@reactor.pgt>
References: <199609061252.MAA00638@fermi.eeel.nist.gov>
<9609062003.AA25514@reactor.pgt>
Message-ID: <199609061526.PAA01068@fermi.eeel.nist.gov>
Charles G. Waldman writes:
>
> mclay@eeel.nist.gov said:
> > Good point. I guess we need a DiscreteFourierTransform and a
> > ContinuousFourierTransform module. That capture more of the
> > algorithm's intent than the name FFT.
>
> Was this intended humorously?
>
> What computer manipulations are *ever* continuous?? It's *all* discrete
> once you leave the blackboard behind and start hacking code...
I just got carried away:-) I think we are moving in a good
direction. The exact naming used for each domain will alway be a
subject for debate. It's just a classification system so it can't
really be right or wrong. My main goal in contributing to this
discussion was to get ni.py used to make it a package. I also want to
move the group towards using descriptive names instead of historical
names. You can always alias back to the historical names.
Michael
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From Rob.Hooft@embl-heidelberg.de Sat Sep 7 18:26:50 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Sat, 7 Sep 1996 19:26:50 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] 2 Bugs? and: Mandelbrot: another nice useless NumPy script?!
Message-ID: <199609071726.TAA18614@nu>
I guess a lot of you have seen the nice posting on c.l.python where
Guido explains the fact that "lambda" can be used to obfuscate python
code beyond belief. I decided to rewrite the mandelbrot script he
sent there. First I did it in plain python (will post to c.l.python
later). My unobfuscated version was about 2 times faster than the
original :-)
But: if one wants to make a really fast python script with vector
code: why not use Numeric python. The result (3 times faster than the
fastest plain python version I could get) is appended to this mail.
To make this message at least a bit useful: are the following two
problems (which I ran in to while coding this) effect of a known bug
in NumPy1.0a2?
Python 1.4b3 (Aug 31 1996) [GCC 2.7.2p snapshot 960816]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> z=array(6*[0j])
>>> z**2 # v v Why are these not zero?
(0.+0.j) (0.+0.j) (0.+0.j) (1.+0.j) (1.+0.j) (0.+0.j)
>>> `z`
"array([0j, 0j, 0j, 0j, 0j, 0j], 'D')"
>>> z=array(6*[0j],Complex)
>>> z
0. 0. 0. 0. 0. 0. ### <==== Hey, these are reals!!!!
>>> `z`
"array([0.0, 0.0, 0.0, 0.0, 0.0, 0.0], 'd')"
Regards,
Rob Hooft.
--------------------------------------------------------
#!/bin/env python
#
# Mandelbrot ASCII-art using Numeric Python 1.0alpha2
#
# Rob Hooft, 1996. Distribute freely.
from Numeric import *
def draw(LowX, HighX, LowY, HighY, stepx=80, stepy=24, maxiter=30):
xx=arange(LowX,HighX,(HighX-LowX)/stepx)
yy=arange(HighY,LowY,(LowY-HighY)/stepy)*1j
c=ravel(xx+yy[:,NewAxis])
z=zeros(c.shape,Complex)
output=resize(array(['_'],'c'),c.shape)
for iter in range(maxiter):
z=z*z+c
finished=greater(abs(z),2.0)
c=where(finished,0+0j,c)
z=where(finished,0+0j,z)
output=where(finished,chr(66+iter),output)
return add.reduce(output)
if __name__ == "__main__":
print draw(-2.1, 0.7, -1.2, 1.2)
--
=== Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux! Free Software Rules The World! =============
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Mon Sep 9 11:58:33 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 9 Sep 96 11:58:33 +0100
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <9609061628.AA22176@icf.llnl.gov.llnl.gov> (dubois1@llnl.gov)
Message-ID: <199609091000.MAA23821@ibs.ibs.fr>
> LAPACK represents a certain quality assurance for me. When choosing a
> routine from a module called LAPACK, I know I'm getting the right answer.
I wouldn't transfer this reputation to any module that calls itself
LAPACK. The interface might be buggy, and it might even do something
else entirely.
Of course users should know what routines a module is based on, but
that shouldn't be part of its name.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Mon Sep 9 12:00:15 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 9 Sep 96 12:00:15 +0100
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <199609061643.MAA03606@monty.CNRI.Reston.Va.US> (message from
Guido van Rossum on Fri, 06 Sep 1996 12:43:58 -0400)
Message-ID: <199609091002.MAA23833@ibs.ibs.fr>
> And you don't get them. If your code says
>
> import FFT.NAG
>
> then FFT.FFTPACK and others are not loaded. So this sounds about right.
It seems I have missed some important feature of Python. How can I get
the symbol "NAG" in module "FFT" assigned to a module without
writing "import NAG" inside FFT.py?
Konrad
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Mon Sep 9 12:04:36 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 9 Sep 96 12:04:36 +0100
Subject: [PYTHON MATRIX-SIG] Modules and Naming issues
In-Reply-To: <9609061900.AA02833@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609091007.MAA23870@ibs.ibs.fr>
> I have to admit that I don't consider Numeric.LinearAlgebra to be at all
> redundant, one of these years I'm definately going to add symbolic math to
> python if nobody beats me to it. I also don't see the need to say import
I have also played with this idea, but I'll probably never find the time
to do it :-(
> I can't imagine ever getting used to typing:
>
> >>> Numeric.LinearAlgebra.inverse(a)
I'd probably write
import Numeric.LinearAlgebra
LA = Numeric.LinearAlgebra
...
LA.inverse(a)
And I think this is clear enough even without a written convention
or recommendation.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 pas@lems.brown.edu Mon Sep 9 16:16:56 1996
From: pas@lems.brown.edu (Perry A. Stoll)
Date: Mon, 9 Sep 1996 11:16:56 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <199609091002.MAA23833@ibs.ibs.fr>
Message-ID: <Pine.SUN.3.91.960909111422.327A-100000@lems33>
On Mon, 9 Sep 1996, Konrad Hinsen wrote:
> > And you don't get them. If your code says
> >
> > import FFT.NAG
> >
> > then FFT.FFTPACK and others are not loaded. So this sounds about right.
>
> It seems I have missed some important feature of Python. How can I get
> the symbol "NAG" in module "FFT" assigned to a module without
> writing "import NAG" inside FFT.py?
>
> Konrad
You can't do it by importing the "module" FFT, but the FFT "package"
should do just fine. It's a nice feature - you should definitely find out
about it. There is documentation on packages at the head of the file ni.py
in the standard distribution.
-Perry
<pas@lems.brown.edu>
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Mon Sep 9 17:15:53 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 9 Sep 1996 12:15:53 -0400
Subject: [PYTHON MATRIX-SIG] 2 Bugs? and: Mandelbrot: another nice useless NumPy script?!
Message-ID: <9609091612.AA29739@goldilocks.LCS.MIT.EDU>
> To make this message at least a bit useful: are the following two
> problems (which I ran in to while coding this) effect of a known bug
> in NumPy1.0a2?
I don't know if thy're a known bug, but I don't get them under alpha3, so
as usual, wait for the next release and let me know if you still have the
problem.
Thanks for the example - Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Mon Sep 9 17:39:08 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 9 Sep 96 17:39:08 +0100
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <Pine.SUN.3.91.960909111422.327A-100000@lems33>
(pas@lems.brown.edu)
Message-ID: <199609091542.RAA26289@ibs.ibs.fr>
> You can't do it by importing the "module" FFT, but the FFT "package"
> should do just fine. It's a nice feature - you should definitely find out
> about it. There is documentation on packages at the head of the file ni.py
> in the standard distribution.
I just looked at it. It's nice, but I don't quite like the way it is
implemented (although there is probably no other way). I don't want to
explain to everyone reading my code that "import ni" doesn't really
import anything, but changes the way the following imports are
treated! Some more tricks like that and we are back to C-style coding
with ingenious preprocessor tricks.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 tom.schwaller@linux-magazin.de Mon Sep 9 18:12:37 1996
From: tom.schwaller@linux-magazin.de (Tom Schwaller)
Date: Mon, 09 Sep 1996 19:12:37 +0200
Subject: [PYTHON MATRIX-SIG] Re: Mandelbrot: another nice useless NumPy script?!
References: <9609091612.AA29739@goldilocks.LCS.MIT.EDU>
Message-ID: <32345005.1E4E81F1@linux-magazin.de>
I discovered a very strange behaviour in the Mandelbrot example.
On my Linux box,
uname -a
Linux 1.99.4 #8-pre-2.0 Wed Aug 21 12:52:32 MET DST 1996 i586
When I do:
print draw(-2.1, 0.7, -1.2, 1.2)
print draw(-2.1, 0.7, -1.2, 1.2)
print draw(-2.1, 0.7, -1.2, 1.2)
print draw(-2.1, 0.7, -1.2, 1.2)
the Python interpreter crahes!!! After the 4th call of print draw,
the third cal is still ok.
Can anybody reproduce this on another machine?
Tom
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From Rob.Hooft@embl-heidelberg.de Mon Sep 9 18:59:18 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Mon, 9 Sep 1996 19:59:18 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] Re: Mandelbrot: another nice useless NumPy script?!
In-Reply-To: <32345005.1E4E81F1@linux-magazin.de>
References: <9609091612.AA29739@goldilocks.LCS.MIT.EDU>
<32345005.1E4E81F1@linux-magazin.de>
Message-ID: <199609091759.TAA14481@nu>
>>>>> "TS" == Tom Schwaller <tom.schwaller@linux-magazin.de> writes:
TS> the Python interpreter crahes!!! After the 4th call of print
TS> draw, the third cal is still ok.
Hm, I just tried it on my ALPHA, and there it crashes already on the
second call. Looks like a jump/call to a weird address:
>>> print draw(-2.1, 0.7, -1.2, 1.2)
inst fault=opdec pid=18396 <python> pc=0x14005bb64 ps=0x8 inst=0x1
signal Illegal instruction at >*[., 0x14005bb68] op10.3e r0, 0x2e, r0
(dbx) where
0 (noname)() [0x14005bb64]
Rob.
--
=== Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux! Free Software Rules The World! =============
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From guido@CNRI.Reston.Va.US Mon Sep 9 19:14:33 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Mon, 09 Sep 1996 14:14:33 -0400
Subject: [PYTHON MATRIX-SIG] Re: Mandelbrot: another nice useless NumPy script?!
In-Reply-To: Your message of "Mon, 09 Sep 1996 19:12:37 +0200."
<32345005.1E4E81F1@linux-magazin.de>
References: <9609091612.AA29739@goldilocks.LCS.MIT.EDU>
<32345005.1E4E81F1@linux-magazin.de>
Message-ID: <199609091814.OAA13103@monty>
> When I do:
>
> print draw(-2.1, 0.7, -1.2, 1.2)
> print draw(-2.1, 0.7, -1.2, 1.2)
> print draw(-2.1, 0.7, -1.2, 1.2)
> print draw(-2.1, 0.7, -1.2, 1.2)
>
> the Python interpreter crahes!!! After the 4th call of print draw,
> the third cal is still ok.
Probably a reference counting bug (missing Py_INCREF()). Probably
somewhere in the numerics code. Probably fixed by Jim H. by the time
you read this.
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Mon Sep 9 19:27:45 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 9 Sep 1996 14:27:45 -0400
Subject: [PYTHON MATRIX-SIG] Re: Mandelbrot: another nice useless NumPy script?!
Message-ID: <9609091824.AA01654@goldilocks.LCS.MIT.EDU>
> TS> the Python interpreter crahes!!! After the 4th call of print
> TS> draw, the third cal is still ok.
>
> Hm, I just tried it on my ALPHA, and there it crashes already on the
> second call. Looks like a jump/call to a weird address:
This problem doesn't show up under my NT, Solaris or sunos versions of
alpha3. Hopefully this too is an already fixed bug. I'm working on
getting that alpha3 release out ASAP.
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Mon Sep 9 20:49:56 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 9 Sep 1996 15:49:56 -0400
Subject: [PYTHON MATRIX-SIG] Using Packages for Numeric Python
Message-ID: <9609091947.AA02705@goldilocks.LCS.MIT.EDU>
I'm now "packaging" up NumPy for the next alpha release. I have the
following structure:
Directory is called Numeric.
The "Standard" Numeric Library is contained in the following modules:
LinearAlgebra.py
Random.py
FFT.py
So you have Numeric.LinearAlgebra.inverse(m) which looks good to me.
What should I now call the module that used to be known as Numeric? This
is the module that contains all of the "core" functionality of the
extension.
import Numeric.Numeric seems kind of broken to me.
from Numeric import Numeric works, but I'm not thrilled with it...
For the life of me I can't come up with a good name to use here. Is there
a standard solution to this?
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From guido@CNRI.Reston.Va.US Mon Sep 9 21:27:42 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Mon, 09 Sep 1996 16:27:42 -0400
Subject: [PYTHON MATRIX-SIG] Re: Using Packages for Numeric Python
In-Reply-To: Your message of "Mon, 09 Sep 1996 15:49:56 EDT."
<9609091947.AA02705@goldilocks.LCS.MIT.EDU>
References: <9609091947.AA02705@goldilocks.LCS.MIT.EDU>
Message-ID: <199609092027.QAA14810@monty>
> Directory is called Numeric.
>
> The "Standard" Numeric Library is contained in the following modules:
> LinearAlgebra.py
> Random.py
> FFT.py
>
> So you have Numeric.LinearAlgebra.inverse(m) which looks good to me.
>
> What should I now call the module that used to be known as Numeric? This
> is the module that contains all of the "core" functionality of the
> extension.
How about Numeric.Core?
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From friedric@rose.rsoc.rockwell.com Mon Sep 9 21:35:14 1996
From: friedric@rose.rsoc.rockwell.com (Robin Friedrich)
Date: Mon, 9 Sep 1996 15:35:14 -0500
Subject: [PYTHON MATRIX-SIG] Using Packages for Numeric Python
Message-ID: <199609092035.PAA07934@darwin.rsoc.rockwell.com>
|> From: "Jim Hugunin" <hugunin@mit.edu>
|> To: "Guido van Rossum" <guido@CNRI.Reston.Va.US>
|>
|> I'm now "packaging" up NumPy for the next alpha release. I have the
|> following structure:
|>
|> Directory is called Numeric.
|>
|> The "Standard" Numeric Library is contained in the following modules:
|> LinearAlgebra.py
|> Random.py
|> FFT.py
|>
|> So you have Numeric.LinearAlgebra.inverse(m) which looks good to me.
|>
|> What should I now call the module that used to be known as Numeric? This
|> is the module that contains all of the "core" functionality of the
|> extension.
|>
|> import Numeric.Numeric seems kind of broken to me.
|> from Numeric import Numeric works, but I'm not thrilled with it...
Yes, I suppose Numeric.Numeric seems odd but it's not without precedent.
I would suggest Core.py yielding import Numeric.Core
|>
|> For the life of me I can't come up with a good name to use here. Is there
|> a standard solution to this?
|>
|> -Jim
No standard solution. Unless Guido says there is;
then there's a standard solution:-)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Mon Sep 9 21:39:02 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 9 Sep 1996 16:39:02 -0400
Subject: [PYTHON MATRIX-SIG] Re: Using Packages for Numeric Python
Message-ID: <9609092036.AA03311@goldilocks.LCS.MIT.EDU>
> > What should I now call the module that used to be known as Numeric?
This
> > is the module that contains all of the "core" functionality of the
> > extension.
>
> How about Numeric.Core?
1) I don't want to type: Numeric.Core.array([1,2,3], Numeric.Core.Float32)
2) "from Numeric import Core" seems even worse
3) This would leave me usually doing: "from Numeric.Core import *" which is
also less than ideal ;-)
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From klm@CNRI.Reston.Va.US Mon Sep 9 21:32:55 1996
From: klm@CNRI.Reston.Va.US (Ken Manheimer)
Date: Mon, 9 Sep 1996 16:32:55 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Using Packages for Numeric Python
In-Reply-To: <9609091947.AA02705@goldilocks.LCS.MIT.EDU>
Message-ID: <Pine.SOL.3.95.960909161353.21477P-100000@glyph>
On Mon, 9 Sep 1996, Jim Hugunin wrote:
> Directory is called Numeric.
>
> The "Standard" Numeric Library is contained in the following modules:
> LinearAlgebra.py
> Random.py
> FFT.py
>
> What should I now call the module that used to be known as Numeric? This
> is the module that contains all of the "core" functionality of the
> extension.
>
> import Numeric.Numeric seems kind of broken to me.
> from Numeric import Numeric works, but I'm not thrilled with it...
>
> For the life of me I can't come up with a good name to use here. Is there
> a standard solution to this?
This is where the packages philosophy diverges. My inclination would be
to have the top level package contain data and functions, as does the
current Numeric module, as well as containing the special-purpose
submodules - Random, FFT, etc.
(You can do this by putting the code for initting the basic numeric
routines in the package's __init__.py module, and/or putting the code in
other modules in the directory and having the __init__.py do a 'from
<blat> import *'.)
This will reduce the ease of identifying the module components of the
system at the top level, though, similar to the way that files obscure
the visibility of contained directories, in a file system.
The only name i can think of for doing it as a nested module is
"base.py", and to me that merely emphasizes the notion that the base
routines and data should be situated at the top level. Fwiw, there is
some precedent for the top-level situation - the os module directly
contains many routines and some data, and also the nested os.path
module. (In that case the nesting is not effected using ni, however.)
Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268
(orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From ted_horst@il.us.swissbank.com Mon Sep 9 21:55:19 1996
From: ted_horst@il.us.swissbank.com (Ted Horst)
Date: Mon, 9 Sep 96 15:55:19 -0500
Subject: [PYTHON MATRIX-SIG] Re: Mandelbrot: another nice useless NumPy
script?!
References: <9609091824.AA01654@goldilocks.LCS.MIT.EDU>
Message-ID: <9609092055.AA00538@ch1d166nwk>
Just to add another data point, I changed the output array to Int and
translated to characters after the iteration was done, and it worked OK.
Ted Horst
(not speaking for SwissBank)
Begin forwarded message:
From: "Jim Hugunin" <hugunin@mit.edu>
To: <Rob.Hooft@embl-heidelberg.de>, "Tom Schwaller" <tom.schwaller@linux-magazin.de>
Cc: <matrix-sig@python.org>
Subject: Re: [PYTHON MATRIX-SIG] Re: Mandelbrot: another nice useless NumPy script?!
Date: Mon, 9 Sep 1996 14:27:45 -0400
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Content-Type: text/plain; charset=ISO-8859-1
Sender: owner-matrix-sig@python.org
> TS> the Python interpreter crahes!!! After the 4th call of print
> TS> draw, the third cal is still ok.
>
> Hm, I just tried it on my ALPHA, and there it crashes already on the
> second call. Looks like a jump/call to a weird address:
This problem doesn't show up under my NT, Solaris or sunos versions of
alpha3. Hopefully this too is an already fixed bug. I'm working on
getting that alpha3 release out ASAP.
-Jim
=================
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 guido@CNRI.Reston.Va.US Mon Sep 9 21:43:56 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Mon, 09 Sep 1996 16:43:56 -0400
Subject: [PYTHON MATRIX-SIG] Re: Using Packages for Numeric Python
In-Reply-To: Your message of "Mon, 09 Sep 1996 16:39:02 EDT."
<9609092036.AA03311@goldilocks.LCS.MIT.EDU>
References: <9609092036.AA03311@goldilocks.LCS.MIT.EDU>
Message-ID: <199609092043.QAA14891@monty>
> > > What should I now call the module that used to be known as Numeric?
> This
> > > is the module that contains all of the "core" functionality of the
> > > extension.
> >
> > How about Numeric.Core?
>
> 1) I don't want to type: Numeric.Core.array([1,2,3], Numeric.Core.Float32)
>
> 2) "from Numeric import Core" seems even worse
>
> 3) This would leave me usually doing: "from Numeric.Core import *" which is
> also less than ideal ;-)
OK, here's a trick that will let you write
import Numeric
Numeric.array(...)
1) Put all the core stuff in Numeric/Core.py. The Numeric.Core.*
names will be the "official names" for all functions.
2) Provide a Numeric/__init__.py that somehow inserts everything from
Core into Numeric. I think the shortest hack is the following:
# This is Numeric/__init__.py
exec "from Core import *" in __.__dict__
(I haven't tested this but since __ is a shortcut for the parent
module and __init__ is actually a submodule of Numeric, __ in
__init__.py should refer to Numeric itself, so it should work.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Mon Sep 9 22:10:22 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Mon, 9 Sep 1996 17:10:22 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Using Packages for Numeric Python
In-Reply-To: <Pine.SOL.3.95.960909161353.21477P-100000@glyph> from "Ken Manheimer" at Sep 9, 96 04:32:55 pm
Message-ID: <199609092110.RAA18124@maigret>
> This is where the packages philosophy diverges. My inclination would be
> to have the top level package contain data and functions, as does the
> current Numeric module, as well as containing the special-purpose
> submodules - Random, FFT, etc.
This would have the advantage of breaking only minimal amounts of code.
It seems reasonable to me as well. After all, it is a core + extensions
architecture, not a multi-tiered system.
--david
=================
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 Tue Sep 10 09:48:13 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 10 Sep 96 09:48:13 +0100
Subject: [PYTHON MATRIX-SIG] Using Packages for Numeric Python
In-Reply-To: <Pine.SOL.3.95.960909161353.21477P-100000@glyph> (message from
Ken Manheimer on Mon, 9 Sep 1996 16:32:55 -0400 (EDT))
Message-ID: <199609100750.JAA29439@ibs.ibs.fr>
> This is where the packages philosophy diverges. My inclination would be
> to have the top level package contain data and functions, as does the
> current Numeric module, as well as containing the special-purpose
> submodules - Random, FFT, etc.
I prefer this to all the other suggestions I have seen. Are there any
serious reasons against doing this?
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 mclay@eeel.nist.gov Tue Sep 10 07:53:30 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Tue, 10 Sep 1996 06:53:30 GMT
Subject: [PYTHON MATRIX-SIG] More naming/module issues
In-Reply-To: <Pine.SUN.3.91.960909111422.327A-100000@lems33>
References: <199609091002.MAA23833@ibs.ibs.fr>
<Pine.SUN.3.91.960909111422.327A-100000@lems33>
Message-ID: <199609100653.GAA07543@fermi.eeel.nist.gov>
Perry A. Stoll writes:
>
>
> On Mon, 9 Sep 1996, Konrad Hinsen wrote:
>
> > > And you don't get them. If your code says
> > >
> > > import FFT.NAG
> > >
> > > then FFT.FFTPACK and others are not loaded. So this sounds about right.
> >
> > It seems I have missed some important feature of Python. How can I get
> > the symbol "NAG" in module "FFT" assigned to a module without
> > writing "import NAG" inside FFT.py?
> >
> > Konrad
>
> You can't do it by importing the "module" FFT, but the FFT "package"
> should do just fine. It's a nice feature - you should definitely find out
> about it. There is documentation on packages at the head of the file ni.py
> in the standard distribution.
>
Be sure to use the ni.py module from either the latest version of
grail or from the 1.4bx distribution. There was a two line fix in
the new release that makes ni much easier to use. (The default
behavior is what is described above.) If you use the older release
trying to do this would raise an exception.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From neal@ctd.comsat.com Tue Sep 10 13:59:06 1996
From: neal@ctd.comsat.com (Neal Becker)
Date: Tue, 10 Sep 1996 08:59:06 -0400
Subject: [PYTHON MATRIX-SIG] Newbee, first try
Message-ID: <E0v0SPC-0002XY-00@neal.ctd.comsat.com>
This is my first try with NumPy. I used python-1.4b3. Running
../python test_all.py
[...]
array([0.0, 0.0, 1.0], 'd')
Traceback (innermost last):
File "test_all.py", line 42, in ?
test_lines(fp.readlines())
File "test_all.py", line 39, in test_lines
exec(line)
File "<string>", line 1, in ?
ImportError: No module named Integer
Is this normal?
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From Rob.Hooft@embl-heidelberg.de Tue Sep 10 15:25:12 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Tue, 10 Sep 1996 16:25:12 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] Useless again.
Message-ID: <199609101425.QAA07508@nu>
Did I really write this? I am ashamed of myself. And such a horribly
inefficient way of getting information from NumPy into Tk.....
Please, if people get bored with these useless examples I'm only
making to teach myself how to use this stuff, tell me and I'll stop
posting.
Regards,
Rob
-----------------------------------------------------------------------
#!/bin/env python
#
# Mandelbrot using TkInter and Numeric Python 1.0alpha2
# Currently does not clean up the temporary files!
#
# Rob Hooft, 1996. Distribute freely.
import Numeric, Tkinter, string, tempfile
def writexbm(fname,bitarr):
"""Write 2-D bit-array bitarr of shape [ysize,xsize] with xsize=8*k
into an 'xbm' type file with name 'fname'. bitarr is not checked on
its bitness!"""
ysize=bitarr.shape[0]
xsize=bitarr.shape[1]
# Make 8 consecutive bits into a byte
if xsize%8:
raise "Oops, xsize should be multiple of 8\n"
xsize=xsize/8
p=Numeric.reshape(bitarr,[ysize,xsize,8])
bytarr=Numeric.zeros([ysize,xsize])
for bit in range(7,-1,-1):
bytarr=bytarr*2+p[:,:,bit]
# put the info in a standard ".xbm" file
f=open(fname,"w");
f.write("#define icon_width %d\n"%(8*xsize));
f.write("#define icon_height %d\n"%ysize);
f.write("static char icon_bits[] = {\n");
# The data should be written as hex numbers separated by ','
f.write(string.join(map(hex,Numeric.reshape(bytarr,[xsize*ysize])),","))
f.write("}\n");
f.close()
class BitScreen:
def __init__(self,master=None):
self.c=Tkinter.Canvas(master,bg="#000")
self.c.pack()
self.num=0
self.frame=tempfile.mktemp()+"%02d"
def mapbits(self,bitarr,color="#F00"):
self.num=self.num+1
fname=self.frame%self.num
writexbm(fname,bitarr)
self.c.create_bitmap(bitarr.shape[1]/2+2,bitarr.shape[0]/2+2,
bitmap="@"+fname,foreground=color);
self.c.update_idletasks()
def erase(self):
for item in self.c.find_all():
self.c.delete(item)
self.c.update_idletasks()
def __del__(self):
self.c.destroy()
def mainloop(self):
self.c.mainloop()
class MandelScreen(BitScreen):
def __init__(self,master=None,stepx=80,stepy=24):
BitScreen.__init__(self,master)
self.colormap=["#00F","#01E","#02D","#03C","#04B","#05A","#069","#078",
"#087","#096","#0A5","#0B4","#0C3","#0D2","#0E1","#0F0",
"#1E0","#2D0","#3C0","#4B0","#5A0","#690","#780","#870",
"#960","#A50","#B40","#C30","#D20","#E10","#F00","#E01",
"#D02","#C03","#B04","#A05","#906","#807","#708","#609",
"#50A","#40B","#30C","#20D","#10F"]
self.setsize(stepx,stepy)
self.setmaxiter(len(self.colormap))
self.colorspeed=1
def setsize(self,stepx,stepy):
self.stepx=(stepx/8)*8
self.stepy=stepy
self.c.configure(width=stepx,height=stepy)
def setmaxiter(self,maxiter):
self.maxiter=maxiter
def draw(self, LowX, HighX, LowY, HighY):
xx=Numeric.arange(LowX,HighX,(HighX-LowX)/self.stepx)
yy=Numeric.arange(HighY,LowY,(LowY-HighY)/self.stepy)*1j
c=xx+yy[:,Numeric.NewAxis]
z=Numeric.zeros(c.shape,Numeric.Complex)
for iter in range(self.maxiter):
z=z*z+c
finished=Numeric.greater(abs(z),2.0)
color=self.colormap[(self.colorspeed*iter)%len(self.colormap)]
self.mapbits(finished,color=color)
c=Numeric.where(finished,0+0j,c)
z=Numeric.where(finished,0+0j,z)
if __name__ == "__main__":
s=MandelScreen()
s.setsize(304,225)
s.setmaxiter(30)
s.draw(-2.1, 0.7, -1.2, 1.2)
s.mainloop()
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Tue Sep 10 18:32:28 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 10 Sep 1996 13:32:28 -0400
Subject: [PYTHON MATRIX-SIG] Newbee, first try
Message-ID: <9609101730.AA15722@goldilocks.LCS.MIT.EDU>
> This is my first try with NumPy. I used python-1.4b3. Running
>
> ../python test_all.py
> [...]
> ImportError: No module named Integer
This is a bug in the alpha2 test script. Just remove the "import Integer"
line from the script and all will be well.
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Tue Sep 10 18:52:56 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 10 Sep 1996 13:52:56 -0400
Subject: [PYTHON MATRIX-SIG] Useless again.
Message-ID: <9609101750.AA15964@goldilocks.LCS.MIT.EDU>
> Did I really write this? I am ashamed of myself. And such a horribly
> inefficient way of getting information from NumPy into Tk.....
You should REALLY look at PIL. It has very nice features for doing exactly
this sort of thing. It's about two lines of code to hook a Numeric array
into a PIL image, and I think the plans are to make the interface even
easier in future versions.
> Please, if people get bored with these useless examples I'm only
> making to teach myself how to use this stuff, tell me and I'll stop
> posting.
I like the examples, they'll help me fill up my samples directory ;-)
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From fredrik_lundh@ivab.se Tue Sep 10 21:06:39 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Tue, 10 Sep 1996 22:06:39 +0200
Subject: [PYTHON MATRIX-SIG] Useless again.
In-Reply-To: <9609101750.AA15964@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <9609102006.AA05536@arnold.image.ivab.se>
Jim writes:
> You should REALLY look at PIL. It has very nice features for doing
> exactly this sort of thing. It's about two lines of code to hook a
> Numeric array into a PIL image, and I think the plans are to make
> the interface even easier in future versions.
Thanks for the kind words. Its great to find PR people everywhere :-)
FYI, here's the current way to interface PIL 0.1 with a numeric array:
import Image, Numeric
def ImageToArray(i):
a = Numeric.array(i._tostring(), "b")
a.shape = i.size[1], i.size[0]
return a
def ArrayToImage(a):
i = Image.new("L", (a.shape[1], a.shape[0]))
i._fromstring(a.toString())
return i
I've added getdata() and putdata() methods in PIL 0.2. The former
returns a sequence object, the latter a takes a sequence, and optional
scale and offset arguments (yes, I know I've forgot to update the web
page. The 0.2 release is a few weeks delayed...)
As for future versions, I really hope we can persuade Guido to add the
multiarray object to the Python core ;-)
Cheers /F
=================
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 Wed Sep 11 13:07:32 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 11 Sep 96 13:07:32 +0100
Subject: [PYTHON MATRIX-SIG] What happened to math exceptions?
Message-ID: <199609111109.NAA06351@ibs.ibs.fr>
Here's today's surprise:
Python 1.4b3 (October 13 1995) [C]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> from umath import *
from umath import *
>>> log(-1.)
log(-1.)
log: DOMAIN error
-1.79769313486e+308
>>>
Shouldn't umath functions raise exceptions in such cases?
I can't see any difference between umath and fast_umath for
this example.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 hugunin@mit.edu Wed Sep 11 18:07:12 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 11 Sep 1996 13:07:12 -0400
Subject: [PYTHON MATRIX-SIG] Re: What happened to math exceptions?
Message-ID: <9609111705.AA29817@goldilocks.LCS.MIT.EDU>
> Shouldn't umath functions raise exceptions in such cases?
> I can't see any difference between umath and fast_umath for
> this example.
The distinction between fast_umath and umath has gone away in my current
working version. I never use umath myself and haven't had the time to keep
it up to date (that's why it doesn't get built in the default makefile).
I'll probably fix this before the beta1 release, but no promises...
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Wed Sep 11 18:46:05 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 11 Sep 1996 13:46:05 -0400
Subject: [PYTHON MATRIX-SIG] More Package concerns
Message-ID: <9609111744.AA00513@goldilocks.LCS.MIT.EDU>
I'm having some serious last minute thoughts about using packages in NumPy.
They basically come down to the mysterious "import ni" that must come at
the top of every file that uses them. This seems like a great hack to play
around with the idea of packages, but it's an awfully confusing convention
to have to explain to all of the potentially naive users I expect for this
system.
How do people feel about having all of their files begin with:
import ni
import Numeric
...
Also, specifically to Guido, is the package feature something that you
expect to have built in to python in the future? Can I expect the import
ni to go away any time soon?
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From guido@CNRI.Reston.Va.US Wed Sep 11 20:15:42 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Wed, 11 Sep 1996 15:15:42 -0400
Subject: [PYTHON MATRIX-SIG] Re: More Package concerns
In-Reply-To: Your message of "Wed, 11 Sep 1996 13:46:05 EDT."
<9609111744.AA00513@goldilocks.LCS.MIT.EDU>
References: <9609111744.AA00513@goldilocks.LCS.MIT.EDU>
Message-ID: <199609111916.PAA23316@monty>
> I'm having some serious last minute thoughts about using packages in NumPy.
> They basically come down to the mysterious "import ni" that must come at
> the top of every file that uses them. This seems like a great hack to play
> around with the idea of packages, but it's an awfully confusing convention
> to have to explain to all of the potentially naive users I expect for this
> system.
>
> How do people feel about having all of their files begin with:
>
> import ni
> import Numeric
> ...
I don't mind, but I can see why this is ugly. Given that one usually
will have to write import sys, os, string etc. as well, does it really
matter?
Perhaps you can suggest
import ni, Numeric
There may also be a way to have a file Numeric.py that bootstraps the
whole thing into existence, which reduces the hack to one file that
you provide.
> Also, specifically to Guido, is the package feature something that you
> expect to have built in to python in the future? Can I expect the import
> ni to go away any time soon?
Not anytime soon -- it will stay imlemented in Python for a long time.
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
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 Thu Sep 12 09:31:15 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 12 Sep 96 09:31:15 +0100
Subject: [PYTHON MATRIX-SIG] More Package concerns
In-Reply-To: <9609111744.AA00513@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609120733.JAA09942@ibs.ibs.fr>
> How do people feel about having all of their files begin with:
>
> import ni
> import Numeric
> ...
Bad. But what's the alternative?
Since I know next to nothing about ni, I shouldn't speculate, but...
Would it be possible to put "import ni" into Numeric, such that
after "import Numeric" or "from Numeric import *" one could go on to
import subpackages?
Incidentally, I have wondered more than once why import doesn't
accept strings to specify the module to be imported. If that
were the case, a simple "FFT = 'FFT'" in Numeric.py would be
sufficient to get most of the package functionality without any
mysterious "import ni".
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 klm@CNRI.Reston.Va.US Thu Sep 12 16:52:18 1996
From: klm@CNRI.Reston.Va.US (Ken Manheimer)
Date: Thu, 12 Sep 1996 11:52:18 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Re: More Package concerns
In-Reply-To: <199609111916.PAA23316@monty>
Message-ID: <Pine.SOL.3.95.960912113601.21477i-100000@glyph>
On Wed, 11 Sep 1996, Guido van Rossum wrote:
> Perhaps you can suggest
>
> import ni, Numeric
>
> There may also be a way to have a file Numeric.py that bootstraps the
> whole thing into existence, which reduces the hack to one file that
> you provide.
>
> > Also, specifically to Guido, is the package feature something that you
> > expect to have built in to python in the future? Can I expect the import
> > ni to go away any time soon?
>
> Not anytime soon -- it will stay imlemented in Python for a long time.
Guido, what do you think of integrating ni just a tiny bit, so the
standard __import__ mechanism resorts to ni for imports that include a
'.' or '__' in the module name? This would slow down __import__
slightly, but i assume it would be fairly negligible, and would
eliminate something that might discourage people from building things
using packages...
(It also occurs to me to that we could have ni engaged at the point that
the regular import would raise an exception, thus having no performance
impact on successful imports. However, i see that would be in
imp.find_module, which may not be the right place to make the other
connections, or we would have to catch the exception around find_module,
which would have some impact on successful conventional imports...)
Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268
(orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From guido@CNRI.Reston.Va.US Thu Sep 12 18:45:45 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Thu, 12 Sep 1996 13:45:45 -0400
Subject: [PYTHON MATRIX-SIG] Re: More Package concerns
In-Reply-To: Your message of "Thu, 12 Sep 1996 11:52:18 EDT."
<Pine.SOL.3.95.960912113601.21477i-100000@glyph>
References: <Pine.SOL.3.95.960912113601.21477i-100000@glyph>
Message-ID: <199609121745.NAA28572@monty>
> Guido, what do you think of integrating ni just a tiny bit, so the
> standard __import__ mechanism resorts to ni for imports that include a
> '.' or '__' in the module name? This would slow down __import__
> slightly, but i assume it would be fairly negligible, and would
> eliminate something that might discourage people from building things
> using packages...
At this point in time, I think it's a bad idea to invoke Python code
implicitly from the C code. There are no precedents for that.
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From cgw@pgt.com Thu Sep 12 19:04:58 1996
From: cgw@pgt.com (Charles G Waldman)
Date: Thu, 12 Sep 1996 14:04:58 -0400
Subject: [PYTHON MATRIX-SIG] Re: Two things (FFT Normalization)
In-Reply-To: Your message of "Fri, 06 Sep 1996 13:46:36 EDT."
<9609061743.AA01849@goldilocks.LCS.MIT.EDU>
Message-ID: <9609121805.AA11754@reactor.pgt>
I'm sorry, I made a mistaken comment about normalization of
2 dimensional FFT's. I misinterpreted the explanation in the
reference I gave - - I should have checked this more carefully
before firing off email to the list.
I wrote:
> First of all, I don't think it will give the traditional normalization.
> (See, for example, Gonzalez&Wintz, "Digital Image Processing",
> Addison-Wesley, 1977, page 45)
Jim Hugunin replied
> Could you give me the right function to normalize this with?
The way it is currently being done is correct; sorry to have made that
inappropriate and incorrect comment.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From guido@CNRI.Reston.Va.US Thu Sep 12 21:19:00 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Thu, 12 Sep 1996 16:19:00 -0400
Subject: [PYTHON MATRIX-SIG] Re: complex numbers glitches and pynt14b3.exe
In-Reply-To: Your message of "12 Sep 1996 17:52:15 +0200."
<nnu3t3ybm8.fsf@tindra.lysator.liu.se>
References: <515kbm$538@news.udel.edu> <twiv9lclid.fsf@lmshp2.ibs.fr> <199609111237.IAA21035@monty> <laiv9l9ext.fsf_-_@albert1.fuw.edu.pl>
<nnu3t3ybm8.fsf@tindra.lysator.liu.se>
Message-ID: <199609122019.QAA29000@monty>
I'm tired of hearing how z1%z2 should be implemented without C code.
Would someone please code it up and send me a patch!?
Also, I want to change int(), long() and float() for complex numbers
to raise a TypeError exception, since these really shouldn't be
applicable to complex numbers. This should fix the problem of
math.sqrt(-1j) returning 0.0.
I wonder if this would break any of the Numerics code though?
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Thu Sep 12 21:57:05 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 12 Sep 1996 16:57:05 -0400
Subject: [PYTHON MATRIX-SIG] Re: complex numbers glitches and pynt14b3.exe
Message-ID: <9609122055.AA17771@goldilocks.LCS.MIT.EDU>
> I'm tired of hearing how z1%z2 should be implemented without C code.
> Would someone please code it up and send me a patch!?
>
> Also, I want to change int(), long() and float() for complex numbers
> to raise a TypeError exception, since these really shouldn't be
> applicable to complex numbers. This should fix the problem of
> math.sqrt(-1j) returning 0.0.
>
> I wonder if this would break any of the Numerics code though?
Won't break any of mine. -Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From Rob.Hooft@embl-heidelberg.de Thu Sep 12 21:52:03 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Thu, 12 Sep 1996 22:52:03 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] Re: complex numbers glitches and pynt14b3.exe
In-Reply-To: <199609122019.QAA29000@monty>
References: <515kbm$538@news.udel.edu>
<twiv9lclid.fsf@lmshp2.ibs.fr>
<199609111237.IAA21035@monty>
<laiv9l9ext.fsf_-_@albert1.fuw.edu.pl>
<nnu3t3ybm8.fsf@tindra.lysator.liu.se>
<199609122019.QAA29000@monty>
Message-ID: <199609122052.WAA21032@nu>
>>>>> "GvR" == Guido van Rossum <guido@CNRI.Reston.Va.US> writes:
GvR> Also, I want to change int(), long() and float() for complex
GvR> numbers to raise a TypeError exception
[...]
GvR> I wonder if this would break any of the Numerics code though?
Numerics code is in Alpha. It is allowed to break it.
Rob.
--
=== Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux! Free Software Rules The World! =============
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Fri Sep 13 22:00:13 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 13 Sep 1996 17:00:13 -0400
Subject: [PYTHON MATRIX-SIG] Alpha3 Available
Message-ID: <9609132058.AA01011@goldilocks.LCS.MIT.EDU>
Wonder of wonders, the next release is out (On a Friday afternoon as
usual).
Major additions:
Linear Algebra, Random Number, FFT modules now provided with portable C
implementations and the option of linking with highly optimized FORTRAN
libraries if available.
Major incompatible changes:
sort, argmax, and their ilk now have a default axis of -1 (once again and
forever)
Numeric is now a python package. To use it you must do "import ni,
Numeric".
If enough people complain, this might be changed before the beta release.
I view this release as complete. Other than packages, I have no intention
of either making incompatible changes or adding any substantial new
features. It's time to concentrate on debugging, documentation
(volunteers?) and getting this out to the rest of the list.
I want to get a handle on how many people are testing this out, so if you
make it on your system please send me email (hugunin@mit.edu). I'd also
appreciate it if you'd run test/test_all.py and let me know how that works.
As usual, bug reports are greatly appreciated.
The source distribution is in:
ftp://ftp.sls.lcs.mit.edu/pub/jjh/NumPy-1.0a3.tar.gz
Read the file INSTALL for instructions on building this version.
For WinNT/95 users, there is a binary distribution available:
ftp://ftp.sls.lcs.mit.edu/pub/jjh/numpy.zip
You should have the latest version of pythonwin (pythonwin-10-b3.exe)
installed to use this. Unpack the zipped file using a version of unzip
that can handle long file names (like unzip) in the toplevel Python
directory created when you install pythonwin. You must use the "-d" option
to preserve the directory structure when you unzip. Also, you must add the
NumPy directory to your PYTHONPATH registry entry.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From acannon@geog.ubc.ca Sat Sep 14 07:08:17 1996
From: acannon@geog.ubc.ca (Alex Cannon)
Date: Fri, 13 Sep 1996 23:08:17 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] Alpha3 Available
In-Reply-To: <9609132058.AA01011@goldilocks.LCS.MIT.EDU>
Message-ID: <Pine.SUN.3.95.960913225943.234C-100000@whimbrel>
On Fri, 13 Sep 1996, Jim Hugunin wrote:
>
> You should have the latest version of pythonwin (pythonwin-10-b3.exe)
> installed to use this. Unpack the zipped file using a version of unzip
> that can handle long file names (like unzip) in the toplevel Python
> directory created when you install pythonwin. You must use the "-d" option
> to preserve the directory structure when you unzip. Also, you must add the
> NumPy directory to your PYTHONPATH registry entry.
>
I've just gotten NumPy, unzipped it (with WinZip), and added the NumPy dir
to the PYTHONPATH registry entry. However, upon importing I get:
PythonWin 1.4b3 (Sep 4 1996) [MSC 32 bit (Intel)]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
Portions copyright 1994-1996 Mark Hammond (MHammond@skippinet.com.au)
>>> import ni, Numeric
Traceback (innermost last):
File "<interactive input>", line 1, in ?
File "C:\Python\Lib\ni.py", line 302, in import_module
m = self.get0(mname)
File "C:\Python\Lib\ni.py", line 344, in get0
m = self.get(name)
File "C:\Python\Lib\ni.py", line 362, in get
sys.modules[name] = m = self.loader.load_module(name, stuff)
File "C:\Python\Lib\ni.py", line 195, in load_module
return self.load_package(name, stuff)
File "C:\Python\Lib\ni.py", line 233, in load_package
self.init_package(package)
File "C:\Python\Lib\ni.py", line 239, in init_package
self.call_init_module(package)
File "C:\Python\Lib\ni.py", line 261, in call_init_module
m = self.load_module(package.__name__ + '.__init__', stuff)
File "C:\Python\Lib\ni.py", line 204, in load_module
return ModuleLoader.load_module(self, name, stuff)
File "C:\Python\Lib\ihooks.py", line 259, in load_module
return self.hooks.load_source(name, filename, file)
File "C:\Python\Lib\ihooks.py", line 170, in load_source
return imp.load_source(name, filename, file)
File "C:\Python\NumPy\Numeric\__init__.py", line 1, in ?
import Core
File "C:\Python\Lib\ni.py", line 302, in import_module
m = self.get0(mname)
File "C:\Python\Lib\ni.py", line 344, in get0
m = self.get(name)
File "C:\Python\Lib\ni.py", line 362, in get
sys.modules[name] = m = self.loader.load_module(name, stuff)
File "C:\Python\Lib\ni.py", line 204, in load_module
return ModuleLoader.load_module(self, name, stuff)
File "C:\Python\Lib\ihooks.py", line 259, in load_module
return self.hooks.load_source(name, filename, file)
File "C:\Python\Lib\ihooks.py", line 170, in load_source
return imp.load_source(name, filename, file)
File "C:\Python\NumPy\Numeric\Core.py", line 4, in ?
import multiarray
File "C:\Python\Lib\ni.py", line 302, in import_module
m = self.get0(mname)
File "C:\Python\Lib\ni.py", line 344, in get0
m = self.get(name)
File "C:\Python\Lib\ni.py", line 362, in get
sys.modules[name] = m = self.loader.load_module(name, stuff)
File "C:\Python\Lib\ni.py", line 204, in load_module
return ModuleLoader.load_module(self, name, stuff)
File "C:\Python\Lib\ihooks.py", line 257, in load_module
return self.hooks.load_dynamic(name, filename, file)
File "C:\Python\Lib\ihooks.py", line 174, in load_dynamic
return imp.load_dynamic(name, filename, file)
ImportError: DLL load failed: One of the library files needed to run this
application cannot be found.
>>>
Any ideas as to what I've done wrong?
Alex
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Sat Sep 14 13:39:47 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sat, 14 Sep 96 13:39:47 +0100
Subject: [PYTHON MATRIX-SIG] Alpha3 Available
In-Reply-To: <9609132058.AA01011@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609141141.NAA19128@ibs.ibs.fr>
> I view this release as complete. Other than packages, I have no intention
Well, I don't. I strongly suspect that you forgot to put
NumPy/Numeric/* into the tar file...
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 hugunin@mit.edu Sat Sep 14 17:15:41 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Sat, 14 Sep 1996 12:15:41 -0400
Subject: [PYTHON MATRIX-SIG] Alpha3 Available
Message-ID: <9609141613.AA09435@goldilocks.LCS.MIT.EDU>
> >
> > You should have the latest version of pythonwin (pythonwin-10-b3.exe)
> > installed to use this. Unpack the zipped file using a version of unzip
> > that can handle long file names (like unzip) in the toplevel Python
> > directory created when you install pythonwin. You must use the "-d"
option
> > to preserve the directory structure when you unzip. Also, you must add
the
> > NumPy directory to your PYTHONPATH registry entry.
> >
>
> I've just gotten NumPy, unzipped it (with WinZip), and added the NumPy
dir
> to the PYTHONPATH registry entry. However, upon importing I get:
...
> Any ideas as to what I've done wrong?
>
> Alex
My guess is that you can't find numpy.dll. Is this file in the same
directory as python14.dll? If not, you need to be sure that this dll is in
your dll load path. Also, you must have python14.dll as the dll used by
your version of python, any older versions won't work.
Let me know if this fixes your problem or if you're still having trouble.
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Sat Sep 14 17:37:10 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Sat, 14 Sep 1996 12:37:10 -0400
Subject: [PYTHON MATRIX-SIG] Another new release?
Message-ID: <9609141635.AA09631@goldilocks.LCS.MIT.EDU>
Due to a shocking typo yesterday afternoon, I produced an alpha3 release
that wasn't worth the bits it was printed on (none of the needed python
files were provided).
So, I just made an alpha4 version available that fixes this (and two
trivial bugs in generalized_inverse and argsort).
The new release is in
ftp://ftp.sls.lcs.mit.edu/pub/jjh/NumPy-1.0a4.tar.gz
For those who already got alpha3 and don't want to download the whole thing
again I'm also providing which can be installed by untarring from the same
place that you untarred alpha3.
ftp://ftp.sls.lcs.mit.edu/pub/jjh/fix-a3-a4.tar.gz
If you downloaded the windows binary version you shouldn't worry about this
release. (However, I've still yet to hear of anybody who successfully
installed that binary so there might be other problems there...)
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Sat Sep 14 18:00:12 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Sat, 14 Sep 1996 13:00:12 -0400
Subject: [PYTHON MATRIX-SIG] More on installation
Message-ID: <9609141658.AA09910@goldilocks.LCS.MIT.EDU>
> > If you downloaded the windows binary version you shouldn't worry about
this
> > release. (However, I've still yet to hear of anybody who successfully
> > installed that binary so there might be other problems there...)
> You might want to remind folks that numpy.dll needs to be in the PATH,
> not the PYTHONPATH. That was my problem.
Good point. I'm assuming that python14.dll is in the PATH, so if you put
numpy.dll in the same place you should be all right...
(relevant to everyone)
> What's also weird is that what works in almost all directories (import
> ni,Numeric) does not work from the NumPy/Numeric directory, for reasons
> which still elude me).
This is indeed strange. Does anybody who better understand packages know
this one?
> Also, remind people to delete their old Lib/Numeric directory if they
> had it...
Is everybody reminded?
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From acannon@geog.ubc.ca Sun Sep 15 02:24:06 1996
From: acannon@geog.ubc.ca (Alex Cannon)
Date: Sat, 14 Sep 1996 18:24:06 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] More on installation
In-Reply-To: <9609141658.AA09910@goldilocks.LCS.MIT.EDU>
Message-ID: <Pine.SUN.3.95.960914182141.2661A-100000@whimbrel>
On Sat, 14 Sep 1996, Jim Hugunin wrote:
> > You might want to remind folks that numpy.dll needs to be in the PATH,
> > not the PYTHONPATH. That was my problem.
>
> Good point. I'm assuming that python14.dll is in the PATH, so if you put
> numpy.dll in the same place you should be all right...
I've tried numpy.dll in the same directory as python14.dll (as well as
others in the PATH) and am still getting the same error.
Alex
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From spillar@uwyo.edu Sun Sep 15 11:13:35 1996
From: spillar@uwyo.edu (Earl Spillar)
Date: Sun, 15 Sep 1996 04:13:35 -0600
Subject: [PYTHON MATRIX-SIG] More on installation]
Message-ID: <323BD6CF.396B@uwyo.edu>
This is a multi-part message in MIME format.
--------------72224073485D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Umm, I'm having the same problem as Alex-
an interesting twist though, everything seems to load fine
if I'm in the command line version of Python 1.4beta3.
Maybe this is a clue?
Earl Spillar
http://plains.uwyo.edu/~spillar
--------------72224073485D
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-path: <owner-matrix-sig@python.org>
Received: from roper.uwyo.edu (SYSTEM@roper.uwyo.edu)
by PLAINS.UWYO.EDU (PMDF V5.0-6 #14244)
id <01I9HBRMIL0W0049QP@PLAINS.UWYO.EDU> for spillar@PLAINS.UWYO.EDU; Sat,
14 Sep 1996 19:55:44 -0600 (MDT)
Received: from DIRECTORY-DAEMON by ROPER.UWYO.EDU (PMDF V5.0-4 #14244)
id <01I9HBRJ8G2O00A7LI@ROPER.UWYO.EDU> for spillar@plains.uwyo.edu; Sat,
14 Sep 1996 19:55:34 -0600 (MDT)
Received: from larch.python.org (larch.python.org)
by ROPER.UWYO.EDU (PMDF V5.0-4 #14244) id <01I9HBRIA4DS007806@ROPER.UWYO.EDU>
for spillar@uwyo.edu; Sat, 14 Sep 1996 19:55:33 -0600 (MDT)
Received: (from majordom@localhost) by python.org (8.7.5/8.7.3)
id VAA15496 for matrix-sig-people; Sat, 14 Sep 1996 21:25:27 -0400 (EDT)
Received: from phoenix.geog.ubc.ca (phoenix.geog.ubc.ca [137.82.51.1])
by python.org (8.7.5/8.7.3) with ESMTPid VAA15491 for <matrix-sig@python.org>;
Sat, 14 Sep 1996 21:25:23 -0400 (EDT)
Received: from whimbrel.geog.ubc.ca (whimbrel [137.82.51.7])
by phoenix.geog.ubc.ca (8.7.3/8.7.3) with ESMTP id SAA15337; Sat,
14 Sep 1996 18:24:07 -0700 (PDT)
Received: from localhost (acannon@localhost)
by whimbrel.geog.ubc.ca (8.6.12/8.6.12) with SMTP id SAA02663; Sat,
14 Sep 1996 18:24:06 -0700
Date: Sat, 14 Sep 1996 18:24:06 -0700 (PDT)
From: Alex Cannon <acannon@geog.ubc.ca>
Subject: Re: [PYTHON MATRIX-SIG] More on installation
In-reply-to: <9609141658.AA09910@goldilocks.LCS.MIT.EDU>
Sender: owner-matrix-sig@python.org
X-Sender: acannon@whimbrel
To: Jim Hugunin <hugunin@mit.edu>
Cc: David Ascher <da@maigret.cog.brown.edu>,
Python Matrix SIG <matrix-sig@python.org>
Message-id: <Pine.SUN.3.95.960914182141.2661A-100000@whimbrel.uwyo.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Precedence: bulk
X-Authentication-warning: whimbrel.geog.ubc.ca: acannon owned process doing -bs
On Sat, 14 Sep 1996, Jim Hugunin wrote:
> > You might want to remind folks that numpy.dll needs to be in the PATH,
> > not the PYTHONPATH. That was my problem.
>
> Good point. I'm assuming that python14.dll is in the PATH, so if you put
> numpy.dll in the same place you should be all right...
I've tried numpy.dll in the same directory as python14.dll (as well as
others in the PATH) and am still getting the same error.
Alex
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
--------------72224073485D--
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From spillar@uwyo.edu Mon Sep 16 00:29:45 1996
From: spillar@uwyo.edu (Earl Spillar)
Date: Sun, 15 Sep 1996 17:29:45 -0600
Subject: [PYTHON MATRIX-SIG] More on installation]
References: <323BD6CF.396B@uwyo.edu>
Message-ID: <323C9169.2813@uwyo.edu>
Actyually, I lied- it appears to take the import ni,numeric OK,
but when I execute anything, the Python session crashes.
Earl
Earl Spillar wrote:
>
> Umm, I'm having the same problem as Alex-
> an interesting twist though, everything seems to load fine
> if I'm in the command line version of Python 1.4beta3.
> Maybe this is a clue?
>
> Earl Spillar
> http://plains.uwyo.edu/~spillar
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From Michal.Spalinski@fuw.edu.pl Mon Sep 16 13:22:23 1996
From: Michal.Spalinski@fuw.edu.pl (Michal.Spalinski@fuw.edu.pl)
Date: Mon, 16 Sep 96 14:22:23 +0200
Subject: [PYTHON MATRIX-SIG] Matrix
Message-ID: <9609161222.AA12912@albert1.fuw.edu.pl>
I did the following:
Python 1.4b3 (Sep 13 1996) [C]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> import ni,Numeric
>>> from Numeric.Matrix import *
>>> qq=Matrix([[12,21],[323,3434]])
>>> qq
Matrix 21
323 3434
This looks strange to me. I also tried
>>> ww=Matrix([21,32,43,5])
>>> ww
Matrix 43 5
>>>
This also looks very odd. Am I misusing Matrix, or is there some problem
here?
--
Michal Spalinski
http://info.fuw.edu.pl/~mspal/home.html
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Mon Sep 16 14:29:47 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 16 Sep 1996 09:29:47 -0400
Subject: [PYTHON MATRIX-SIG] Matrix
Message-ID: <9609161327.AA29243@goldilocks.LCS.MIT.EDU>
...
> This also looks very odd. Am I misusing Matrix, or is there some problem
> here?
My first comment would be that there's a reason Matrix is not documented
yet. I haven't looked at the code since the 0.35 release. I'll look at
UserArray and Matrix when I get a chance, but specific patches are also
greatly appreciated.
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Mon Sep 16 16:24:54 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 16 Sep 96 16:24:54 +0100
Subject: [PYTHON MATRIX-SIG] Matrix
In-Reply-To: <9609161222.AA12912@albert1.fuw.edu.pl>
(Michal.Spalinski@fuw.edu.pl)
Message-ID: <199609161426.QAA25695@ibs.ibs.fr>
> Python 1.4b3 (Sep 13 1996) [C]
> Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
> >>> import ni,Numeric
> >>> from Numeric.Matrix import *
> >>> qq=Matrix([[12,21],[323,3434]])
> >>> qq
> Matrix 21
> 323 3434
>
> This looks strange to me. I also tried
The following line in UserArray.py is responsible for this rubbish:
def __repr__(self):
return self.name+str(self.array)[5:] #Hack, will break if repr for array changes
As the comment says, this has broken... As an immediate replacement,
I suggest:
def __repr__(self):
return self.name + '\n' + str(self.array)
This will print "Matrix" and the data starting from the next line.
In the long run, someone should think about (and implement) a nicer
way to print matrices to make them look distinct from arrays, e.g.
a border around it or whatever.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Mon Sep 16 18:18:36 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 16 Sep 96 18:18:36 +0100
Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
Message-ID: <199609161620.SAA26543@ibs.ibs.fr>
There are a couple of issues that I think ought to be discussed
before moving from alpha to beta status:
1) The package system.
----------------------
Although a good idea, I dislike it more and more after using it for a
while. Not only does it need the mysterious "import ni", whose meaning
is evident neither from its name nor from the way it is used, but it
also introduces unwelcome surprises. For example, "from Numeric
import *" doesn't work any more, even after "import ni", importing
anything specific poses no problem ("from Numeric import
array"). Sure, I can resort to "from Numeric.Core import *", but
that's more complicated (think about interactive use) and less
clear. How am I supposed to explain to a newbie (who just learned who
wonderfully consistent Python is) that getting all functions from
Numeric involves
import ni; from Numeric.Core import *
although no object from "ni" is never used and "Numeric.Core" occurs
in no other context?
So let's look at the alternatives:
a) No packages. We could then have suggestive names, e.g.
"Numeric_FFT" for the submodules. Of course that supposes
that long module names can safely be used on all systems.
b) Simulate the module behaviour in a different way. One idea I had
is to define a class (untested, of course ;-)
class Submodule:
def __init__(self, name, base):
self.name = name
self.base = base
self.module = None
def __getattr__(self, name):
if self.module is None:
module_name = self.base + self.name
exec 'import ' + module_name
self.module = eval(module)
return getattr(self.module, name)
Then Numeric.py would contain, for example,
FFT = Submodule('FFT', 'N_')
and any reference to Numeric.FFF.x would import N_FFT and
return object x from it, which could then be assigned at
will or of course used directly. If performance is considered
a problem, one could transfer all the names from the freshly
loaded module into the submodule object for direct access.
This would give most of the package functionality, except
it is impossible to import a submodule directly - which in
our case doesn't make much sense anyway.
2) The umath module.
--------------------
The original idea was to have two versions of this module: one, umath,
would behave just like any decent Python program and raise exceptions
for floating point errors, and the other, fast_umath, would for the
sake of speed just return whatever the floating point code (or
processor) produces. Since Jim is a speed fanatic, he has concentrated
on fast_umath to the point that umath is not even compiled in the
standard distribution. Still I think that there will be no disagreement
about the need for both in an official distribution.
However, there are additional problems caused by the fact that
routines from umath are used in Numeric (to be precise, all items from
umath are provided by Numeric, and some are used in other functions,
e.g. add.reduce). This raises two questions:
a) How can the user select between umath and fast_umath?
b) Which should be the default?
Right now, "fast_umath" is hard-coded into Numeric/Core.py, which is
probably the worst solution. The alternatives I can think of are
a) Have two separate modules, "Numeric" and "Fast_numeric". A bit
wasteful, even more so in the presence of packages.
b) Selection via a variable or function in module sys.
c) Provide just one module, umath, and add a function to it that
allows disabling or enabling exceptions.
d) Remove the import from Numeric and leave it to the user. The few
routines actually used in Numeric/Core.py could be taken from
umath, since they are not speed critical.
c) would be closest to the way most C/Fortran/whatever floating-point
libraries work. But it would also be restrictive, since one could not
easily have exceptions for, say, square roots while disabling them for
logarithms. b) would be little effort, but not evident and therefore
error-prone. a) is too messy for my taste. Which leaves d) as my
personal favourite. Note that everyone is free to define his/her
personal module that imports everything from Numeric and
umath/fast_umath, and to prevent name proliferation we could even
provide two such modules with the standard distribution (coming close
again to solution a) without its drawback of code duplication).
The default question arises only with solution b). In this case, I
strongly favour umath as the default. According to the principle of
least surprise, everything should work as usual in Python, and the
decision to give up exceptions for the sake of speed should be a
conscious decision of the user, not a default imposed by someone's
personal preferences.
And now you can all wake up, I am finished. Any comments?
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-76.88.54.94
41, Ave. 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 dubois1@llnl.gov Mon Sep 16 17:49:02 1996
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Mon, 16 Sep 1996 09:49:02 -0700
Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
Message-ID: <9609161648.AA03947@icf.llnl.gov.llnl.gov>
I certainly thought we had all agreed that at least the default behavior was
that a floating point exception or math routine exception was caught
immediately.
It is impossible to debug a large code otherwise. We don't have a single
production code at LLNL which is willing to end up with the answer NaN two
days later.
----------
> From: Konrad Hinsen <hinsen@ibs.ibs.fr>
> To: matrix-sig@python.org
> Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
> Date: Monday, September 16, 1996 10:18 AM
>
> There are a couple of issues that I think ought to be discussed
> before moving from alpha to beta status:
>
> 1) The package system.
> ----------------------
>
> Although a good idea, I dislike it more and more after using it for a
> while. Not only does it need the mysterious "import ni", whose meaning
> is evident neither from its name nor from the way it is used, but it
> also introduces unwelcome surprises. For example, "from Numeric
> import *" doesn't work any more, even after "import ni", importing
> anything specific poses no problem ("from Numeric import
> array"). Sure, I can resort to "from Numeric.Core import *", but
> that's more complicated (think about interactive use) and less
> clear. How am I supposed to explain to a newbie (who just learned who
> wonderfully consistent Python is) that getting all functions from
> Numeric involves
> import ni; from Numeric.Core import *
> although no object from "ni" is never used and "Numeric.Core" occurs
> in no other context?
>
> So let's look at the alternatives:
>
> a) No packages. We could then have suggestive names, e.g.
> "Numeric_FFT" for the submodules. Of course that supposes
> that long module names can safely be used on all systems.
>
> b) Simulate the module behaviour in a different way. One idea I had
> is to define a class (untested, of course ;-)
>
> class Submodule:
>
> def __init__(self, name, base):
> self.name = name
> self.base = base
> self.module = None
>
> def __getattr__(self, name):
> if self.module is None:
> module_name = self.base + self.name
> exec 'import ' + module_name
> self.module = eval(module)
> return getattr(self.module, name)
>
> Then Numeric.py would contain, for example,
>
> FFT = Submodule('FFT', 'N_')
>
> and any reference to Numeric.FFF.x would import N_FFT and
> return object x from it, which could then be assigned at
> will or of course used directly. If performance is considered
> a problem, one could transfer all the names from the freshly
> loaded module into the submodule object for direct access.
> This would give most of the package functionality, except
> it is impossible to import a submodule directly - which in
> our case doesn't make much sense anyway.
>
>
> 2) The umath module.
> --------------------
>
> The original idea was to have two versions of this module: one, umath,
> would behave just like any decent Python program and raise exceptions
> for floating point errors, and the other, fast_umath, would for the
> sake of speed just return whatever the floating point code (or
> processor) produces. Since Jim is a speed fanatic, he has concentrated
> on fast_umath to the point that umath is not even compiled in the
> standard distribution. Still I think that there will be no disagreement
> about the need for both in an official distribution.
>
> However, there are additional problems caused by the fact that
> routines from umath are used in Numeric (to be precise, all items from
> umath are provided by Numeric, and some are used in other functions,
> e.g. add.reduce). This raises two questions:
>
> a) How can the user select between umath and fast_umath?
> b) Which should be the default?
>
> Right now, "fast_umath" is hard-coded into Numeric/Core.py, which is
> probably the worst solution. The alternatives I can think of are
>
> a) Have two separate modules, "Numeric" and "Fast_numeric". A bit
> wasteful, even more so in the presence of packages.
> b) Selection via a variable or function in module sys.
> c) Provide just one module, umath, and add a function to it that
> allows disabling or enabling exceptions.
> d) Remove the import from Numeric and leave it to the user. The few
> routines actually used in Numeric/Core.py could be taken from
> umath, since they are not speed critical.
>
> c) would be closest to the way most C/Fortran/whatever floating-point
> libraries work. But it would also be restrictive, since one could not
> easily have exceptions for, say, square roots while disabling them for
> logarithms. b) would be little effort, but not evident and therefore
> error-prone. a) is too messy for my taste. Which leaves d) as my
> personal favourite. Note that everyone is free to define his/her
> personal module that imports everything from Numeric and
> umath/fast_umath, and to prevent name proliferation we could even
> provide two such modules with the standard distribution (coming close
> again to solution a) without its drawback of code duplication).
>
> The default question arises only with solution b). In this case, I
> strongly favour umath as the default. According to the principle of
> least surprise, everything should work as usual in Python, and the
> decision to give up exceptions for the sake of speed should be a
> conscious decision of the user, not a default imposed by someone's
> personal preferences.
>
>
> And now you can all wake up, I am finished. Any comments?
>
> Konrad.
> --
>
------------------------------------------------------------------------------
-
> Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
> Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
> Institut de Biologie Structurale | Fax: +33-76.88.54.94
> 41, Ave. des Martyrs | Deutsch/Esperanto/English/
> 38027 Grenoble Cedex 1, France | Nederlands/Francais
>
------------------------------------------------------------------------------
-
>
> =================
> MATRIX-SIG - SIG on Matrix Math for Python
>
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Mon Sep 16 17:55:18 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 16 Sep 1996 12:55:18 -0400
Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
Message-ID: <9609161653.AA01978@goldilocks.LCS.MIT.EDU>
> There are a couple of issues that I think ought to be discussed
> before moving from alpha to beta status:
>
> 1) The package system.
>
I'll leave discussion of this one to others.
> 2) The umath module.
> --------------------
A couple of comments here.
1) fast_umath behavior WILL be the default. I just don't feel like
compromising on this one.
2) I'd like to make life as easy as possible for people who want umath
exceptions.
Regarding 2, I just looked at that code again and had an interesting idea:
error checking behavior is an attribute of the ofuncs. Each ofunc has this
attribute set seperately.
Exposing this attribute at the python level would be trivial.
It would then be easy to write the following:
for f in Numeric.umath:
try:
f.error_check = 1
except(AttributeError):
pass
This would turn on error checking for all of the functions in
Numeric.umath. This would not involve global variables or any similar
evils.
This does allow things like having error checking on sqrt, but not on log.
It also allows a function to say:
if sqrt.error_check: do something with errors
else: do something different
The problem (feature?) I see here is that it will change the behavior of
every instance of sqrt. If I have a function that depends on sqrt not
doing this error check and you have one that does depend on it then there
could be problems (I can't actually think of any cases where this would be
a problem in well written code...)
Just trying to provide fuel to the discussion - Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Mon Sep 16 20:06:12 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 16 Sep 96 20:06:12 +0100
Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
In-Reply-To: <9609161653.AA01978@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609161808.UAA26997@ibs.ibs.fr>
> A couple of comments here.
>
> 1) fast_umath behavior WILL be the default. I just don't feel like
> compromising on this one.
Can you give a good argument for this? I just can't think of any.
Turning off exceptions is clearly an optimization feature. Optimization
should never take precedence over safety by default.
> This would turn on error checking for all of the functions in
> Numeric.umath. This would not involve global variables or any similar
> evils.
In a sense the state of the flag in each function *is* a global
variable, so it involves the same evil.
> The problem (feature?) I see here is that it will change the behavior of
> every instance of sqrt. If I have a function that depends on sqrt not
> doing this error check and you have one that does depend on it then there
> could be problems (I can't actually think of any cases where this would be
> a problem in well written code...)
Why not? Think of two library modules written by different people.
I can imagine many applications for code that requires exceptions - my
impression is that dealing with exceptions is a general programming
strategy in Python, not just a way to deal with extreme cases. In fact,
I have some of my own code that relies on acos raising an exception for
arguments larger than 1.
It is more difficult to think of code that logically requires the
absence of exceptions, but of course there might be plenty of code
that requires the absence of exceptions to be acceptably fast. Such
code - in a library - would presumably switch off exceptions during
initialization and thereby ruin code that depends on them.
So I think having both versions simultaneously is important, and
besides easily doable in Python. The problem is where to put the
decision.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 Rob.Hooft@embl-heidelberg.de Mon Sep 16 20:00:52 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Mon, 16 Sep 1996 21:00:52 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
In-Reply-To: <199609161808.UAA26997@ibs.ibs.fr>
References: <9609161653.AA01978@goldilocks.LCS.MIT.EDU>
<199609161808.UAA26997@ibs.ibs.fr>
Message-ID: <199609161900.VAA17293@nu>
Just to help tip the balance here: I agree 100% percent with Konrad.
The original situation where there was a choice of importing fast or
correct routines was very nice, and I can see many applications where
I would use both. And I also think that if there needs to be a default
it is much better to have it "safe". You might remember from earlier
postings that I am a speed devil, but I don't think that is the right
attitude for the general public.
We might want to have 3 versions: fast_umath, umath, and
default_umath. In that case if you're writing a library routine that
can work with fast as well as correct versions, the user of the
library routine can still have the choice.
Rob.
--
=== Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux! Free Software Rules The World! =============
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From tim@lassi.ece.uiuc.edu Mon Sep 16 22:37:53 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Mon, 16 Sep 1996 16:37:53 -0500
Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
In-Reply-To: <199609161620.SAA26543@ibs.ibs.fr> (message from Konrad Hinsen on
Mon, 16 Sep 96 18:18:36 +0100)
Message-ID: <199609162135.RAA21280@python.org>
Some questions/comments on umath vs. fast_umath:
1) Is the use of umath vs. fast_umath going to affect the packages,
e.g. LinearAlgebra, or can they be assumed to take care of themselves?
More concretely, if I write:
import Numeric
<Magic incantation to select umath or fast_umath>
LA = Numeric.LinearAlgebra
Is my choice of umath or fast_umath going to percolate down to
LinearAlgebra? I would guess that LinearAlgebra should be able to
decide for itself if it should run safe or fast. And, if necessary
expose the choice through something like LA.playSafe() or
LA.runWithScissors() (I mean LA.runFast(), sorry ;).
If my choice does NOT affect the packages, the why not substitute
'Fast' and 'Safe' for 'Core'. This way there would be no default - so
we'd all automatically agree, and it would always be obvious whether
you were using the fast or the safe routines.
2) I forget what I was going to say here... Sorry
--
-tim
+--------------------------------------------------------------------+
| Tim Hochberg Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu University of Illinois |
| http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 |
+--------------------------------------------------------------------+
=================
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 Tue Sep 17 10:43:50 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 17 Sep 96 10:43:50 +0100
Subject: [PYTHON MATRIX-SIG] NumPy 1.0a3
In-Reply-To: <199609162135.RAA21280@python.org> (tim@lassi.ece.uiuc.edu)
Message-ID: <199609170845.KAA28950@ibs.ibs.fr>
> 1) Is the use of umath vs. fast_umath going to affect the packages,
> e.g. LinearAlgebra, or can they be assumed to take care of themselves?
Like any other module, LinearAlgebra decides for itself which, if
any, of the umath modules to import. Currently the three choices
are:
1) umath
2) fast_umath
3) Numeric (i.e. indirectly fast_umath)
As it is, LinearAlgebra uses Numeric, which it needs anyway for
functions like transpose(). In this particular case it doesn't matter,
since the only float operation used is "equal", which doesn't raise
exceptions anyway.
In general, I think the library author should decide which umath
version to use. Using the "default" is a bad idea (and I am more
and more convinced that the mere existence of a "default" is a
bad idea). The library author is the only person who can decide
whether speed is critical, whether exceptions can occur, and what
is necessary to deal with them.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 busby@icf.llnl.gov Wed Sep 18 02:06:00 1996
From: busby@icf.llnl.gov (L. Busby)
Date: Tue, 17 Sep 96 18:06:00 PDT
Subject: [PYTHON MATRIX-SIG] Ruminations on SIGFPE
Message-ID: <9609180106.AA04842@icf.llnl.gov.llnl.gov>
Dear Readers,
I have lately been thinking about SIGFPE and python. At the June
Python Workshop during the Wishlist discussion, I volunteered (in
absentia) to do the following little piece of work:
Provide (conditional) code to generate SIGFPE on a variety of Unix
workstations. Quite important for large scale numerical analysis.
Basis and Yorick can provide example code. If you don't do this,
you eventually waste expensive computer time filling a large
dumpfile with NaNs.
A) The Easy Part
At the present time, python pretty much uses the default state of the
hardware floating point unit to dictate its behavior with respect to
floating point errors. Here's a quick example from python running on
Sparc hardware, Solaris 2.4:
>>> x = 1e160*1e160
>>> x
Infinity
>>> x-x
NaN
The multiplication generated an IEEE 754 Overflow error, since the
product exceeds the largest representable 64 bit value of around
1.8e308. "X-x" is an IEEE Invalid Operation and results in the NaN (Not
a Number). If your FPU defaults to generating SIGFPE when these things
happen (I believe Linux on Intel does), you will have gotten a core
dump at the Overflow. Incidentally, the python interpreter does a good
job of catching the most common IEEE error, Division by 0, but it can't
do everything, and it can't possibly catch errors in an extension
module (such as the Numeric module). Extension modules should
certainly be written to trap their own errors insofar as reasonable,
but - well, that's what exception handlers are for.
The wishlist item proposes to add setup code to python so that the FPU
*will* generate SIGFPE when IEEE errors occur. This is certainly a
Good Thing when your code would otherwise waste hours and hours
producing reams of absurd results. It is much less good in an
interactive situation - funny thing how the same users who complain
about wasting time in their batch jobs are the first to scream if their
interactive session dumps core unexpectedly.
I think this is fairly non-controversial so far. A new routine or two
can be implemented in an "fpu_control" module, to turn on or off SIGFPE
generation at the user's discretion. It may possibly need to be
statically loaded, but it won't otherwise change python in any way.
I'll work on that and have it ready Real Soon Now.
B) The Hard Part
There is a harder question with respect to the handling of SIGFPE.
What I have outlined so far gives you two options, instead of just one:
1) Either you suffer the NaNs, Infinities and Db0s, or
2) You suffer core dumps.
Outside of an unattended batch situation as discussed above, I would
*prefer* to suffer neither. That is, I would like my python-enhanced
number cruncher to tell me a floating point problem had happened, then
recover so that I might try the operation again with different
parameters. While I'm dreaming, I would also prefer to be informed
*immediately*, rather than waiting until my program finishes inverting
that 1000 X 1000 matrix.
Achieving these preferences is not impossible, but it appears that it
would require a rather fundamental change in the way that python
handles signals. At the present time, python handles (practically all)
signals in a uniform way, by noting their delivery and then deferring
further action until the end of the current virtual instruction. This
has the great advantage that signal handling and signal handlers can be
lifted up out of compiled code and into the interpreter. It may have
further advantages in simplifying the handling of threaded code, and it
seems to contribute to a simple, clean design for error handling and
the python parser. I like it.
However, the model cannot handle "synchronous" signals such as SIGFPE.
(If you provide a non-default handler for SIGFPE, you will have a
guaranteed infinite loop when an error occurs.) The only method I know
for really handling SIGFPE would flush the current virtual instruction,
perhaps with a traceback to show where the error occurred, then restart
the parser (typically with a longjmp) at the next line of input. As
far as I know, this can't be done in interpreted code. It really looks
like a serious change to me.
So for the moment I'm stuck on Part B. I need to understand the
requirements of Python numerical users better, and I need to understand
the context in which the current Python signal handling model was
developed - what is sacred, etc. I am probably limited by my lack of
knowledge or imagination in solving this problem. In any case, I would
appreciate hearing from the Matrix SIG and Python developers about
this matter.
Thanks for your attention - Lee.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From jac@gandalf.llnl.gov Wed Sep 18 04:31:39 1996
From: jac@gandalf.llnl.gov (James Crotinger)
Date: Tue, 17 Sep 96 20:31:39 PDT
Subject: [PYTHON MATRIX-SIG] Ruminations on SIGFPE
In-Reply-To: <9609180106.AA04842@icf.llnl.gov.llnl.gov>
References: <9609180106.AA04842@icf.llnl.gov.llnl.gov>
Message-ID: <9609180331.AA09805@gandalf.llnl.gov>
Lee, while I do agree that we need at least the same capability for
catching FPEs as we have in Basis (i.e. trapping them and returning
control to the parser), under Python I would think there would be room
for improvement (I've often wished that I couild intercept SIGFPEs
with Basis code). I haven't thought it through (and really know pretty
much nothing about Python's exception handling), but wouldn't the
ideal arrangement be for SIGFPE's to result in a thrown exception. The
default handler could print a traceback and pop you back to the parser
(or could go into a recursive parser state, like the "debugger" stuff
I added to Basis).
>From your message, I suspect that the problem is that this type of
handling would have to occur at the level of the python virtual
machine, and this may be the problem. For example, waiting for a
timestep to finish in a simulation code that is doing all of its work
in compiled code would probably not be acceptable. This could be
handled by something like the "ruthere" call in Basis (Basis traps
SIGINT and sets a state flag; compiled routines can call "ruthere" and
if SIGINT has been raised, the interrupt is handled - this way SIGINT
only interrupts compiled modules at places where the module writer
wants it to be interrupted).
Jim
=================
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 Wed Sep 18 10:32:50 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 18 Sep 96 10:32:50 +0100
Subject: [PYTHON MATRIX-SIG] Ruminations on SIGFPE
In-Reply-To: <9609180106.AA04842@icf.llnl.gov.llnl.gov> (busby@icf.llnl.gov)
Message-ID: <199609180834.KAA04172@ibs.ibs.fr>
> So for the moment I'm stuck on Part B. I need to understand the
> requirements of Python numerical users better, and I need to understand
> the context in which the current Python signal handling model was
> developed - what is sacred, etc. I am probably limited by my lack of
> knowledge or imagination in solving this problem. In any case, I would
> appreciate hearing from the Matrix SIG and Python developers about
> this matter.
I don't know much about how Python handles signals, but I do know that
as a user I'd vastly prefer a Python exception to both NaNs and core
dumps.
If I understand you correctly, there would be no problem in having
Python raise an exception at the end of the next virtual instruction,
which would be sufficient for operations that don't take much time.
Maybe potentially costly operations (such as matrix inversions) ought
to provide their own exception handlers.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 da@maigret.cog.brown.edu Wed Sep 18 19:03:53 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 18 Sep 1996 14:03:53 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Statistics and file formats
Message-ID: <199609181803.OAA06915@maigret>
Hi all.
1) I need access to some statistics, such as t-tests, ANOVA's, etc. Is
there a commonly accepted library which provides a simple API to
such functions?
2) I'm considering using netCDF as the file format for some tools I'm
building. There are alternatives, however, such as HDF. My
interest in these is a standardized way of having self-describing
data, not the ability to handle very large datasets (that doesn't
happen with my data). Is there a consensus out there which I should
be aware of? I've also looked a little at some of the tools that
Paul mentioned, such as SILO/SLIDE. I have no good basis on which
to make one decision or another (except that there is a netcdf
module out there, although it appears to do 1-D data only for now).
I'd appreciate any info on either of these topics.
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Wed Sep 18 19:45:41 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 11:45:41 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609181845.LAA00553@phoebe.geog.ubc.ca>
I am using arrayobject.h to write some extensions with arrays and
I was wondering how you refer to elements of an array; for example,
how would I get a[i,j,k]?
Thanks,
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From phil@geog.ubc.ca Thu Sep 19 03:11:55 1996
From: phil@geog.ubc.ca (Phil Austin)
Date: Wed, 18 Sep 1996 19:11:55 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] Statistics and file formats
In-Reply-To: <199609181803.OAA06915@maigret>
References: <199609181803.OAA06915@maigret>
Message-ID: <199609190211.TAA00677@coot.geog.ubc.ca>
>>>>> "David" == David Ascher <da@maigret.cog.brown.edu> writes:
David> 2) I'm considering using netCDF as the file format for some
David> tools I'm building. There are alternatives, however, such
David> as HDF. My interest in these is a standardized way of
David> having self-describing data, not the ability to handle very
David> large datasets (that doesn't happen with my data). Is
David> there a consensus out there which I should be aware of?
David> I've also looked a little at some of the tools that Paul
David> mentioned, such as SILO/SLIDE. I have no good basis on
David> which to make one decision or another (except that there is
David> a netcdf module out there, although it appears to do 1-D
David> data only for now).
We have to support both HDF and netcdf interfaces for satellite
and aircraft data, and my impressions of the two are:
1) HDF is more flexible (Vdata allows pointer-like structures
that netCDF doesn't)
2) Netcdf is much better documented, and there are more browsers,
etc., written for it. (as evidenced by the respective home pages).
Netcdf also has Splus, Matlab, C++, perl, and java (this one
read-only) interfaces.
3) NASA has adopted HDF in a big way. They have been funding
convergence of the two formats via a netCDF interface in HDF, at a
cost in (HDF) efficiency. NOAA and NCAR (obviously) prefer netCDF.
There is a new netCDF version being tested now that makes some
significant API changes (and doubles the speed of netCDF)--I don't
know whether the NCSA HDF developers are committed to tracking these
changes.
Since we are doing plain packed n-dimensional arrays we have
focussed on netCDF. Kyle Schalm, a co-op student working with me on
Python image processing, is currently adding Numeric arrays to William
Noon's package, he should have a beta version in a week or two.
Regards, Phil
Phil Austin INTERNET: phil@geog.ubc.ca
(604) 822-2175 FAX: (604) 822-6150
http://www.geog.ubc.ca/~phil
Associate Professor
Atmospheric Sciences Programme
Geography #217
University of British Columbia
1984 W Mall
Vancouver, BC V6T 1Z2
CANADA
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Thu Sep 19 03:36:01 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 18 Sep 1996 19:36:01 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609190236.TAA01770@dragon.geog.ubc.ca>
>Please stop posting the same message over and over again!!
I'm not! I sent this message to the mailing list, hours ago...
once... I'm not sure what's up?!
Kyle
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From guido@CNRI.Reston.Va.US Thu Sep 19 03:32:31 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Wed, 18 Sep 1996 22:32:31 -0400
Subject: [PYTHON MATRIX-SIG] Ruminations on SIGFPE
In-Reply-To: Your message of "Tue, 17 Sep 1996 18:06:00 PDT."
<9609180106.AA04842@icf.llnl.gov.llnl.gov>
References: <9609180106.AA04842@icf.llnl.gov.llnl.gov>
Message-ID: <199609190232.WAA01533@monty>
This sounds like a good start.
Python's current signal handling is really intended for async signal
handling only. Since SIGFPE is an exception to most rules about
signals anyway, I don't mind making an exception for it, provided it
can be done fairly portably or disabled easily.
I would think that in order to catch most FP exceptions in *Python*
code, modifications to a small number of files would suffice; you
could start with floatobject.c and complexobject.c, and then add
mathmodule.c and cmathmodule.c and be done with most of it.
I'd expect that the modification could look roughly like this:
- The interface is based on controlled use of setjmp/longjmp.
- Somewhere globally, set a signal handler for SIGFPE.
- Before invoking some code that could raise SIGFPE, you declare a
setjmp buffer and call setjmp(). You then set a global variable
that points to the setjmp buffer. (All this could be done in a macro
so it's easily disabled.) When the code returns safely, you zap the
global pointer variable.
- The SIGFPE handler, when invokes, sees if this global variable is
set. If so, it longjmps there. If not, it should emulate the current
behavior (NaN or core dump -- perhaps a call to
PyErr_Fatal("unhandled FPE") is the thing to do).
- If the longjmp is done, the code invoking the unsafe code should zap
the global pointer variable as before, clean up, and raise a Python
exception (usually this done through a call to PyErr_Set*() and
returning NULL).
Unfortunately this looks like a lot of work. I expect that a few
macros could be developed so that e.g. fload_add() could changed from
static object *
float_add(v, w)
floatobject *v;
floatobject *w;
{
return newfloatobject(v->ob_fval + w->ob_fval);
}
to
static object *
float_add(v, w)
floatobject *v;
floatobject *w;
{
double result;
PyFPE_MAGIC_PREP(return NULL)
result = v->ob_fval + w->ob_fval;
PyFPE_MAGIC_DONE
return newfloatobject(result);
}
Roughly, PyFPE_MAGIC_PREP(leave_stmt) should expand to
{
jmp_buf b;
void *save = PyFPE_JumpBufPtr;
if (setjmp(b)) {
PyFPE_JumpBufPtr = save;
PyErr_SetString(PyExc_FloatingPointException, "...");
leave_stmt;
}
PyFPE_JumpBufPtr = &b;
(note unmatched brace -- see next macro) and PyFPE_MAGIC_DONE should
expand to
PyFPE_JumpBufPtr = save;
}
Note that this takes care of nested invocations through the 'save'
variable.
Some problems with this:
- the type of PyFPE_JumpBufPtr is problematic
- it's rather a lot of overhead for a single f.p. add, therefore it
probably should be an option (on the other hand, there's already a lot
of overhead in any single float operation in Python, e.g. the
newfloatobject() call does a malloc(), etc.)
- it's a lot of changes to get this right.
- I don't have the time to write this code (though I will accept it as
a patch for 1.5).
Hope this helps,
--Guido van Rossum (home page: http://www.python.org/~guido/)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Thu Sep 19 14:11:12 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 19 Sep 1996 09:11:12 -0400
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <9609191308.AA10424@goldilocks.LCS.MIT.EDU>
I'd really like to know what happened to cause this message to get bounced
to the list so many times. Kyle, if you hear anything from your sysadmins
that suggests it might have happened on your end, please let me know.
Anyway...
There are three approachs to this problem. The first two are easiest, but
involve copying on discontiguous arrays, and can not be used to modify an
arbitrary array in-place.
1) Use PyArray_As[1,2,3]D to get the data in the array into an appropriate
C pointer. Then you can access elements as a[i][j][k].
2) Use PyArray_ContiguousFromObject and do your own math to determine the
location of any given element.
3) Define macros similar to the following:
#define Index1f(a, i) *(float *)(a->data + a->strides[0]*i)
#define Index2f(a, i, j) *(float *)(a->data + a->strides[0]*i +
a->strides[1]*j)
...
If enough people want macros like this and can agree on the best notation,
I'll add them to arrayobject.h
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Fri Sep 20 15:37:05 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 20 Sep 1996 10:37:05 -0400
Subject: [PYTHON MATRIX-SIG] Open Issues (packages, umath, ...)
Message-ID: <9609201434.AA26865@goldilocks.LCS.MIT.EDU>
There are two open issues that need to be resolved before the alpha5
release can go out. I'd be tempted to say that these are the only
remaining issues before a beta release (except for cleaner installs on all
the platforms out there). These are handling errors in umath functions and
use/disuse of packages.
1) umath
I've decided to be reasonable on this issue (well, I guess I just got
intimidated by all the knowledgable people who disagreed with me). Here's
my current proposal:
Numeric will do "import umath". Note: it will not do "from umath import
*".
This means that the safe version of the math functions will be used by
default. On the other hand, you won't be able to type: Numeric.log(1.0)
anymore, this will now look like Numeric.umath.log(1.0) [or any other way
you care to import this module into your namespace].
If you want to change the functions used internally by Numeric, you can
just do Numeric.umath = fast_umath (I hope this actually works...).
I think this scheme makes sense and should make most everybody happy.
Nonetheless, there's an outstanding problem that reveals my ignorance (and
is probably the secret reaons that I've been avoiding umath recently).
Currently, the safe version of umath does two checks:
1) It tests to see if "errno != 0" which will tell if any of the math
library routines raised an error. This is obviously an extremely fast
test.
2) It iterates over all of the elements in the array to make sure that they
have legal values (-Infinity < x < Infinity). This is obviously the slow
part of this process. This second part of the check is also hard to
implement portably. Look at the code for the CHECK macro at the top of
ofuncobject.c to see how I'm currently doing it.
So, my questions are, am I doing the right thing here for the safe version
of umath? Should the two saftely options be split apart so that we now
have three modules with different levels of error checking?
2) packages
I think that the benefits of packages are obvious. I'm just not sure that
they are currently mature enough to be used in a system that already has
enough complications of its own.
Konrad has already brought up a number of complaints about the package
system. I'd like to add a few of my own:
1) On my Unix platform (Solaris on a PentiumPro) "import ni" takes about
1.0 seconds. This is a fairly annoying addition to the startup time of
some of my simpler scripts. I find it particularly annoying when I try and
run my "numpy" calculator which basically starts up a python interpreter
and does "from Numeric import *". Interestingly enough, on this same
system I can import all of the modules in the Numeric package (including
the huge LinearAlgebra module) in far less time than I can import ni.
2) "import ni" is just an ugly thing to have at the top of all my files.
Have other people had different experiences using the package system with
alpha4? Good or bad?
-Jim
=================
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 Sep 20 17:14:51 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 20 Sep 96 17:14:51 +0100
Subject: [PYTHON MATRIX-SIG] Fortran I/O
Message-ID: <199609201516.RAA03340@ibs.ibs.fr>
Here's something for those poor fellows who have to deal with Fortran
programs: Fortran-style I/O in Python. It should be considered a beta
release, since no one by myself has tested it. I'd welcome any
comments and suggestions.
Konrad.
---------------------------------------------------------------------------
-- FortranFormat.py -------------------------------------------------------
---------------------------------------------------------------------------
# This module defines a class that handles I/O using
# Fortran-compatible format specifications.
#
#
# Warning: Fortran formatting is a complex business and I don't
# claim that this module works for anything complicated. It knows
# only the most frequent formatting options. Known limitations:
#
# 1) Only A, D, E, F, G, I, and X formats are supported (plus string constants
# for output).
# 2) No direct support for complex numbers. You have to split them into
# real and imaginary parts before output, and for input you get
# two float numbers anyway.
#
#
# Written by Konrad Hinsen <hinsen@ibs.ibs.fr>
# last revision: 1996-9-20
#
"""Fortran-compatible input/output
This module provides two classes that aid in reading and writing
Fortran-formatted text files. Only a subset of formatting options
is supported: A, D, E, F, G, I, and X formats, plus string constants
for output. Repetition (e.g. 4I5 or 3(1X,A4)) is supported. Complex
numbers are not supported; you have to treat real and imaginary parts
separately.
Examples:
=========
Input:
------
>> s = ' 59999'
>> format = FortranFormat('2I4')
>> line = FortranLine(s, format)
>> line[0]
5
>> line[1]
9999
Output:
-------
>> format = FortranFormat('2D15.5')
>> line = FortranLine([3.1415926, 2.71828], format)
>> line.text
' 3.14159D+00 2.71828D+00'
The second argumet to FortranLine can be a format object or a
string (that is then converted into a format object). If the
same format is to be used several times, it is more efficient
to convert it into a format object once - parsing the format
string is a relatively expensive operation.
"""
import string
#
# The class FortranLine represents a single line of input/output,
# which can be accessed as text or as a list of items.
#
class FortranLine:
def __init__(self, line, format, length = 80):
if type(line) == type(''):
self.text = line
self.data = None
else:
self.text = None
self.data = line
if type(format) == type(''):
self.format = FortranFormat(format)
else:
self.format = format
self.length = length
if self.text is None:
self._output()
if self.data is None:
self._input()
def __len__(self):
return len(self.data)
def __getitem__(self, i):
return self.data[i]
def __getslice__(self, i, j):
return self.data[i:j]
def isBlank(self):
return len(string.strip(self.text)) == 0
def _input(self):
text = self.text
if len(text) < self.length: text = text + (self.length-len(text))*' '
self.data = []
for field in self.format:
l = field[1]
s = text[:l]
text = text[l:]
type = field[0]
value = None
if type == 'A':
value = s
elif type == 'I':
s = string.strip(s)
if len(s) == 0:
value = 0
else:
value = string.atoi(s)
elif type == 'D' or type == 'E' or type == 'F' or type == 'G':
s = string.strip(s)
if len(s) == 0:
value = 0.
else:
value = string.atof(s)
if value is not None:
self.data.append(value)
def _output(self):
data = self.data
self.text = ''
for field in self.format:
type = field[0]
if type == "'":
self.text = self.text + field[1]
elif type == 'X':
self.text = self.text + field[1]*' '
else: # fields that use input data
length = field[1]
if len(field) > 2: fraction = field[2]
value = data[0]
data = data[1:]
if type == 'A':
self.text = self.text + (value+length*' ')[:length]
else: # numeric fields
if type == 'I':
s = `value`
elif type == 'D':
s = ('%'+`length`+'.'+`fraction`+'e') % value
n = string.find(s, 'e')
s = s[:n] + 'D' + s[n+1:]
elif type == 'E':
s = ('%'+`length`+'.'+`fraction`+'e') % value
elif type == 'F':
s = ('%'+`length`+'.'+`fraction`+'f') % value
elif type == 'G':
s = ('%'+`length`+'.'+`fraction`+'g') % value
else:
raise ValueError, 'Not yet implemented'
s = string.upper(s)
self.text = self.text + ((length*' ')+s)[-length:]
#
# The class FortranFormat represents a format specification.
# It ought to work for correct specifications, but there is
# little error checking.
#
class FortranFormat:
def __init__(self, format, nested = 0):
fields = []
format = string.strip(format)
while format and format[0] != ')':
n = 0
while format[0] in string.digits:
n = 10*n + string.atoi(format[0])
format = format[1:]
if n == 0: n = 1
type = string.upper(format[0])
if type == "'":
eof = string.find(format, "'", 1)
text = format[1:eof]
format = format[eof+1:]
else:
format = string.strip(format[1:])
if type == '(':
subformat = FortranFormat(format, 1)
fields = fields + n*subformat.fields
format = subformat.rest
eof = string.find(format, ',')
if eof >= 0:
format = format[eof+1:]
else:
eof = string.find(format, ',')
if eof >= 0:
field = format[:eof]
format = format[eof+1:]
else:
eof = string.find(format, ')')
if eof >= 0:
field = format[:eof]
format = format[eof+1:]
else:
field = format
format = ''
if type == "'":
field = (type, text)
else:
dot = string.find(field, '.')
if dot > 0:
length = string.atoi(field[:dot])
fraction = string.atoi(field[dot+1:])
field = (type, length, fraction)
else:
if field:
length = string.atoi(field)
else:
length = 1
field = (type, length)
fields = fields + n*[field]
self.fields = fields
if nested:
self.rest = format
def __len__(self):
return len(self.fields)
def __getitem__(self, i):
return self.fields[i]
if __name__ == '__main__':
f = FortranFormat("'!!',D10.3,F10.3,G10.3,'!!'")
l = FortranLine([1.5707963, 3.14159265358, 2.71828], f)
print l.text
---------------------------------------------------------------------------
-- end of FortranFormat.py ------------------------------------------------
---------------------------------------------------------------------------
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 da@maigret.cog.brown.edu Fri Sep 20 16:45:37 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 20 Sep 1996 11:45:37 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Open Issues (packages, umath, ...)
In-Reply-To: <9609201434.AA26865@goldilocks.LCS.MIT.EDU> from "Jim Hugunin" at Sep 20, 96 10:37:05 am
Message-ID: <199609201545.LAA17343@maigret>
> 1) umath
>
> I've decided to be reasonable on this issue (well, I guess I just got
> intimidated by all the knowledgable people who disagreed with me). Here's
> my current proposal:
>
> Numeric will do "import umath". Note: it will not do "from umath import
> *".
>
> This means that the safe version of the math functions will be used by
> default. On the other hand, you won't be able to type: Numeric.log(1.0)
> anymore, this will now look like Numeric.umath.log(1.0) [or any other way
> you care to import this module into your namespace].
>
> If you want to change the functions used internally by Numeric, you can
> just do Numeric.umath = fast_umath (I hope this actually works...).
>
> I think this scheme makes sense and should make most everybody happy.
Ugh. It seems cumbersome in 95% of cases -- in other words, a given
user is likely to want either umath or fast_umath most of the time.
Having to type .umath every time seems user-unfriendly.
Is there a setup which would let people do:
import Numeric
Numeric.log(1.0) [referring to Numeric.umath.log]
Numeric.makeFast()
Numeric.log(1.0) [referring to Numeric.fast_umath.log]
Numeric.makeSafe()
Numeric.log(1.0) [referring to Numeric.umath.log]
[with the .umath and .fast_umath ways still being there in case people
want .umath.log and .fast_umath.exp]
Alternatively:
import Numeric
Numeric.log(1.0) [referring to Numeric.umath.log]
import FastNumeric
Numeric = FastNumeric
Numeric.log(1.0) [referring to Numeric.fast_umath.log]
import SafeNumeric
Numeric = SafeNumeric
Numeric.log(1.0) [referring to Numeric.umath.log]
Or some such variant?
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Fri Sep 20 17:04:41 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 20 Sep 1996 12:04:41 -0400
Subject: [PYTHON MATRIX-SIG] Open Issues (packages, umath, ...)
Message-ID: <9609201602.AA27837@goldilocks.LCS.MIT.EDU>
> > 1) umath
> >
> > I've decided to be reasonable on this issue (well, I guess I just got
> > intimidated by all the knowledgable people who disagreed with me).
Here's
> > my current proposal:
> >
> > Numeric will do "import umath". Note: it will not do "from umath
import
> > *".
> >
> > This means that the safe version of the math functions will be used by
> > default. On the other hand, you won't be able to type:
Numeric.log(1.0)
> > anymore, this will now look like Numeric.umath.log(1.0) [or any other
way
> > you care to import this module into your namespace].
> >
> > If you want to change the functions used internally by Numeric, you can
> > just do Numeric.umath = fast_umath (I hope this actually works...).
> >
> > I think this scheme makes sense and should make most everybody happy.
>
> Ugh. It seems cumbersome in 95% of cases -- in other words, a given
> user is likely to want either umath or fast_umath most of the time.
> Having to type .umath every time seems user-unfriendly.
The way I envision this being used (and this is partially contingenent on
package choices in the future, is as follows:
import Numeric
import fast_umath
umath = fast_umath
umath.log(1.0)
ie. the math functions are moved to their own name-space and the access
through Numeric is not used in general.
Does this seem less cumbersome?
-Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Fri Sep 20 17:07:04 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 20 Sep 1996 12:07:04 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Open Issues (packages, umath, ...)
In-Reply-To: <9609201602.AA27837@goldilocks.LCS.MIT.EDU> from "Jim Hugunin" at Sep 20, 96 12:04:41 pm
Message-ID: <199609201607.MAA17420@maigret>
> The way I envision this being used (and this is partially contingenent on
> package choices in the future, is as follows:
>
> import Numeric
> import fast_umath
> umath = fast_umath
>
> umath.log(1.0)
>
> ie. the math functions are moved to their own name-space and the access
> through Numeric is not used in general.
>
> Does this seem less cumbersome?
Yes and no. I understand how to control which umath to use in my
modules, but how can I tell the LinearAlgebra package to use a different
umath than its default? Or is that not deemed a good idea?
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From kschalm@geog.ubc.ca Fri Sep 20 19:27:10 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Fri, 20 Sep 1996 11:27:10 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <199609201827.LAA07756@dragon.geog.ubc.ca>
I was wondering what C function gets called to return the array slices
when you type
>>> a[h:i, j:k]
(a is an array here). For plain old a[i:j] I assume __getslice__(self, i, j)
is called but for multiple slices I don't know. Also what would the type
of the argument(s) be? Similarly what function is called for assignments,
like
>>> a[h:i, j:k] = spam
thanks
Kyle
PS on a related note is there a Numerical C API tutorial or reference
out there? If not, is there any plan to have one? I would love to see
something like this :)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Fri Sep 20 19:44:49 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 20 Sep 1996 14:44:49 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] newbie question: accessing array elements
In-Reply-To: <199609201827.LAA07756@dragon.geog.ubc.ca> from "Kyle Schalm" at Sep 20, 96 11:27:10 am
Message-ID: <199609201844.OAA17709@maigret>
> PS on a related note is there a Numerical C API tutorial or reference
> out there? If not, is there any plan to have one? I would love to see
> something like this :)
There isn't one, but when I get around to rewriting the Python API
tutorial, I might as well do one for the C API. Till then, ask this
SIG.
Can't help you with your question right now, though. Probably
someone else will.
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Fri Sep 20 20:15:32 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 20 Sep 1996 15:15:32 -0400
Subject: Fw: [PYTHON MATRIX-SIG] newbie question: accessing array elements
Message-ID: <9609201913.AA00447@goldilocks.LCS.MIT.EDU>
----------
> From: Jim Hugunin <hugunin@mit.edu>
> To: Kyle Schalm <kschalm@geog.ubc.ca>
> Subject: Re: [PYTHON MATRIX-SIG] newbie question: accessing array
elements
> Date: Friday, September 20, 1996 2:40 PM
>
> > I was wondering what C function gets called to return the array slices
> > when you type
> >
> > >>> a[h:i, j:k]
>
> It's the function getitem, mapping semantics are used to support multiple
> slices (and multiple indices).
>
> The single argument in this case is a tuple of slice objects.
>
> This function was never intended to be called from C code, in general
it's
> fairly easy to do this sort of thing by hand if you understand the
> internals of the arrayobject structure.
>
> > PS on a related note is there a Numerical C API tutorial or reference
> > out there? If not, is there any plan to have one? I would love to see
> > something like this :)
>
> Well then , WTFM ;-)
>
> Seriously, I doubt I'm going to have time to do this. I'm much more
> concerned with documentation for the python code. People who are writing
> their own C code can be made to suffer a little bit more (because they're
> already suffering).
>
> -Jim
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Sat Sep 21 14:58:32 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sat, 21 Sep 96 14:58:32 +0100
Subject: [PYTHON MATRIX-SIG] Open Issues (packages, umath, ...)
In-Reply-To: <9609201434.AA26865@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609211300.PAA05775@ibs.ibs.fr>
> Numeric will do "import umath". Note: it will not do "from umath import
> *".
>
> This means that the safe version of the math functions will be used by
> default. On the other hand, you won't be able to type: Numeric.log(1.0)
> anymore, this will now look like Numeric.umath.log(1.0) [or any other way
> you care to import this module into your namespace].
The question is: who will use Numeric.umath? Obviously it would be
easier to import from umath or fast_umath directly. This leaves
Numeric.umath as a kind of "default" when the programmer wants
to leave the choice to the user. Fine with me - but I would not
recommend using Numeric.umath in any part of the standard library.
> 1) It tests to see if "errno != 0" which will tell if any of the math
> library routines raised an error. This is obviously an extremely fast
> test.
This makes sense only when a math library function was called, i.e. not
for addition etc.
> So, my questions are, am I doing the right thing here for the safe version
> of umath? Should the two saftely options be split apart so that we now
> have three modules with different levels of error checking?
No, the way it works now is the only combination that makes sense. The
point of umath is to catch all floating-point errors, irrespective of
how they are treated according to IEEE rules. In addition, there is no
sign of uniformity in different machines' treatment of errors.
> I think that the benefits of packages are obvious. I'm just not sure that
> they are currently mature enough to be used in a system that already has
> enough complications of its own.
I agree. I'd rather live without packages. In fact, that's what I am
already doing (I have put lib/python1.4/Numeric into PYTHONPATH and
put a copy of Core.py as Numeric.py into another directory in the
search path). The "ni" system is clearly experimental - if and when it
becomes an official part of Python, we can still move to packages.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 da@maigret.cog.brown.edu Tue Sep 24 19:42:07 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 24 Sep 1996 14:42:07 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] SWIGing HDF
Message-ID: <199609241842.OAA04064@maigret>
Is anyone else thinking about SWIGging an interface to HDF?
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From da@maigret.cog.brown.edu Fri Sep 27 19:09:06 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 27 Sep 1996 14:09:06 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] CGM to ??? converters
Message-ID: <199609271809.OAA18189@maigret>
This is not really Python related, but it seemed a good place to ask.
I'm using the gistmodule by Lee Busby, and my output format choices are
CGM and postscript. While I appreciate the advantages of CGM, I'm
looking for a way to get bitmap formats out as well (e.g. GIF, Jpeg,
whatever).
Currently the only way I can find is to do a screen capture. Does
anyone know of CGM -> bitmap conversion tools?
--david
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From cgw@pgt.com Fri Sep 27 21:03:44 1996
From: cgw@pgt.com (Charles G Waldman)
Date: Fri, 27 Sep 1996 16:03:44 -0400
Subject: [PYTHON MATRIX-SIG] CGM to ??? converters
In-Reply-To: Your message of "Fri, 27 Sep 1996 14:09:06 EDT."
<199609271809.OAA18189@maigret>
Message-ID: <9609272003.AA23151@reactor.pgt>
da@maigret.cog.brown.edu said:
> I'm using the gistmodule by Lee Busby, and my output format choices
> are CGM and postscript. While I appreciate the advantages of CGM,
> I'm looking for a way to get bitmap formats out as well (e.g. GIF,
> Jpeg, whatever).
> Currently the only way I can find is to do a screen capture.
You can use the Postscript output, and feed it through Ghostscript
to produce GIF, JPEG or PBM output formats.
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hugunin@mit.edu Sun Sep 29 19:56:04 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Sun, 29 Sep 1996 14:56:04 -0400
Subject: [PYTHON MATRIX-SIG] Plea for help! (ASAP)
Message-ID: <9609291900.AA09462@goldilocks.LCS.MIT.EDU>
I'd like to ask for help from everyone on this list who has used/is using
Numeric Python and has found it useful to them. I'm taking my Oral
Qualifying Exam here at MIT on Wednesday, October 2nd (yes, in three days).
I gave my practice talk on Friday and the one huge complaint I received
was that I didn't make it clear if the project was a success or not. This
is a serious enough problem it might lead to my failing this exam, which
would leave me looking for a real job where they weren't so friendly about
my spending substantial amounts of time working on free software.
I think that there are a number of you out there who would consider this
work a success (I know you're still waiting for the beta 1 release, but one
problem at a time please). I want to collect a list of short quotes from
people saying how this project has been useful to them.
I know that one is not supposed to ask for this sort of praise, but I'm
feeling a little bit desperate at the moment. Just look at this as a weird
variation on shareware fees. Instead of $50 for using NumPy, I'm asking
you to write a very short testimonial.
I apologize for my brashness, and as usual, thanks for your time - Jim
PS - Here's the sort of quote I'd give for myself:
"NumPy made it possible for me to build a far more flexible and powerful
speech recognition research system than would have been possible using any
other framework I've seen."
Jim Hugunin - Research Associate - MIT Laboratory for Compiuter Science
(the most impressive form of my title)
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From tim@lassi.ece.uiuc.edu Mon Sep 30 15:23:59 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Mon, 30 Sep 1996 09:23:59 -0500
Subject: [PYTHON MATRIX-SIG] Plea for help! (ASAP)
In-Reply-To: <9609291900.AA09462@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199609301420.KAA12935@python.org>
>I know that one is not supposed to ask for this sort of praise, but I'm
>feeling a little bit desperate at the moment. Just look at this as a weird
>variation on shareware fees. Instead of $50 for using NumPy, I'm asking
>you to write a very short testimonial.
"I work in computational electromagnetics, and one of the common
problems I have is writing programs to manipulate the files produced
by model-drawing packages such as PATRAN and FEMAP into a form
suitable for my use. Writing these filters in C++ is tedious, and
while using Python for this is a joy, ii is too slow for this
use. Numerical Python allows me the power and ease of coding in Python
without a significant sacrifice in speed over C++.
With Numerical Python, I can have my spam and eat it too."
--
-tim
+--------------------------------------------------------------------+
| Tim Hochberg Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu University of Illinois |
| http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 |
+--------------------------------------------------------------------+
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From Rob.Hooft@embl-heidelberg.de Mon Sep 30 20:58:04 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Mon, 30 Sep 1996 21:58:04 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] 1.0a4
Message-ID: <199609301958.VAA08899@nu>
I finally got around to compiling 1.0a4 this weekend. Seems to work
fine so far, but I have one note on the installation: ".c" files
of 600kB each take gcc quite a while to compile. The memory usage
for the compiler ran up to 65MB.... It might be better to cut these
files into smaller pieces.
And Jim: I have not made any big applications for NumPy yet, but I
regularly use it as part of my desk-calculator. Now that the standard
numeric fortran libraries are available as standard modules from
python, NumPy will enable me to use top-quality algorithms for quick
hacks. I definitely think the project is a big success. Getting the
abstractions right always takes longer than one thinks, certainly when
targeting such a diverse group of users as NumPy is doing!
Rob.
--
=== Rob.Hooft@EMBL-Heidelberg.DE http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling? http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures? http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux! Free Software Rules The World! =============
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================