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: Message-ID: 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 > 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: 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! # # . # ================= 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 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 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 > 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: 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 ================= 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: 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 > 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 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: 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 ================= 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: (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 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 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" |> To: "Guido van Rossum" |> |> 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: 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 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! # # . # ================= 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" To: , "Tom Schwaller" Cc: 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: 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: (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: References: <199609091002.MAA23833@ibs.ibs.fr> 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: 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 "", 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: 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! # # . # ================= 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." References: 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." References: <515kbm$538@news.udel.edu> <199609111237.IAA21035@monty> 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> <199609111237.IAA21035@monty> <199609122019.QAA29000@monty> Message-ID: <199609122052.WAA21032@nu> >>>>> "GvR" == Guido van Rossum 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: 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 "", 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: 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: 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 ; 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 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 Cc: David Ascher , Python Matrix SIG Message-id: 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 > 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 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 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 # 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 > To: Kyle Schalm > 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 =================