From hugunin@mit.edu  Mon Mar  3 18:48:40 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 3 Mar 1997 13:48:40 -0500
Subject: [PYTHON MATRIX-SIG] Incompatible change to dot (any objections?)
Message-ID: <01BC27D9.9A9035E0@misha.lcs.mit.edu>


Konrad Hinsen writes:
> I still think that it would be better to give Numeric.dot() the
> functionality of Numeric.matrixmultiply() and remove the latter (or
> keep it for compatibility, but not document it). There is no need for
> two functions, and many people will probably use dot() although what
> they need is matrixmultiply().

It's amazing to me that this has been an issue since the very beginning of 
the matrix-sig.  The problem seems to be that I have much more training in 
computer languages/systems than in linear algebra which gives me a slightly 
different (warped?) perspective on things.

Anyway, I'm finally willing to go along with Konrad on this one.  I intend 
to change dot in the next release to have the same functionality as 
matrixmultiply currently does.  This will give those linear algebra folks 
out there a nice easy way to multiply two matrices together "correctly".  I 
will also expose the lower level function "innerproduct" that currently 
behaves almost exactly like dot (no transposes involved).  I'd also like to 
get rid of the function "matrixmultiply", though I'd be willing to keep it 
around if people have concerns about backwards compatibility for their 
code.

-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 Mar  3 18:53:05 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 3 Mar 1997 13:53:05 -0500
Subject: [PYTHON MATRIX-SIG] Changes to diagonal and trace functions
Message-ID: <01BC27DA.38995D20@misha.lcs.mit.edu>


> I also still think that the generalized version of diagonal() and trace()
> that I posted a while ago would be more suitable than the current
> version that works only on rank-2 arrays. Here's my version again:
> <Real code removed>

I've always felt that these functions should be generalized to higher 
dimensions, but just never got around to it.  I am making the following 
changes to Konrad's implementation, best summarized by the new function 
prototypes.

def diagonal(a, offset=0, axis1=-2, axis2=-1):
def trace(a, offset=0, axis1=-2, axis2=-1):

This version has the advantage of being compatible with the current version 
of diagonal and trace, and also of behaving as I would normally expect for 
arrays of greater than two dimensions.

-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 Mar  3 19:37:22 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 3 Mar 1997 14:37:22 -0500
Subject: [PYTHON MATRIX-SIG] More repr vs. str issues - Please Read!
Message-ID: <01BC27E0.685C2C80@misha.lcs.mit.edu>


This repr vs. str discussion might seem esoteric, but it will affect the 
day to day interactions of everybody who works with NumPy.  Please do read 
the following and let me know if this will have a negative impact on your 
work.

After all of this discussion, I've decided that I don't like the current 
way that strings are displayed in Unix interpreters (which is good, because 
the way they are displayed only works because of a bug in my code which 
needs to be fixed one way or another).  I find that when I "really" want to 
know what an array looks like I'll usually type "repr(a)" anyway.  I also 
really like the current property that the repr of an array is something 
that can be typed into python to get an equivalent array back.

The problem with the current repr function is that it doesn't display the 
internal structure of the array which leaves out a lot of valuable 
information.  To fix all of these problems in one fell swoop ;-), I propose 
the following new behavior:

>>> from Numeric import *
>>> a = identity(10)
>>> a # same as repr(a)
array([[1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
       [0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
       [0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
       [0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
       [0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
       [0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
       [0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
       [0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
       [0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
       [0, 0, 0, 0, 0, 0, 0, 0, 0, 1]], 'l')

>>> print a # same as str(a)
1 0 0 0 0 0 0 0 0 0
0 1 0 0 0 0 0 0 0 0
0 0 1 0 0 0 0 0 0 0
0 0 0 1 0 0 0 0 0 0
0 0 0 0 1 0 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 0 1 0 0 0
0 0 0 0 0 0 0 1 0 0
0 0 0 0 0 0 0 0 1 0
0 0 0 0 0 0 0 0 0 1

>>>

I realize that this seems a little bit uglier than the current behavior 
(especially to those used to programs like matlab).  Nonetheless, I think 
that this behavior is much more "pythonesque".  I think that this new 
output notation will much better fit into the python world where everything 
is not in fact an array.

Let me know what you think - 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 Mar  3 19:42:37 1997
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Mon, 03 Mar 1997 14:42:37 -0500
Subject: [PYTHON MATRIX-SIG] Re: More repr vs. str issues - Please Read!
In-Reply-To: Your message of "Mon, 03 Mar 1997 14:37:22 EST."
 <01BC27E0.685C2C80@misha.lcs.mit.edu>
References: <01BC27E0.685C2C80@misha.lcs.mit.edu>
Message-ID: <199703031942.OAA06261@monty>

*I* like it!

--Guido

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From pas@xis.xerox.com  Mon Mar  3 20:30:45 1997
From: pas@xis.xerox.com (Perry A. Stoll)
Date: Mon, 3 Mar 1997 12:30:45 PST
Subject: [PYTHON MATRIX-SIG] More repr vs. str issues - Please Read!
In-Reply-To: <01BC27E0.685C2C80@misha.lcs.mit.edu>
Message-ID: <199703032030.PAA18589@fantod.xis.xerox.com>


> The problem with the current repr function is that it doesn't display the 
> internal structure of the array which leaves out a lot of valuable 
> information.  To fix all of these problems in one fell swoop ;-), I propose 
> the following new behavior:
> 
>>>> from Numeric import *
>>>> a = identity(10)
>>>> a # same as repr(a)
> array([[1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>        [0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
>        [0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
>        [0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
>        [0, 0, 0, 0, 0, 0, 0, 0, 0, 1]], 'l')

Will repr format it as above, i.e. including the newlines? Currently
it returns a single string without newlines, basically nullifying an
easy scan of the internal structure. 

# currently, repr does this: 
>>> repr(a)
"array([[1, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 1, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 1, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 1, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 1, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 1, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 1, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 1, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 1, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 1]], 'l')"

-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 Mar  3 20:40:15 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 3 Mar 1997 15:40:15 -0500
Subject: [PYTHON MATRIX-SIG] More repr vs. str issues - Please Read!
Message-ID: <01BC27E9.311CDE50@misha.lcs.mit.edu>

Perry Stoll writes:
>
> > The problem with the current repr function is that it doesn't display 
the
> > internal structure of the array which leaves out a lot of valuable
> > information.  To fix all of these problems in one fell swoop ;-), I 
propose
> > the following new behavior:
> >
> >>>> from Numeric import *
> >>>> a = identity(10)
> >>>> a # same as repr(a)
> > array([[1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
> >        [0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
> >        [0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
> >        [0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
> >        [0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
> >        [0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
> >        [0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
> >        [0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
> >        [0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
> >        [0, 0, 0, 0, 0, 0, 0, 0, 0, 1]], 'l')
>
> Will repr format it as above, i.e. including the newlines? Currently
> it returns a single string without newlines, basically nullifying an
> easy scan of the internal structure.
>
> # currently, repr does this:
> >>> repr(a)
> "array([[1, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 1, 0, 0, 0, 0, 0, 0, 0, 0], 
[0, 0, 1, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 1, 0, 0, 0, 0, 0, 0], [0, 0, 0, 
0, 1, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 1, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 1, 
0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 1, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 1, 0], 
[0, 0, 0, 0, 0, 0, 0, 0, 0, 1]], 'l')"

Yes!  Adding these new lines to repr's format is basically the grand idea I 
had this weekend to provide a repr format that was both in tune with the 
rest of python, and yet showed the internal structure of the array.  The 
format will look basically like the currently printed form of an array with 
a few commas and brackets added (in fact, for the first version I plan to 
just make these small changes to Konrad's current array print function to 
use as the array repr function).

-Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From motteler@laura.llnl.gov  Mon Mar  3 21:25:33 1997
From: motteler@laura.llnl.gov (Zane C. Motteler)
Date: Mon, 3 Mar 97 13:25:33 PST
Subject: [PYTHON MATRIX-SIG] More repr vs. str issues - Please Read!
In-Reply-To: <199703032030.PAA18589@fantod.xis.xerox.com>; from "Perry A. Stoll" at Mar 3, 97 12:30 (noon)
Message-ID: <199703032130.QAA14041@python.org>

Jim,

I like your proposal very much. I've never liked the current format
or repr. 

Zane

--
-----------------------------------------------------------------------------
Zane C. Motteler, Ph. D.                  ___________ALSO:_________________
Computer Scientist                        | Professor Emeritus of Computer|
Lawrence Livermore National Laboratory    |   Science and Engineering     |
P O Box 808, L-472                        | California Polytechnic State  |
Livermore, CA 94551-9900                  |   University, San Luis Obispo |
510/423-2143                              ---------------------------------
FAX 510/423-9969
zcm@llnl.gov or motteler@laura.llnl.gov or zmottel@calpoly.edu

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From amullhau@ix.netcom.com  Tue Mar  4 01:37:44 1997
From: amullhau@ix.netcom.com (Andrew P. Mullhaupt)
Date: Mon, 03 Mar 1997 20:37:44 -0500
Subject: [PYTHON MATRIX-SIG] More repr vs. str issues - Please Read!
References: <01BC27E0.685C2C80@misha.lcs.mit.edu>
Message-ID: <331B7CE8.25E5@ix.netcom.com>

Jim Hugunin wrote:
> 
> I realize that this seems a little bit uglier than the current behavior

Well, it conveys the important information. Looks good to me.

> Let me know what you think - Jim

It's the best we're likely to get.

Later,
Andrew Mullhaupt



_______________
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 Mar  4 10:36:25 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 4 Mar 1997 11:36:25 +0100
Subject: [PYTHON MATRIX-SIG] More repr vs. str issues - Please Read!
In-Reply-To: <01BC27E0.685C2C80@misha.lcs.mit.edu> (message from Jim Hugunin
 on Mon, 3 Mar 1997 14:37:22 -0500)
Message-ID: <199703041036.LAA18549@lmspc2.ibs.fr>

> information.  To fix all of these problems in one fell swoop ;-), I propose 
> the following new behavior:
> 
> >>> from Numeric import *
> >>> a = identity(10)
> >>> a # same as repr(a)
> array([[1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
>        [0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
>        [0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
>        [0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
>        [0, 0, 0, 0, 0, 0, 0, 0, 0, 1]], 'l')

Fine for this example. But what will a float array look like?
With every element formatted individually, the result will be a mess.
And what happens to higher-rank arrays?

To make the output of repr() clear for the user, it must be produced
in a similar way to how str() works now. In fact, it would be easy
to modify the array printer to produce a format like the one above.

One final comment about "a format that is a legal input
representation".  That sounds like a neat idea at first, but doesn't
really make much sense in an extensible language. In fact, the
representation shown above is legal input only if you have executed
"from Numeric import *" before. And there might be a dozen modules
that implement a data type called "array". So the importance of repr()
is more to aid the *user* in recognizing the type, not the interpreter.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Tue Mar  4 10:39:12 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 4 Mar 1997 11:39:12 +0100
Subject: [PYTHON MATRIX-SIG] Incompatible change to dot (any objections?)
In-Reply-To: <01BC27D9.9A9035E0@misha.lcs.mit.edu> (message from Jim Hugunin
 on Mon, 3 Mar 1997 13:48:40 -0500)
Message-ID: <199703041039.LAA18563@lmspc2.ibs.fr>

> behaves almost exactly like dot (no transposes involved).  I'd also like to 
> get rid of the function "matrixmultiply", though I'd be willing to keep it 
> around if people have concerns about backwards compatibility for their 
> code.

I recommend to leave it in the code, but not mention it in any documentation.
That should be sufficient to get rid of it in the long term.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Tue Mar  4 10:38:17 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 4 Mar 1997 11:38:17 +0100
Subject: [PYTHON MATRIX-SIG] More repr vs. str issues - Please Read!
In-Reply-To: <01BC27E9.311CDE50@misha.lcs.mit.edu> (message from Jim Hugunin
 on Mon, 3 Mar 1997 15:40:15 -0500)
Message-ID: <199703041038.LAA18557@lmspc2.ibs.fr>

> format will look basically like the currently printed form of an array with 
> a few commas and brackets added (in fact, for the first version I plan to 
> just make these small changes to Konrad's current array print function to 
> use as the array repr function).

OK, I should have read on before commenting ;-)
That sounds like a good way to go.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From jhauser@ifm.uni-kiel.de  Tue Mar  4 12:01:26 1997
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Tue, 4 Mar 1997 13:01:26 +0100
Subject: [PYTHON MATRIX-SIG] Icon for NumPy?
Message-ID: <9703041201.AA09753@flores.ifm.uni-kiel.de>

So, here is some action on the list, perhaps the right moment to
propose the generation of an unique Icon or emblem for NumPy. My first
and very obvious thought was that of number-crunching snake, perhaps
one of this kind wich is called a ...., eh you know :-)

Are there any artistic people on this list?

Just an idea,

__Janko


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From dave@zeus.hud.ac.uk  Tue Mar  4 12:49:53 1997
From: dave@zeus.hud.ac.uk (Dave Dench)
Date: Tue, 4 Mar 1997 12:49:53 GMT
Subject: [PYTHON MATRIX-SIG] Icon for NumPy?
Message-ID: <199703041249.MAA13931@be.csm>

> 
> So, here is some action on the list, perhaps the right moment to
> propose the generation of an unique Icon or emblem for NumPy. My first
> and very obvious thought was that of number-crunching snake, perhaps
> one of this kind wich is called a ...., eh you know :-)

There is a British snake called an ADDER , possibly useful for a 
cut-down implementation? ;-)
	David

________________________________________________________________________________

  	         ************************************************
                 *     David Dench                          	*
                 *     The University of Huddersfield , UK     	*
                 *     Tel:  01484 472083     			*
                 *     email: d.j.dench@zeus.hud.ac.uk 	 	*
                 ************************************************
________________________________________________________________________________

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hugunin@mit.edu  Tue Mar  4 14:44:52 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 4 Mar 1997 09:44:52 -0500
Subject: [PYTHON MATRIX-SIG] Icon for NumPy?
Message-ID: <01BC2880.B65A7E00@misha.lcs.mit.edu>

Janko writes:
> So, here is some action on the list, perhaps the right moment to
> propose the generation of an unique Icon or emblem for NumPy. My first
> and very obvious thought was that of number-crunching snake, perhaps
> one of this kind which is called a ...., eh you know :-)

I actually spent some time thinking about this while putting together the 
web pages for the beta release.  My answer will probably reveal the depths 
of my artistic inadequacies, but personally I rather enjoy the pun involved 
(it might take you a moment to notice it).  Check out the icon at the top 
of the Numeric Python page to see what I'm talking about 
http://www.sls.lcs.mit.edu/~jjh/numpy/.

I'm certainly not going to argue that this is the perfect icon, and I'd be 
thrilled to look at anything more artistic folks out there would care to 
create.  One thing that I really like about this icon though is that there 
is no snake in it.  With the covers on the two recent books it has become 
easy to forget the origins of the name Python (from the FAQ):

"Apart from being a computer scientist, I'm also a fan of "Monty Python's 
Flying Circus" (a BBC comedy series from the seventies, in the -- unlikely 
-- case you didn't know). It occurred to me one day that I needed a name 
that was short, unique, and slightly mysterious. And I happened to be 
reading some scripts from the series at the time... So then I decided to 
call my language Python. But Python is not a joke. And don't you associate 
it with dangerous reptiles either! (If you need an icon, use an image of 
the 16-ton weight from the TV series or of a can of SPAM :-) " - Python FAQ

-Jim

PS - Another note about designing NumPy icons.  There is no such thing as a 
NumPy file or program, so there is no need to design something small enough 
for this typical icon use.  The only use I've found for my icon has been on 
the NumPy web pages.






_______________
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  Tue Mar  4 15:45:42 1997
From: tom.schwaller@linux-magazin.de (Tom Schwaller)
Date: Tue, 04 Mar 1997 16:45:42 +0100
Subject: [PYTHON MATRIX-SIG] Icon for NumPy?
References: <01BC2880.B65A7E00@misha.lcs.mit.edu>
Message-ID: <331C43A6.2CFB8E05@linux-magazin.de>

Jim Hugunin wrote:

> "Apart from being a computer scientist, I'm also a fan of "Monty Python's
> Flying Circus" (a BBC comedy series from the seventies, in the -- unlikely
> -- case you didn't know). It occurred to me one day that I needed a name
> that was short, unique, and slightly mysterious. And I happened to be
> reading some scripts from the series at the time... So then I decided to
> call my language Python. But Python is not a joke. And don't you associate
> it with dangerous reptiles either! (If you need an icon, use an image of
> the 16-ton weight from the TV series or of a can of SPAM :-) " - Python FAQ


Me too :-)
If you wanna have some fun, please check the following pictures (Big and
small one)

http://www.linux-magazin.de/pics/title.03.96.jpg
http://www.linux-magazin.de/pics/title.03.96s.jpg

It is still one of my favorite one. Maybe I could 
tell my cover artist to make another one which I could missuse here.
It has to match another coverstory of course, but hei, I decide that :-)
A snake would be easy of course

Tom

_______________
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 Mar  4 17:26:28 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 4 Mar 1997 18:26:28 +0100
Subject: [PYTHON MATRIX-SIG] Icon for NumPy?
In-Reply-To: <01BC2880.B65A7E00@misha.lcs.mit.edu> (message from Jim Hugunin
 on Tue, 4 Mar 1997 09:44:52 -0500)
Message-ID: <199703041726.SAA19959@lmspc2.ibs.fr>

> of my artistic inadequacies, but personally I rather enjoy the pun involved 
> (it might take you a moment to notice it).  Check out the icon at the top 

Indeed, it's not obvious, but I like it ;-)  Maybe one could
use some morphing program to generate letters that are halfway between
the numbers and the letters?

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From barrett@compass.gsfc.nasa.gov  Thu Mar  6 18:12:11 1997
From: barrett@compass.gsfc.nasa.gov (Paul Barrett)
Date: Thu, 6 Mar 1997 13:12:11 -0500
Subject: [PYTHON MATRIX-SIG] NASA Research Announcement - Astrophysics Data Program
Message-ID: <199703061812.NAA09765@compass.rcssc668>


One week ago, NASA Research Announcement 97-OSS-02 was released.  This
NRA is for the Astrophysics Data Program or ADP.  This program
solicits basic and applied research proposals for three types of
investigations.  Two of them are for research involving space
astrophysics data and are of no concern here.  The third type is for
applied research to provide new and/or improved tools that enhance
space-based astrophysical observing, data analysis, and/or data
management.  Participation in this program is open to all categories
of organizations, domestic and foreign, including educational
institutions, for profit, and not for profit orginizations, NASA
Centers, and other U.S. Government agencies.  Therefore, an ADP
proposal is an excellent opportunity to enhance the numerical and data
analysis aspects of Python and to encourage wider use in the
scientific community.  The proposal deadline is 1997 May 27.

A fellow scientist at Goddard, Joe Harrington, and I have had
preliminary discussions about such a proposal and have arrived at the
following consensus:

1) To make Python more accessible to the scientific community,
Numerical Python needs to be provided as an easily installable
package, preferably having pre-built binaries for common platforms
available.  A binary package will make it much more likely that a
scientist will install the package to evaluate it.

2) A basic (or standard) data analysis environment must be developed.
Modules to be included in this package would almost certainly include
the numeric module, the netCDF module, the GIST module, and the PIL
module which would provide basic array, file, plotting and graphic
capabilities, resp.  The basic numerical python package would allow
most scientists to quickly and easily plot or display their data.
Note that most of these modules are already being developed and only
need to be integrated into a standard data analysis environment.

3) Though an ADP proposal can request financial support for up to
three years, a more conservative, and probably better, approach would
be to request financial support for only the first year, while
including in the proposal an outline of our long term goals.  A
successful first year, i.e. reaching over 75% of our goals, would most
likely lead to continued support for another two or three years.
Financial support can be rquested for both hardware and programmer
support.  Our initial thoughts would be to hire one programmer.

4) Since the ADP supports space astrophysics data analysis, this
proposal must include some aspect directly related to the topic.  We
would therefore propose to develop several astronomical libraries.
Two that come immediately to mind are the StarLink Astronomical
library and the Flexible Image Transport System (FITS) library, the
latter being the standard file format for astronomy.

5) To make this proposal of general use, and hence more viable, we
would work to develop C libraries that can be used by SWIG.  So in the
event that Python does not take root in the astronomical community
(God forbid!), these libraries could still be used by other
scripting-type languages, such as Perl, Guile, and Glish.

Well, if you have read this far, the purpose of this message is to see
who else in the Python community might be interested in collaborating
on such a proposal and to request from the Python community any
comments that they might have about our proposal.

Cheers,
Paul

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Paul Barrett  -  Astrophysicist  -  Universities Space Research Association |
|                 Compton Observatory Science Support Center                  |
| NASA/Goddard SFC     phone: 301-286-1108         "Linux, it's for everyone" |
| Code 660.1,          FAX:   301-286-1681                    A free UNIX OS  |
| Greenbelt,MD 20771   barrett@compass.gsfc.nasa.gov            for x386 PCs  |
|             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 hinsen@ibs.ibs.fr  Thu Mar  6 19:24:36 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 6 Mar 1997 20:24:36 +0100
Subject: [PYTHON MATRIX-SIG] NASA Research Announcement - Astrophysics Data Program
In-Reply-To: <199703061812.NAA09765@compass.rcssc668>
 (barrett@compass.gsfc.nasa.gov)
Message-ID: <199703061924.UAA27840@lmspc2.ibs.fr>

> 1) To make Python more accessible to the scientific community,
> Numerical Python needs to be provided as an easily installable
> package, preferably having pre-built binaries for common platforms
> available.  A binary package will make it much more likely that a
> scientist will install the package to evaluate it.

For Unix, binaries are always a bit of a problem due to the many
versions and subversions, but for a few very popular flavours it could
probably be done. I suspect that a one-in-all source distribution of
Python 1.4 plus NumPy and maybe some other extensions would already be
a big step ahead, even more if it has been tested for easy
installation on most common platforms. In fact, that's what I keep
around on my disk for installation of the various machines I use from
time to time.

> 2) A basic (or standard) data analysis environment must be developed.
> Modules to be included in this package would almost certainly include
> the numeric module, the netCDF module, the GIST module, and the PIL
> module which would provide basic array, file, plotting and graphic
> capabilities, resp.  The basic numerical python package would allow

This sounds like a very good idea. Right now getting and installing
all the nice stuff can be rather intimidating to people with little
experience in system administration. (In fact, I see this as the
major problem with Python's flexible extension system.)

> 5) To make this proposal of general use, and hence more viable, we
> would work to develop C libraries that can be used by SWIG.  So in the

That makes sense, of course.

> Well, if you have read this far, the purpose of this message is to see
> who else in the Python community might be interested in collaborating
> on such a proposal and to request from the Python community any
> comments that they might have about our proposal.

The astronomy-specific parts aside, such a project could well make
Python a much more attractive choice in science. So if you want moral
support, I'll let you have plenty of it ;-)
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From gmiller@user2.mnsinc.com  Thu Mar  6 19:47:28 1997
From: gmiller@user2.mnsinc.com (Gordon James Miller)
Date: Thu, 6 Mar 1997 14:47:28 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] Helping with Std. Pkg
Message-ID: <199703061947.OAA14065@user2.mnsinc.com>

I just read the request for assistance on standard packaging
the numerical and plotting aspects of Python and would love to help
out.  In my previous life, I worked at the Naval Research Lab doing
research in upper atmospheric physics.  In doing this, we used 
IDL (Interactive Data Language) and PV-Wave.  As soon as I heard
about python, I began using it for my own analysis work.  It has
been about a year since I was at the Lab, but I am more than willing
to lend whatever assistance I can to this project.

-- 
Gordon Miller                       gmiller@mnsinc.com
Software Engineer                   (703) 907-5343 (voice)
SAIC                                (888) 587-9903 (pager)
                                    gmiller-pager@std.saic.com

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From templon@studbolt.physast.uga.edu  Thu Mar  6 20:49:03 1997
From: templon@studbolt.physast.uga.edu (Jeffrey Templon)
Date: Thu, 6 Mar 1997 15:49:03 -0500
Subject: [PYTHON MATRIX-SIG] NASA Research Announcement - Astrophysics Data Program
In-Reply-To: <199703061812.NAA09765@compass.rcssc668>
References: <199703061812.NAA09765@compass.rcssc668>
Message-ID: <199703062049.PAA08837@studbolt.physast.uga.edu>

Hi,

Paul Barrett writes:

 > 1) To make Python more accessible to the scientific community,
 > Numerical Python needs to be provided as an easily installable
 > package, preferably having pre-built binaries for common platforms
 > available.  A binary package will make it much more likely that a
 > scientist will install the package to evaluate it.

I fully agree.  Asking your average Joe Physicist to go thru the
Makefile procedure will never work.  If you give EXPLICIT instructions
(both in 'sh' and 'csh' language, for Unix people) on how to set the
environment variables, you may succeed.

 > 2) A basic (or standard) data analysis environment must be developed.
 > Modules to be included in this package would almost certainly include
 > the numeric module, the netCDF module, the GIST module, and the PIL
 > module which would provide basic array, file, plotting and graphic
 > capabilities, resp.  The basic numerical python package would allow
 > most scientists to quickly and easily plot or display their data.
 > Note that most of these modules are already being developed and only
 > need to be integrated into a standard data analysis environment.

This is in my mind the most important thing, and also would be a HUGE
contribution to the NumPy community.  I used GIST about a year ago,
and while it was clear that it was nice, it was a hassle to use.
There were conflicts between it and the standard GNU Readline
mechanism, for example, and also lots of little functions and
parameters to remember.  One would hope for some default function
which would look sort of like GNUplot (or at least is as simple):

	plot1=gist.mkplot()       # default plot: 2D lin-lin
	plot2=gist.mkplot('2d','loglin')
	plot3=gist.mkplot('3d','surf')

	plot1.plot(xarray,yarray,ebararray)
	plot2.plot(x,cos(x))
	plot3.plot(grid,vals)

	plot2.xlabel('Energy (MeV)')
	plot2.show

I guess I'm trying to say that GIST plotting was very 'unpythonish' a
year ago.  I haven't looked since (too busy with other stuff) so I
apologize if these remarks are now off base.

The bottom line: modules listed in your (2) which have a consistent,
Pythonnish syntax and form, would make Python (and NumPy) much more
attractive to the community at large.  Go for it!

						JT

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From johann@physics.berkeley.edu  Thu Mar  6 22:00:24 1997
From: johann@physics.berkeley.edu (Johann Hibschman)
Date: Thu, 6 Mar 1997 14:00:24 -0800 (PST)
Subject: [PYTHON MATRIX-SIG] NASA Research Announcement - Astrophysics Data Program
In-Reply-To: <199703061812.NAA09765@compass.rcssc668>
Message-ID: <Pine.SUN.3.91.970306134554.4795A-100000@physics20.Berkeley.EDU>

On Thu, 6 Mar 1997, Paul Barrett wrote:

> Well, if you have read this far, the purpose of this message is to see
> who else in the Python community might be interested in collaborating
> on such a proposal and to request from the Python community any
> comments that they might have about our proposal.

If you want to get astronomers interested in python, you may want 
to wrap the PGPLOT libraries.  Someone just asked about that on 
comp.lang.python, and it started me thinking about how hard a task that 
would be.

All that has to be done, really, is to find a good way to pass variables
by reference through SWIG and to find a way to connect NumPy arrays to
SWIG pointers.  I have a feeling that I'm just missing something that lets
me pass variables by reference to SWIG, and just last night I coded a
quick function to take an array and return the SWIG string pointer
representation of its data.  However, for some reason the C-linking part
of SWIG on my workstation is not working now; I think I tweaked it so
heavily to get C++ to work that I broke something. 

In any case, it's something that's easily doable.  I've run out of 
disposable time for now, but I'll eventually get something that works.  
Once you get the C routines running, it is then trivial to write python 
code to give them a nice user interface.

On the down side, PGPLOT is still tied to FORTRAN, so it would be nice 
to encourage people to move to something else.  But, then again, having 
PGPLOT available in an easy form would encourage people to try the python 
system in the first place.  So, clearly, the answer is to get PGPLOT 
working to sucker people in, but then stop supporting it to get them to 
switch.  ;-)

Just free-associating...

- Johann

--
Johann Hibschman            | Grad student in Physics, lurking in Astronomy,
johann@physics.berkeley.edu | Probing Pulsar Pair Plasma Production Processes



_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From djc@lct.com  Thu Mar  6 22:19:54 1997
From: djc@lct.com (Duncan Child)
Date: Thu, 6 Mar 97 16:19:54 CST
Subject: [PYTHON MATRIX-SIG] FFT
Message-ID: <9703062219.AA11029@ lct.com>


Hello all,

Having much fun with Numeric Python but I am a bit confused
by the FFT module. Any suggestions gratefully accepted as to
what is wrong with the following:


#!/usr/local/bin/python

from Numeric import *
from FFT import *

raw_a = array ( [ 1.3 , 1.2, 1.5, 1.4 ]  )

print "raw_a ",raw_a

freq_a = real_fft (raw_a)

print "freq_a ",freq_a

prep_b = inverse_real_fft (freq_a)

print "prep_b ",prep_b

print "length of arrays: ",len(raw_a),len(freq_a),len(prep_b)


If I swap fft for real_fft and inverse_fft for inverse_real_fft the 
results seem OK. 


Thanks

Duncan

_______________
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  Thu Mar  6 22:16:17 1997
From: busby@icf.llnl.gov (L. Busby)
Date: Thu, 6 Mar 97 14:16:17 PST
Subject: [PYTHON MATRIX-SIG] NASA Research Announcement - Astrophysics Data Program
Message-ID: <9703062216.AA02218@icf.llnl.gov.llnl.gov>

[ Paul Barrett said ]
>One week ago, NASA Research Announcement 97-OSS-02 was released.  This
[ etc. ]

We've been taking some initial steps in a similar direction to your
proposal, Paul.  We have established a local CVS repository for Python
+ NumPy + Gist + <various other modules/patches useful for
scientists>.  We had two uses in mind when we put this together:  One
is to give us a sandbox where we could conveniently experiment with
additions and changes to Python, specifically (but not limited to)
better support and integration of C++.  Second, we hope the repository
will give us a handle on the afore-mentioned difficult problem of
configuring all the various components of Numerical Python into a
single build area.  E.g., we want to be able to

  cvs co python;cd python; configure; make

and get all the usual pieces in the package.  CVS, and CVS modules,
seems like a plausible way to organize all the parts, and they provide
a controlled means to expand the distribution over time.  I should
emphasize here that we *don't* intend to establish alternative
version(s) to Standard Python.  Putting the source in a code management
system is a means to support our research, while still allowing us to
closely track new releases from python.org.

We are interested in making our repository available to selected
researchers outside LLNL.  At the present time, you would need to apply
for an account on our network, and you'd need to have cvs and ssh
clients available on your local machine.  An alternative might be to
establish one or more mirror sites, perhaps at your location.
Regardless of repository access, we will certainly make periodic
"combined source" releases available on our anonymous ftp site.

The notion of providing pre-built binaries is intriguing, but it is not
presently a priority for us.  On the other hand, Thomas Esser's teTeX
distribution is a sort of existence proof that it can be done.

Good luck with your proposal.  I hope that our work in this area may
turn out to be mutually beneficial.

Lee

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From michaelb@gold.iap.net.au  Thu Mar  6 23:56:38 1997
From: michaelb@gold.iap.net.au (Michael Bell)
Date: Fri, 7 Mar 1997 07:56:38 +0800 (WST)
Subject: [PYTHON MATRIX-SIG] NASA Research Announcement - Astrophysics Data Program
In-Reply-To: <Pine.SUN.3.91.970306134554.4795A-100000@physics20.Berkeley.EDU>
 (message from Johann Hibschman on Thu, 6 Mar 1997 14:00:24 -0800
 (PST))
Message-ID: <m0w2n1a-00000nC@belfry.iap.net.au>

> Johann Hibschman wrote:
> 
> If you want to get astronomers interested in python, you may want 
> to wrap the PGPLOT libraries.  Someone just asked about that on 
> comp.lang.python, and it started me thinking about how hard a task that 
> would be.

Yes, I asked about PGPLOT ports to python on c.l.p.

The PGPLOT distribution includes a C version, and Using SWIG it was
trivial to wrap up most of pgplot into a python module, at least all
the subroutines with only scalar arguments.

It seems to me that it _ought_ to be trivial to extend the SWIGed code
to import array and matrix data (1d and 2d) from python objects to
pointers for the C/fortran library, but it's beyond my naive skill.

Python would then have a commonly used (by astronomers) plotting
module complete with vector plots, contouring, grey-scale and false
colour plots.  Perl has had this available in extremely easy to use
form for over a year I think.

> On the down side, PGPLOT is still tied to FORTRAN, so it would be nice 
> to encourage people to move to something else.  But, then again, having 
> PGPLOT available in an easy form would encourage people to try the python 
> system in the first place.  So, clearly, the answer is to get PGPLOT 
> working to sucker people in, but then stop supporting it to get them to 
> switch.  ;-)

Evil, wicked man!

-- 
Michael Bell
Kalgoorlie, Western Australia.

domestic disruption counter-intelligence DES arrangements AK-47
genetic $400 million in gold bullion class struggle Peking munitions
cracking terrorist radar bomb nuclear

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From johann@physics.berkeley.edu  Fri Mar  7 02:58:47 1997
From: johann@physics.berkeley.edu (Johann Hibschman)
Date: Thu, 6 Mar 1997 18:58:47 -0800 (PST)
Subject: [PYTHON MATRIX-SIG] PGPLOT issues
In-Reply-To: <m0w2n1a-00000nC@belfry.iap.net.au>
Message-ID: <Pine.SUN.3.91.970306184520.6300B-100000@physics20.Berkeley.EDU>

On Fri, 7 Mar 1997, Michael Bell wrote:

> It seems to me that it _ought_ to be trivial to extend the SWIGed code
> to import array and matrix data (1d and 2d) from python objects to
> pointers for the C/fortran library, but it's beyond my naive skill.

Well, I can move arrays back and forth.  You would have to transpose
the NumPy arrays before sending them in, since PGPLOT expects Fortran 
array element order, and you would have to remember that fortran indices 
start at 1, not 0, but a little bit of python wrapper code could fix 
that.

A more serious problem is the use of output variables, passed by 
reference in the argument lists of many PGPLOT functions.  Python just 
won't do this.  The only options I see are to send lists (or other 
mutable types) to the functions, or to have the pythonized versions 
return tuples of the output vars.  Not terribly nice.  I've asked on 
c.l.p if anyone has an elegant solution to this.

As for the arrays, the following code should work:

/*
  Given a Python array object, produce a Python string representing a
   SWIG pointer to the data of that object (as a contiguous block)
*/

static PyObject *
PyArray_ToSwigRef( PyObject *self, PyObject *args ) {
  PyObject *obj;
  char  *data;
  int   dims;
  char  *ptrstring;

  if(!PyArg_ParseTuple(args,"O",&obj))  /* get the object */
    return NULL;

  /* attempt to interpret the object as a 1D array of floats */
  if( !(PyArray_As1D(&obj, &data, &dims, PyArray_FLOAT))
    return NULL;  /* set error flag? */

  /* make a SWIG pointer (represented as a python string) */
  _swig_make_hex(ptrstring, data, "_float_p");

  return Py_BuildValue("s", ptrstring);
}

I'm not sure if this code is right, so don't blame me if your computer 
explodes.

- Johann

--
Johann Hibschman            | Grad student in Physics, lurking in Astronomy,
johann@physics.berkeley.edu | Probing Pulsar Pair Plasma Production Processes


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From michaelb@gold.iap.net.au  Fri Mar  7 13:22:00 1997
From: michaelb@gold.iap.net.au (Michael Bell)
Date: Fri, 7 Mar 97 13:22 WST
Subject: [PYTHON MATRIX-SIG] fidl, was: PGPLOT issues
In-Reply-To: <Pine.SUN.3.91.970306184520.6300B-100000@physics20.Berkeley.EDU>
 (message from Johann Hibschman on Thu, 6 Mar 1997 18:58:47 -0800
 (PST))
Message-ID: <m0w2s6s-00002zC@grendel.iap.net.au>

Johann Hibschman wrote:

<Snip! goes nonsense from me>
> A more serious problem is the use of output variables, passed by 
> reference in the argument lists of many PGPLOT functions.  Python just 
> won't do this.  The only options I see are to send lists (or other 
> mutable types) to the functions, or to have the pythonized versions 
> return tuples of the output vars.  Not terribly nice.  I've asked on 
> c.l.p if anyone has an elegant solution to this.

When I scanned the list archive I found the man page for 'fidl',
posted by Jim Fulton.  It appeared that, at least in simple cases,
fidl would produce something to work with.  I haven't been able to
find out anything else about it.  Does it still exist, or has it been
absorbed into the general NumPy effort?

-- 
Michael Bell
Kalgoorlie Consolidated Gold Mines, Western Australia

CIA Ortega Mossad Honduras smuggle domestic disruption BATF
cryptographic DES PLO Peking Delta Force Semtex Noriega strategic

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Fri Mar  7 08:56:53 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 7 Mar 1997 09:56:53 +0100
Subject: [PYTHON MATRIX-SIG] PGPLOT issues
In-Reply-To: <Pine.SUN.3.91.970306184520.6300B-100000@physics20.Berkeley.EDU>
 (message from Johann Hibschman on Thu, 6 Mar 1997 18:58:47 -0800
 (PST))
Message-ID: <199703070856.JAA29776@lmspc2.ibs.fr>

> A more serious problem is the use of output variables, passed by 
> reference in the argument lists of many PGPLOT functions.  Python just 
> won't do this.  The only options I see are to send lists (or other 

You can always pass in arrays to interface with the Fortran code.
The Python wrappers should of course return values properly, i.e.
as tuples if there is more than one.

It would be easier to discuss this if you could give an example
of such a function!
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From sean@embl-grenoble.fr  Fri Mar  7 10:14:19 1997
From: sean@embl-grenoble.fr (Sean McSweeney)
Date: Fri, 07 Mar 1997 11:14:19 +0100
Subject: [PYTHON MATRIX-SIG] PGPLOT issues
References: <Pine.SUN.3.91.970306184520.6300B-100000@physics20.Berkeley.EDU>
Message-ID: <331FEA7B.46FF@embl-grenoble.fr>

I have a Swigged version of the cpgplot lib. Which seems to work okay
with line plots. If I remember correctly I had some problem with the 
surface plots, probably due to my almost complete ignorance of C. 
I can't be more precise as I don't have the file here, and it's a long
time since I looked at it...

anyway it works with NumPy arrays, and it would be trivial to make it
look like the normal pgplot calls. 

Anybody can have what I have  if they want it. I would need to email it
out due to the paranoia of our firewall people.

S

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From Zachary_Roadhouse@brown.edu  Fri Mar  7 13:53:26 1997
From: Zachary_Roadhouse@brown.edu (Zachary_Roadhouse@brown.edu)
Date: Fri, 07 Mar 1997 08:53:26 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] NASA Research Announcement - Astrophysic
In-Reply-To: <199703061812.NAA09765@compass.rcssc668>
Message-ID: <XFMail.970307090225.Zachary_Roadhouse@brown.edu>


This would be an incredible chance for Python to expand.  Python is now
the core of the computer vision work we do here at LEMS.  One of the
nastier problems is that Python plus all the various packages we use 
(NumPy, PIL, opengl, vtk, and so on) is nasty to build.  It takes a
minimum of several hours to get a clean installation working -- even when
you know all the tricks.

We have been working on our environment for scientific work.  Our project,
call Raphael, is used to organize our work and provide a common GUI for
use various algorythms.  Interactive work is done using the integrated
editor/interpreter PTUI.

Interesting directions for this project might involve developing a better
Python dynamic environment for programming.  Extensions to this
environment would come in the form of plugins so that capabilities not
needed wouldn't be loaded in.  Matrix manipulation would of course be
central, and plugins would include graphing, surface visualization, volume
visualization...

Anyway, I have to go to class, just some ideas...

     - Zack

E-MAIL: Zachary_Roadhouse@brown.edu  WEB: http://althor.netspace.org/~zack/
Brown University, Box 220, Providence, RI 02912
Phone: (401) 863 - 5435

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From jim.fulton@digicool.com  Fri Mar  7 14:55:53 1997
From: jim.fulton@digicool.com (Jim Fulton)
Date: Fri, 07 Mar 1997 09:55:53 -0500
Subject: [PYTHON MATRIX-SIG] fidl, was: PGPLOT issues
References: <m0w2s6s-00002zC@grendel.iap.net.au>
Message-ID: <33202C79.4FE9@digicool.com>

Michael Bell wrote:
> 
> Johann Hibschman wrote:
> 
> <Snip! goes nonsense from me>
> > A more serious problem is the use of output variables, passed by
> > reference in the argument lists of many PGPLOT functions.  Python just
> > won't do this.  The only options I see are to send lists (or other
> > mutable types) to the functions, or to have the pythonized versions
> > return tuples of the output vars.  Not terribly nice.  I've asked on
> > c.l.p if anyone has an elegant solution to this.
> 
> When I scanned the list archive I found the man page for 'fidl',
> posted by Jim Fulton.  It appeared that, at least in simple cases,
> fidl would produce something to work with.  I haven't been able to
> find out anything else about it.  Does it still exist, or has it been
> absorbed into the general NumPy effort?

Here is the issue with fidl.

fidl was produced while I was at USGS.  I found it to be extremely
useful and would very much like to release it.  However, the only way
that it can be released is through a publication mechanism involving
colleague reviewers.  I attempted to get some such reviews by making
selected beta releases.  Unfortunately, I have gotten almost no
feedback, and the feedback I got was really more in the form of
questions.   I cannot, in good conscience, release fidl any more, even
to "beta testers".  This is a shame, because I think fidl could be quite
useful.

I no longer work at USGS, although I still have a connection with USGS
as a volunteer.  fidl is in no way related to my current activities, so
it is nearly impossible to justify additional effort on it.  However, 
I am willing to put some effort if:

  1. The past "beta testers" make any encouraging noises to me that they 
     think it is worth the effort, and

  2. I get a couple of people to sign on as colleague reviewers, 
     but this is a *real* commitment.  If someone says they are 
     going to do this, then I want *real* comments back.

Note that fidl has one limitation that some people consider to be a show
stopper, which is that it only interfaces to function, not to common
blocks.  This is find for libraries such as imsl, but is problematic for
systems that do all of their communication through common.  If fidl is
ever released, it would not be hard for someone to extend it to generate
common-block access capabilities, but I'm not going to do it.

Also, because Fortran doesn't (or at least didn't :) have the
equivalent, of C .h files, fidl requires that you write the moral
equivalent of .h files, or more accurately, the moral equivalent of idl
files. (C header files really arent expressive enough.)  It occurs to me
that one might be able to bypass or automate much of this effort in a
non-portable way by parsing certain Fortran compiler output.

I would also have to do some work to make fidl work more closely with
NumPy.  Fidl uses a matrix type which is an extremely early precursor to
NumPY arrays.  The fidl matrices should work with NumPy, just like other
Python sequence types do, but it would be more efficient for it to use
NumPy arrays directly.  This would probably be very easy.

On the other hand, fidl is very simply.  I wrote it in less than a day.
It might be easier to rebuild it from scratch, or, perhaps better,
integrate it's ideas into SWIG, than to "publish" it through USGS.

I'd be happy to discuss this with someone by phone or in person.  I
can't justify time for long email discussions on the topic.

Jim


-- 
Jim Fulton         Digital Creations
jim@digicool.com   540.371.6909
## Python is my favorite language ##
##     http://www.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  Fri Mar  7 16:04:01 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 7 Mar 1997 11:04:01 -0500
Subject: [PYTHON MATRIX-SIG] FFT
Message-ID: <01BC2AE7.43D84470@misha.lcs.mit.edu>

Duncan Child writes:
>
> Hello all,
>
> Having much fun with Numeric Python but I am a bit confused
> by the FFT module. Any suggestions gratefully accepted as to
> what is wrong with the following:
>
>
> #!/usr/local/bin/python
>
> from Numeric import *
> from FFT import *
>
> raw_a = array ( [ 1.3 , 1.2, 1.5, 1.4 ]  )
>
> print "raw_a ",raw_a
>
> freq_a = real_fft (raw_a)
>
> print "freq_a ",freq_a

real_fft returns the left half of the fft of a real array (the fft of a 
real array is conjugate symmetric, so only half of it is needed).  Notice 
that you can use the regular fft function on a real array and you'll get 
back the whole transform.  This is probably normally your best choice.  The 
real_fft function is just a little bit more efficient (it only has to do 
half the work).  It's there for those frequent cases where you'll take the 
fft of a real signal and then immediately throw out the right half.

> prep_b = inverse_real_fft (freq_a)

This should raise an exception (I added it to my bug list, but the fix 
might not happen before the next beta as it's not a "real" error). 
 inverse_real_fft is not the inverse function of real_fft, but it instead 
returns the left half of the inverse fft of a real valued vector.  This 
naming convention is from fftpack, and I don't think it's bad enough to 
fix.

> print "prep_b ",prep_b
>
> print "length of arrays: ",len(raw_a),len(freq_a),len(prep_b)

Do all of these results make sense now?

> If I swap fft for real_fft and inverse_fft for inverse_real_fft the
> results seem OK.

That's good!  inverse_fft(fft(a)) == a - give or take machine precision 
issues.  This is not at all true of real_fft and inverse_real_fft.  I'll 
add some notes to the manual, but the take-home message is that real_fft is 
an unusual function that should only be used in special circumstances (I 
added it because the speed is essential for computing speech spectrograms 
and for 2d fft's of images...)

-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 Mar  7 16:39:23 1997
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 7 Mar 1997 11:39:23 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] fidl, was: PGPLOT issues
In-Reply-To: <33202C79.4FE9@digicool.com>
Message-ID: <Pine.SGI.3.95q.970307112250.15032A-100000@maigret>


> Here is the issue with fidl.
> 
> fidl was produced while I was at USGS.  I found it to be extremely
> useful and would very much like to release it.  However, the only way
> that it can be released is through a publication mechanism involving
> colleague reviewers.  I attempted to get some such reviews by making
> selected beta releases.  Unfortunately, I have gotten almost no
> feedback, and the feedback I got was really more in the form of
> questions.   I cannot, in good conscience, release fidl any more, even
> to "beta testers".  This is a shame, because I think fidl could be quite
> useful.
> 
> I no longer work at USGS, although I still have a connection with USGS
> as a volunteer.  fidl is in no way related to my current activities, so
> it is nearly impossible to justify additional effort on it.  However, 
> I am willing to put some effort if:
> 
>   1. The past "beta testers" make any encouraging noises to me that they 
>      think it is worth the effort, and
> 
>   2. I get a couple of people to sign on as colleague reviewers, 
>      but this is a *real* commitment.  If someone says they are 
>      going to do this, then I want *real* comments back.

I'll admit to the world that I am one of those beta testers.  I asked Jim
for a beta because local folks were pestering me about ways to do weird
statistical tests which only IMSL provided.  Those people have since
quieted down, and as I don't need IMSL for my own work, my motivation to
work on testing FIDL more thoroughly has died down.  Just like Jim, this
ain't my day job...

That said, I certainly want to make 'encouraging noises' re: FIDL -- It
works great as far as I've tested it (very little), and if it could be
used by someone who could 'take on' the fidlization of a large library
such as IMSL, it would result in a truly useful system for lots of folks. 
One might even consider talking to the folks who sell IMSL about possibly
supporting such an effort, since it would only encourage Python users to
pay for the library licenses...  Also, talking to them might allow one to
get access to source files which would make the automatic use of FIDL more
realistic.  I found that wrapping a single IMSL routine was not hard, but
it's far from automatic simply because of the complexity of the
relationships between arguments.  This is due to the IMO poor interface
definition of IMSL, not to any FIDL problems. It also requires human
reading of the documentation which is only available through a GUI, which
makes automatizing impossible. Extrapolating, I'd say that wrapping all of
IMSL is a significant chunk of work (which is why I haven't done it).

Do astronomers ever use statistical tools like IMSL, or do you have more
specialized ones?  I do like the idea of getting some sort of support for
this type of project, since it makes it more likely to happen... 

On a related note, what's the status of the GRAD system, and its possible
release?  [this is addressed to the folks at United Space Alliance,
obviously]

--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 Mar  7 16:40:47 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 7 Mar 1997 11:40:47 -0500
Subject: [PYTHON MATRIX-SIG] Helping with Std. Pkg
Message-ID: <01BC2AEC.668BD5E0@misha.lcs.mit.edu>

Gordon Miller writes:
> I just read the request for assistance on standard packaging
> the numerical and plotting aspects of Python and would love to help
> out.  In my previous life, I worked at the Naval Research Lab doing
> research in upper atmospheric physics.  In doing this, we used
> IDL (Interactive Data Language) and PV-Wave.  As soon as I heard
> about python, I began using it for my own analysis work.  It has
> been about a year since I was at the Lab, but I am more than willing
> to lend whatever assistance I can to this project.

I would love to have somebody put some effort into making NumPy easily 
installable on Unix platforms.  Since I've recently gone over to the dark 
side (Windows NT), I have even less incentive to work on these issues than 
usual.  I have produced (with Mark Hammond's help) a very easy to install 
system for Windows NT and 95.  You download a program, run it, and select a 
few options, like where you want NumPy to go.  From there all of the 
details like environment variable settings get taken care of automagically. 
 Making this happen in the Unix world is a bear.

I had really wanted to put together a set of binaries for most major 
platforms myself, but I got really intimidated when I realized the number 
of "major" platforms.

So, I can't offer any help, but anybody who wants to take this on has my 
complete moral support.  I'd also be thrilled to add any easy to install 
versions of NumPy to my web pages.

Hoping somebody else will solve this one - 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 Mar  7 17:33:18 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 7 Mar 1997 18:33:18 +0100
Subject: [PYTHON MATRIX-SIG] Helping with Std. Pkg
In-Reply-To: <01BC2AEC.668BD5E0@misha.lcs.mit.edu> (message from Jim Hugunin
 on Fri, 7 Mar 1997 11:40:47 -0500)
Message-ID: <199703071733.SAA08926@lmspc2.ibs.fr>

> I would love to have somebody put some effort into making NumPy easily 
> installable on Unix platforms.  Since I've recently gone over to the dark 

I think the problem is partly Python itself, which doesn't offer a
standard procedure to "install" a self-contained extension. Having
a slightly more elaborate Setup file plus the right tools could change
that. Then you could just do configure; make; make install for
NumPy or any other extension.

For the moment, I see the installation in the Python source tree as
the best way to do a "real" installation. And it could be simplified
a lot by a slightly different package that contains updates to
all the files of the 1.4 distribution that must be modified. Then
the procedure would be

  1) Unpack Python 1.4
  2) Unpack NumPy
  3) configure; make; make install

> I had really wanted to put together a set of binaries for most major 
> platforms myself, but I got really intimidated when I realized the number 
> of "major" platforms.

Indeed. I am planning to put together an RPM version for RPM-enabled
Linuces (mostly RedHat), as soon as I feel confident that there won't
be a NumPy update out the next day ;-)  RPMs are so easy to install
that there is no reason left to complain.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Fri Mar  7 17:37:06 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 7 Mar 1997 18:37:06 +0100
Subject: [PYTHON MATRIX-SIG] fidl, was: PGPLOT issues
In-Reply-To: <Pine.SGI.3.95q.970307112250.15032A-100000@maigret> (message from
 David Ascher on Fri, 7 Mar 1997 11:39:23 -0500 (EST))
Message-ID: <199703071737.SAA08939@lmspc2.ibs.fr>

> That said, I certainly want to make 'encouraging noises' re: FIDL -- It

And I'll join in. Right now I am not planning to use any Fortran library
other than LAPACK (for which we have a complete interface), but I would
definitely like to be able to try one out in a simple way when need
arises. Unfortunately, I know nothing at all about what FIDL does and
how, what input data it needs etc., so I can't make any better comment
than "it sounds very interesting". Certainly easy Fortran interfacing
would be a desirable feature for NumPy!

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hugunin@mit.edu  Fri Mar  7 19:58:57 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 7 Mar 1997 14:58:57 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
Message-ID: <01BC2B08.166064C0@misha.lcs.mit.edu>

Recent posts have started me thinking about plotting and NumPy again.  This 
seems to be the weakest link in the package at the moment (since I've only 
been receiving minimal bug reports for the first beta release).  I'd really 
like people to be able to type:

plot(sin(arange(0,5*pi,pi/10)))

and have something reasonable happen.  While I continue to avow that this 
is not considered a basic part of NumPy, the current state of affairs 
regarding plotting packages is rather embarrassing.  In the Windows world 
I'm rather tempted to buy a nice plotting OCX (like an X widget) and just 
use that.  Still, I'd much prefer a public domain system that worked across 
platforms...

Here are my brief comments on the major packages out there, and why I don't 
use them:

1) Narcisse - Cool package used somewhat at Livermore, not publicly 
available.

2) Gist - Completely tied to Xlib.  Requires patches to python interpreter 
to use.

3) PGPlot - Basic code is FORTRAN.  Not something I'd want to hack to get 
working with Windows, and not something that most users of NumPy can be 
expected to be able to even compile.

4) PLPlot - The best option I've seen, the basic distribution even comes 
with a python module.  It's driver model also looks good, I could easily 
see adding Windows support.  On the other hand, installation is really a 
pain.  I just spent 45 minutes trying to get it up and running under Sun 
Solaris with no luck.  I'm also unsure of whether or not it is missing 
important features that these other packages have.

Am I missing any packages?  Am I wrong in my comments about any of these? 
 It sounds to me like the Astronomers among us are only interested in 
PGPlot.  Is this for historical reasons, or are there some features in this 
package that are not supported by the others?

I have no intention (or really ability) to legislate a single plotting 
package for NumPy.  Nonetheless, I'd be happiest if there could be a 
consensus on a good system for general use.  I'd even be willing to write 
the interface code to such a system to help get things off on the right 
track.

Looking for opinions - Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From djc@lct.com  Fri Mar  7 20:36:49 1997
From: djc@lct.com (Duncan Child)
Date: Fri, 7 Mar 97 14:36:49 CST
Subject: [PYTHON MATRIX-SIG] fidl, was: PGPLOT issues
Message-ID: <9703072036.AA17229@ lct.com>



> Certainly easy Fortran interfacing would be a desirable feature for NumPy!

and ...

> That said, I certainly want to make 'encouraging noises' re: FIDL


I agree. Not sure how I can contribute but please keep me posted. 

Regards

Duncan

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From motteler@laura.llnl.gov  Fri Mar  7 20:37:38 1997
From: motteler@laura.llnl.gov (Zane C. Motteler)
Date: Fri, 7 Mar 97 12:37:38 PST
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <01BC2B08.166064C0@misha.lcs.mit.edu>; from "Jim Hugunin" at Mar 7, 97 2:58 pm
Message-ID: <199703072041.PAA27562@python.org>

Jim,

> 
> Recent posts have started me thinking about plotting and NumPy again.  This 
> seems to be the weakest link in the package at the moment (since I've only 
> been receiving minimal bug reports for the first beta release).  I'd really 
> like people to be able to type:
> 
> plot(sin(arange(0,5*pi,pi/10)))
> 
<snip>
> 
> Here are my brief comments on the major packages out there, and why I don't 
> use them:
> 
> 1) Narcisse - Cool package used somewhat at Livermore, not publicly 
> available.

The French are working to make it public domain. I think their
bureaucracy is more impenetrable than ours, though. Narcisse does
have a couple of problems. First, it's very poor for 2d plots
(excellent for 3d however). Secondly, it is glacially slow.

> 
> 2) Gist - Completely tied to Xlib.  Requires patches to python interpreter 
> to use.

I now have excellent 2d and 3d Gist capability available in Python,
and in fact, the above plot command is pretty close to one of the
plot commands I have implemented. We haven't yet released this to
the general public because it was written with the older version
of NumPy, and as you know, the interface has changed dramatically, which
means that I have a lot of rewriting to do.

<snip>
> 
> 4) PLPlot - The best option I've seen, the basic distribution even comes 
> with a python module.  It's driver model also looks good, I could easily 
> see adding Windows support.  On the other hand, installation is really a 
> pain.  I just spent 45 minutes trying to get it up and running under Sun 
> Solaris with no luck.  I'm also unsure of whether or not it is missing 
> important features that these other packages have.

Actually, Geoff Furnish has suggested that I look at the possibility
of a "plplot driver" for Gist. I haven't, yet; don't have much spare
time right now, as I am in the midst of *trying* to develop a Gist
widget for tk. The former may actually be easier than the latter.

Cheers,

Zane

--
-----------------------------------------------------------------------------
Zane C. Motteler, Ph. D.                  ___________ALSO:_________________
Computer Scientist                        | Professor Emeritus of Computer|
Lawrence Livermore National Laboratory    |   Science and Engineering     |
P O Box 808, L-472                        | California Polytechnic State  |
Livermore, CA 94551-9900                  |   University, San Luis Obispo |
510/423-2143                              ---------------------------------
FAX 510/423-9969
zcm@llnl.gov or motteler@laura.llnl.gov or zmottel@calpoly.edu

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From templon@studbolt.physast.uga.edu  Fri Mar  7 20:49:05 1997
From: templon@studbolt.physast.uga.edu (Jeffrey Templon)
Date: Fri, 7 Mar 1997 15:49:05 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <01BC2B08.166064C0@misha.lcs.mit.edu>
References: <01BC2B08.166064C0@misha.lcs.mit.edu>
Message-ID: <199703072049.PAA11099@studbolt.physast.uga.edu>

Hi,

Jim Hugunin writes:
 > Recent posts have started me thinking about plotting and NumPy again.  This 
 > seems to be the weakest link in the package at the moment (since I've only 
 > been receiving minimal bug reports for the first beta release).  I'd really 
 > like people to be able to type:
 > 
 > plot(sin(arange(0,5*pi,pi/10)))

I'd like to reiterate my opinion that it'd be nice to have a plot be
an object.  This allows us to move up a notch (out of spaghetti-like
code) and do cool things like modify existing plots:

	plot1.xlims(10,20)
	plot1.update()

to change the x-axis limits, or for example

	gwin.stackplots(2,2,plot1,plot2,plot3,plot4)

to arrange four plots in a 2x2 matrix on the graphics window 'gwin'.

 > Am I missing any packages?  Am I wrong in my comments about any of these? 
 >  It sounds to me like the Astronomers among us are only interested in 
 > PGPlot.  Is this for historical reasons, or are there some features in this 
 > package that are not supported by the others?

Have you looked at DISLIN?  It's available in C, and looks pretty
nice.  The Linux and DOS versions are free, but unfortunately you have
to pay for the versions for other operating systems.  That's the
biggest disadvantage.  Possibly you might cut a deal with them as part
of making it a package.

The URL

	http://www.mpae.gwdg.de/dislin/dislin.html

					JAT

_______________
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 Mar  7 21:03:47 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 7 Mar 1997 16:03:47 -0500
Subject: [PYTHON MATRIX-SIG] Type coercion issues again - possible incompatibility in next release :-(
Message-ID: <01BC2B11.243BD2B0@misha.lcs.mit.edu>


I just fixed the recently reported bug that real_fft(a) (A function which 
expects an array of reals) would silently coerce an array of complex 
numbers by dropping their imaginary component.  This is clearly a bug and 
is now fixed.

In fixing this bug, I noticed a laxness in a number of array functions for 
coercion with loss of precision.  For example, the following code runs 
without a hitch in NumPy-beta1

>>> from Numeric import *
>>> a = arange(10, typecode=Float)
>>> a
array([ 0.,  1.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9.])
>>> asarray(a, Int)
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

While this is clearly not a problem in this case, in general it's a very 
dangerous thing to automatically coerce an array of floats to ints.

With my recent modifications (strictly intended to fix the real_fft bug) 
this will now raise an exception: "TypeError: Array can not be safely cast 
to required type".

The only way to get the previous behavior is to do: "a.astype(Int)". i.e. 
an explicit coercion.

The reason that I bring this up rather than just silently fixing it is that 
I find a fair number (~5) lines in the core NumPy python code that are 
broken by this bugfix.  It's easy for me to fix them here, and in my own 
code, but I thought I should open things up for discussion before 
introducing such an incompatible change after the beta1 release.

Opinions? - Jim



_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From ROWLAND@orion.cmc.uab.edu  Fri Mar  7 21:12:00 1997
From: ROWLAND@orion.cmc.uab.edu (ROWLAND@orion.cmc.uab.edu)
Date: Fri, 7 Mar 1997 15:12:00 -0600 (CST)
Subject: [PYTHON MATRIX-SIG] Plotting packages
Message-ID: <970307151200.4502e595@orion.cmc.uab.edu>


Has anyone considered the PLOTMTV package? As for platforms it's only
available for X11. I find it does a lot very simply but I have no idea
how easy it would be to modify.

Scott Rowland

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From barton@simsg1.mdc.com  Fri Mar  7 21:13:10 1997
From: barton@simsg1.mdc.com (Brien Barton)
Date: Fri, 07 Mar 1997 13:13:10 -0800
Subject: [PYTHON MATRIX-SIG] Plotting packages
References: <01BC2B08.166064C0@misha.lcs.mit.edu>
Message-ID: <332084E6.167E@simsg1.mdc.com>

Jim Hugunin wrote:
> 
> Recent posts have started me thinking about plotting and NumPy again.  

I think that well integrated plotting capability is crucial to the
success of NumPy.

> 4) PLPlot - The best option I've seen, the basic distribution even comes
> with a python module.  It's driver model also looks good, I could easily
> see adding Windows support.  On the other hand, installation is really a
> pain.

I did get an earlier version of PLPlot working with NumPy on an SGI
about a year ago but it seemed to have bugs.  About 2 months ago I tried
PLPlot version 961023 and couldn't get it to work at all.  

> Am I missing any packages?

I recall someone mentioning that there was (or will be?) a C library
interface to the GNUPLOT package.  That sounded very promising to me,
since GNUPLOT works on most of the major operating systems (including
Windows) and also supports a large number of output devices.  Does
anyone know if this library exists?  Has anyone gotten it to work with
Python?

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From motteler@laura.llnl.gov  Fri Mar  7 21:26:34 1997
From: motteler@laura.llnl.gov (Zane C. Motteler)
Date: Fri, 7 Mar 97 13:26:34 PST
Subject: [PYTHON MATRIX-SIG] Plotting packages
Message-ID: <199703072129.QAA27844@python.org>

Jeffrey Templon said:

> I'd like to reiterate my opinion that it'd be nice to have a plot be
> an object.  This allows us to move up a notch (out of spaghetti-like
> code) and do cool things like modify existing plots:

I'd like to emphasize that my first Python interface to Narcisse and
Gist was object-oriented; only later did I add the capability of
just calling plot functions, for those old-fashioned line-oriented folks.

Just to recap my original design, it consisted of geometric objects--
Curves, Surfaces, Meshes, etc. Then there was Graph (inherited by
Graph2d and Graph3d); a graph can have one or more geometric objects.
Finally there were Plotter objects (currently in two varieties,
Narcisse and Gist). A Graph can also have one or more Plotter objects.
You then plot a graph g by giving the command g.plot(). The plot may
go to one or more windows and/or cgm, postscript, and other types of
files, depending on the Plotters which the Graph contains. Graphs
have methods to change things like limits, colors, etc. just as
Jeffrey mentioned in his note.

Cheers

Zane

--
-----------------------------------------------------------------------------
Zane C. Motteler, Ph. D.                  ___________ALSO:_________________
Computer Scientist                        | Professor Emeritus of Computer|
Lawrence Livermore National Laboratory    |   Science and Engineering     |
P O Box 808, L-472                        | California Polytechnic State  |
Livermore, CA 94551-9900                  |   University, San Luis Obispo |
510/423-2143                              ---------------------------------
FAX 510/423-9969
zcm@llnl.gov or motteler@laura.llnl.gov or zmottel@calpoly.edu

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hugunin@mit.edu  Fri Mar  7 21:31:34 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 7 Mar 1997 16:31:34 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
Message-ID: <01BC2B15.06183A90@misha.lcs.mit.edu>

Jeffrey Templon writes:
> I'd like to reiterate my opinion that it'd be nice to have a plot be
> an object.  This allows us to move up a notch (out of spaghetti-like
> code) and do cool things like modify existing plots:
>
> 	plot1.xlims(10,20)
> 	plot1.update()
>
> to change the x-axis limits, or for example
>
> 	gwin.stackplots(2,2,plot1,plot2,plot3,plot4)
>
> to arrange four plots in a 2x2 matrix on the graphics window 'gwin'.

I agree with you completely.  On the other hand, I'd like there to be a 
simplified interface like the one that I proposed available so that one can 
trivially look at an array graphiucally without having to setup plot 
windows/objects/whatever.  My proposed function was mainly for interactive 
use.  Something like your notation is clearly what should be done for use 
within modules.

>  > Am I missing any packages?  Am I wrong in my comments about any of 
these?
>  >  It sounds to me like the Astronomers among us are only interested in
>  > PGPlot.  Is this for historical reasons, or are there some features in 
this
>  > package that are not supported by the others?
>
> Have you looked at DISLIN?  It's available in C, and looks pretty
> nice.  The Linux and DOS versions are free, but unfortunately you have
> to pay for the versions for other operating systems.  That's the
> biggest disadvantage.  Possibly you might cut a deal with them as part
> of making it a package.

The base price of DISLIN for a workstation is ~$375 US.  This is completely 
unreasonable for a package to make the basic plotting component of NumPy. 
 If nothing better than this can be found I'd rather just grab one of the 
cheaper OCX's for Windows and be done with it.

-Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From steve@estel.uindy.edu  Fri Mar  7 23:20:56 1997
From: steve@estel.uindy.edu (Steve Spicklemire)
Date: Fri, 7 Mar 97 18:20:56 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <01BC2B08.166064C0@misha.lcs.mit.edu> (message from Jim Hugunin on Fri, 7 Mar 1997 14:58:57 -0500)
Message-ID: <9703072320.AA19267@estel.uindy.edu>


Hi NymPy folks,

>>>>> "Jim" == Jim Hugunin <hugunin@mit.edu> writes:

    Jim> Recent posts have started me thinking about plotting and
    Jim> NumPy again.  This seems to be the weakest link in the
    Jim> package at the moment (since I've only been receiving minimal
    Jim> bug reports for the first beta release).  I'd really like
    Jim> people to be able to type:

    Jim> plot(sin(arange(0,5*pi,pi/10)))

    Jim> and have something reasonable happen.  While I continue to
    Jim> avow that this is not considered a basic part of NumPy, the

	I don't know if this would help at all, but I've been having
good luck using a Java/Applet based graphing. I've been using NumPy in
Physics courses since the 0.3x days. I've incorporated David A.'s
docs. At one point I melded it with my Zinc based GUI module.. but now
I'm using more 'off the shelf' technology (i.e., Java) Point your
favorite Java enabled browser to

http://estel.uindy.edu/PESSci/ph280/

and look at some of the links there. The nice thing about this approach
is that you can make the resulting 'graph' more interactive. It might be 
pretty easy to come up with some applets that work nicely with NumPy, and
also allow lots of other cool stuff.

-steve


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From johann@physics.berkeley.edu  Fri Mar  7 23:42:56 1997
From: johann@physics.berkeley.edu (Johann Hibschman)
Date: Fri, 7 Mar 1997 15:42:56 -0800 (PST)
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <01BC2B08.166064C0@misha.lcs.mit.edu>
Message-ID: <Pine.SUN.3.91.970307152329.9903B-100000@physics20.Berkeley.EDU>

On Fri, 7 Mar 1997, Jim Hugunin wrote:

> Am I missing any packages?  Am I wrong in my comments about any of these? 
>  It sounds to me like the Astronomers among us are only interested in 
> PGPlot.  Is this for historical reasons, or are there some features in this 
> package that are not supported by the others?

Well, I don't actually use it myself, but it's always on the list of
packages mentioned when discussing plots.  I get the feeling that most
people use SuperMongo or IDL, which are both proprietary.

Personally, I just use gnuplot and Mathematica for most of my plots. I
wrote a brief Python interface to gnuplot, which works in the simplest way
imaginable: it writes out temporary files of data and plotting commands,
then calls gnuplot on them.  That idea would work for any of the standard
interactive plotting packages, but is rather slow. 

> I have no intention (or really ability) to legislate a single plotting 
> package for NumPy.  Nonetheless, I'd be happiest if there could be a 
> consensus on a good system for general use.  I'd even be willing to write 
> the interface code to such a system to help get things off on the right 
> track.

Speaking of consensus, would it be possible to define a standard set of
basic NumPy plot classes and methods, which would then be implemented
through any of a number of plot packages?  I am thinking of something like
the os module; each OS has its own implementation of rm, ls, etc., but the
os module provides a universal interface, allowing easy portability.

There could be a basic plot interface which allows plotting of 1D arrays,
setting titles, setting axis labels, setting ranges, log scaling, etc., in
a standard way.  All these plotting packages do basically the same thing,
so shouldn't it be possible to define one interface to them all, with a
few special commands to provide access to package-specific features?  Or
is this more trouble than it's worth? 

- Johann

--
Johann Hibschman            | Grad student in Physics, lurking in Astronomy,
johann@physics.berkeley.edu | Probing Pulsar Pair Plasma Production Processes


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From tismer@tismer.com  Sat Mar  8 00:18:18 1997
From: tismer@tismer.com (Christian Tismer)
Date: Sat, 08 Mar 1997 01:18:18 +0100
Subject: [PYTHON MATRIX-SIG] Plotting packages
References: <9703072320.AA19267@estel.uindy.edu>
Message-ID: <3320B04A.4AE6@tismer.com>

[ ... ]

>         I don't know if this would help at all, but I've been having
> good luck using a Java/Applet based graphing. I've been using NumPy in
> Physics courses since the 0.3x days. I've incorporated David A.'s
> docs. At one point I melded it with my Zinc based GUI module.. but now
> I'm using more 'off the shelf' technology (i.e., Java) Point your
> favorite Java enabled browser to
> 
> http://estel.uindy.edu/PESSci/ph280/
> 
> and look at some of the links there. The nice thing about this approach
> is that you can make the resulting 'graph' more interactive. It might be
> pretty easy to come up with some applets that work nicely with NumPy, and
> also allow lots of other cool stuff.

Hi Steve, I found this really cool. Taking Java not as a competitor, but
simply a working horse and doing the nice stuff in Python.
It is also quite quick. I could give it a try with my polytop meshes.
Is there a way to talk to the java code locally, also?
Could that be the compromise for the future?
Just to say we use Java as a general platform for the gui and control it
from Python?
I personally like the idea because it gives us _something_ immediately,
because it runs everywhere, and everyone can use a browser.

At least this is a very quick solution to the gui problem.
I would like to see a discussion in the main list.

cheers - chris

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From steve@estel.uindy.edu  Sat Mar  8 00:36:38 1997
From: steve@estel.uindy.edu (Steve Spicklemire)
Date: Fri, 7 Mar 97 19:36:38 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <3320B04A.4AE6@tismer.com> (message from Christian Tismer on Sat, 08 Mar 1997 01:18:18 +0100)
Message-ID: <9703080036.AA19783@estel.uindy.edu>

Hi Christian,

>>>>> "Christian" == Christian Tismer <tismer@tismer.com> writes:

    Christian> Hi Steve, I found this really cool. Taking Java not as
    Christian> a competitor, but simply a working horse and doing the
    Christian> nice stuff in Python.  It is also quite quick. I could
    Christian> give it a try with my polytop meshes.  Is there a way
    Christian> to talk to the java code locally, also?  Could that be

Hmm... perhaps with ILU that could be made to work. I've not been able
to build 2.0a9 on my NeXT yet though. :-( Or perhaps some simple
protocol could be cooked up to communicate between Python doing
calculations and a Java 'window' running as a separate process.

    Christian> the compromise for the future?  Just to say we use Java
    Christian> as a general platform for the gui and control it from
    Christian> Python?  I personally like the idea because it gives us
    Christian> _something_ immediately, because it runs everywhere,
    Christian> and everyone can use a browser.

Yup.

    Christian> At least this is a very quick solution to the gui
    Christian> problem.  I would like to see a discussion in the main
    Christian> list.

    Christian> cheers - chris

works for me.
-steve

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From alan@oldp.nmsu.edu  Sun Mar  9 05:53:20 1997
From: alan@oldp.nmsu.edu (Alan Watson)
Date: Sat, 8 Mar 1997 22:53:20 -0700
Subject: [PYTHON MATRIX-SIG] Coercion problems solved?
Message-ID: <9703090553.AA09883@oldp.nmsu.edu>

I'm evaluating Numerical Python for astronomical imaging applications.
These tend to involve largish arrays. For example, state-of-the-art
visible light detectors are 2k by 4k, so even with 32-bit floats a
single image is 32 MB.

I read the discussion in the mailing list archive on the coercion
rules between arrays and scalars with some disappointment. I
appreciate that having (scalar * vector)[i] == scalar * vector[i] is a
nice property, but I saw my options as either eating the cache and
page faults, buying a computer with a bigger cache and yet more
memory, or having to wrap every scalar in a function to convert it to
a rank-0 32-bit float array. None of these prospects filled me with
unbounded joy.

Then I remembered that Python is not an assembler with structs but is
an object-oriented language. A few minutes yielded:

    import UserArray
    class array32(UserArray.UserArray):
        def __init__(self, sequence): 
            UserArray.UserArray.__init__(self, sequence, typecode='f')
        def __coerce__(self,other): 
            return (self, UserArray.UserArray(other, typecode='f'))

(I've been using Python for only two days, so this may not be quite
perfect. Also, the UserArray classes don't appear to support a copy
argument.) This allows me to implement my own `principle of least
surprise' for coercion, namely that array elements are always 32-bit
floats. I think this idea can be extended to other, more complicated,
schemes.

I've not seen this mentioned in the discussion; maybe it was too
obvious or maybe I missed it while scanning the archive. I think it
just about eliminates the problem of the current rules for those of us
who prefer to work with the smaller types.

Regards,

Alan Watson

_______________
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  Sun Mar  9 17:14:39 1997
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Sun, 9 Mar 1997 09:14:39 -0800
Subject: [PYTHON MATRIX-SIG] Plotting packages
Message-ID: <9703091715.AA24200@icf.llnl.gov.llnl.gov>

Some remarks about activity at LLNL:

We have had an OO attitude from the first about how the Python/graphics
interfaces should look, but also recognize there has to be an easy 

plot(y,x, color="red", style="dashed", scale="linlog") 

sort of interface for casual use. It is possible to do both, and we are doing
it. 

We have tried to create our work in layers so that the graphics object and
plot(y,x, ...) sort of layers are INDEPENDENT of the underlying graphics
library choice. It could be a reasonable goal for us to try to agree on the
design of the upper layers first, since the (time-dependent) question of
portability obfuscates the discussion of the bottom layers. Our design is
influenced (presumably positively) by our years of Basis and Yorick
experience, but since we do not all do the same kind of work I would presume
there are needs that our design does not meet.

On the subject of graphics packages, there are graphics packages and then
there are graphics packages. In this discussion little has been said about
the capabilities of the packages mentioned. It is one thing to need to graph
a curve; another to need to do colored contouring on irregular grids of data
with missing values. The set of available output-file formats matter, too.

The Gist module we have under development is very full featured. As Zane
mentioned, It is taking more time than we would like because we are both
underfunded and having to do a 3-D layer because of our application, but we
should have a much enhanced release for "PyGist" soon. The comment has been
made that Gist uses X-Windows only. I believe one of our physicists has
ported the C Gist library to NT and Mac. I am checking on this and will
report back. We are investigating how hard a Tk widget for Gist would be.

PLPLOT has been interfaced to Python with great success. It is also a very
capable library and a Tk widget for it has been developed. While there have
been isolated reports of difficulty installing it, the majority of people
seem to have no trouble. It would be helpful for people having difficulty
with an install to send details to furnish@llnl.gov. 

We just learned last week that a group doing climate modeling here is
beginning to interface their VERY fancy graphics library and accompanying
tools to Python. Python is being used as the "glue" to connect modeling
codes, data, and graphics. This library was written here and is entirely
self-contained. Again, as I learn more about it I will try to keep you all
informed.  This is presently a Unix library but the author said NT was on his
mind these days.

We consider portability to NT a longer-term necessity too. 

-- Paul Dubois

----------
> From: Jeffrey Templon <templon@studbolt.physast.uga.edu>
> To: Jim Hugunin <hugunin@mit.edu>
> Cc: MATRIX Sig <matrix-sig@python.org>
> Subject: [PYTHON MATRIX-SIG] Plotting packages
> Date: Friday, March 07, 1997 12:49 PM
> 
> Hi,
> 
> Jim Hugunin writes:
>  > Recent posts have started me thinking about plotting and NumPy again. 
This 
>  > seems to be the weakest link in the package at the moment (since I've
only 
>  > been receiving minimal bug reports for the first beta release).  I'd
really 
>  > like people to be able to type:
>  > 
>  > plot(sin(arange(0,5*pi,pi/10)))
> 
> I'd like to reiterate my opinion that it'd be nice to have a plot be
> an object.  This allows us to move up a notch (out of spaghetti-like
> code) and do cool things like modify existing plots:
> 
> 	plot1.xlims(10,20)
> 	plot1.update()
> 
> to change the x-axis limits, or for example
> 
> 	gwin.stackplots(2,2,plot1,plot2,plot3,plot4)
> 
> to arrange four plots in a 2x2 matrix on the graphics window 'gwin'.
> 
>  > Am I missing any packages?  Am I wrong in my comments about any of
these? 
>  >  It sounds to me like the Astronomers among us are only interested in 
>  > PGPlot.  Is this for historical reasons, or are there some features in
this 
>  > package that are not supported by the others?
> 
> Have you looked at DISLIN?  It's available in C, and looks pretty
> nice.  The Linux and DOS versions are free, but unfortunately you have
> to pay for the versions for other operating systems.  That's the
> biggest disadvantage.  Possibly you might cut a deal with them as part
> of making it a package.
> 
> The URL
> 
> 	http://www.mpae.gwdg.de/dislin/dislin.html
> 
> 					JAT
> 
> _______________
> 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  Sun Mar  9 18:02:51 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sun, 9 Mar 1997 19:02:51 +0100
Subject: [PYTHON MATRIX-SIG] Type coercion issues again - possible incompatibility in next release :-(
In-Reply-To: <01BC2B11.243BD2B0@misha.lcs.mit.edu> (message from Jim Hugunin
 on Fri, 7 Mar 1997 16:03:47 -0500)
Message-ID: <199703091802.TAA16447@lmspc2.ibs.fr>

> In fixing this bug, I noticed a laxness in a number of array functions for 
> coercion with loss of precision.  For example, the following code runs 
> without a hitch in NumPy-beta1
> 
> >>> from Numeric import *
> >>> a = arange(10, typecode=Float)
> >>> a
> array([ 0.,  1.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9.])
> >>> asarray(a, Int)
> array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
> 
> While this is clearly not a problem in this case, in general it's a very 
> dangerous thing to automatically coerce an array of floats to ints.

What's automatic in this case? There's an explicit 'Int' there, so
I don't see a problem.

I agree, of course, that truly automatic conversion with loss of
precision should not happen, even if that leads to somewhat incompatible
behaviour.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From amullhau@ix.netcom.com  Sun Mar  9 18:13:34 1997
From: amullhau@ix.netcom.com (Andrew P. Mullhaupt)
Date: Sun, 09 Mar 1997 13:13:34 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
References: <9703091715.AA24200@icf.llnl.gov.llnl.gov>
Message-ID: <3322FDCE.5EA@ix.netcom.com>

Paul F. Dubois wrote:
> 
> Some remarks about activity at LLNL:
> 
> We have had an OO attitude from the first about how the Python/graphics
> interfaces should look, but also recognize there has to be an easy
> 
> plot(y,x, color="red", style="dashed", scale="linlog")
> 
> sort of interface for casual use. It is possible to do both, and we are doing
> it.

Actually, you really want plot to be a _method_, and its _result_ to be
an object.

One nice way of making this work well is to have 'default' plot methods,
as is done in S.

In fact, despite other shortcomings S may have, the graphics and their
interface are, in the sense of 'the big picture' probably the way to go.
The graphics there are powerful, easy to use, and easy to extend. I
would really like people who are going to go to the trouble of making a
plot extension for Numerical Python to at least have seen what you can
do with the S approach.

> It could be a reasonable goal for us to try to agree on the
> design of the upper layers first, since the (time-dependent) question of
> portability obfuscates the discussion of the bottom layers.

You got that right.

> Our design is
> influenced (presumably positively) by our years of Basis and Yorick
> experience, but since we do not all do the same kind of work I would presume
> there are needs that our design does not meet.

I cannot really say, since I haven't tried the latest version of Yorick,
but the limitations of those graphics I ran into involved not being able
to interact with the plot, and not being able to build up sufficiently
customized plots.

Later,
Andrew Mullhaupt


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Sun Mar  9 18:23:46 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sun, 9 Mar 1997 19:23:46 +0100
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <9703091715.AA24200@icf.llnl.gov.llnl.gov> (dubois1@llnl.gov)
Message-ID: <199703091823.TAA16510@lmspc2.ibs.fr>

> We have had an OO attitude from the first about how the Python/graphics
> interfaces should look, but also recognize there has to be an easy 
> 
> plot(y,x, color="red", style="dashed", scale="linlog") 
> 
> sort of interface for casual use. It is possible to do both, and we are doing
> it. 

Good. The availability of both a simple and a flexible access to graphics
is the main reason why I still use Mathematica for plotting, in spite
of some major inconveniences.

> We have tried to create our work in layers so that the graphics object and
> plot(y,x, ...) sort of layers are INDEPENDENT of the underlying graphics
> library choice. It could be a reasonable goal for us to try to agree on the

That seems to me the only reasonable choice. Clearly there is no
single good-enough-for-everyone plot package on the market, much less
on the freeware market. And if some day someone does it right, we will
surely want to profit.

In fact, I wonder whether it might be easier to write a library from
scratch, in Python, using some high-level graphics library such as
OpenGL, than to deal with the intricacies of libraries that are
sometimes so old that they predate modern graphics hardware.

> On the subject of graphics packages, there are graphics packages and then
> there are graphics packages. In this discussion little has been said about
> the capabilities of the packages mentioned. It is one thing to need to graph
> a curve; another to need to do colored contouring on irregular grids of data
> with missing values. The set of available output-file formats matter, too.

True. We should concentrate on getting something for the most common
needs first, without of course forgetting about more sophisticated
stuff for later. Straightforward 2D curve plots on all platforms would
already be a big step forward.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Sun Mar  9 18:26:12 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sun, 9 Mar 1997 19:26:12 +0100
Subject: [PYTHON MATRIX-SIG] Coercion problems solved?
In-Reply-To: <9703090553.AA09883@oldp.nmsu.edu> (message from Alan Watson on
 Sat, 8 Mar 1997 22:53:20 -0700)
Message-ID: <199703091826.TAA16522@lmspc2.ibs.fr>

> Then I remembered that Python is not an assembler with structs but is
> an object-oriented language. A few minutes yielded:
> 
>     import UserArray
>     class array32(UserArray.UserArray):
>         def __init__(self, sequence): 
>             UserArray.UserArray.__init__(self, sequence, typecode='f')
>         def __coerce__(self,other): 
>             return (self, UserArray.UserArray(other, typecode='f'))

This sounds like a very good approach. Maybe we should even put
something like this into the standard distribution, if only as
an example for specializing arrays.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hochberg@wwa.com  Sun Mar  9 20:09:40 1997
From: hochberg@wwa.com (Timothy A. Hochberg)
Date: Sun, 9 Mar 1997 14:09:40 -0600 (CST)
Subject: [PYTHON MATRIX-SIG] Type coercion issues again - possible incompatibility in next release :-(
In-Reply-To: <199703091802.TAA16447@lmspc2.ibs.fr>
Message-ID: <Pine.BSI.3.95.970309140518.22475B-100000@shoga.wwa.com>



On Sun, 9 Mar 1997, Konrad Hinsen wrote:

> > In fixing this bug, I noticed a laxness in a number of array functions for 
> > coercion with loss of precision.  For example, the following code runs 
> > without a hitch in NumPy-beta1
> > 
> > >>> from Numeric import *
> > >>> a = arange(10, typecode=Float)
> > >>> a
> > array([ 0.,  1.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9.])
> > >>> asarray(a, Int)
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
> > 
> > While this is clearly not a problem in this case, in general it's a very 
> > dangerous thing to automatically coerce an array of floats to ints.
> 
> What's automatic in this case? There's an explicit 'Int' there, so
> I don't see a problem.
> 
> I agree, of course, that truly automatic conversion with loss of
> precision should not happen, even if that leads to somewhat incompatible
> behaviour.

I've been bitten a few times by the followiung behaviour.

a = NP.zeros((5,5))
a[3] = 1.5 # .5 is silently dropped
b = NP.zeros((5,5), NP..Float)
b[3] = 5 + 4j  # 4j silently dropped

Would the changes your proposing 'fix' this? Or am I gonna just have to
learn to be a little more careful in my coding....;)

-tim




_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From templon@studbolt.physast.uga.edu  Sun Mar  9 22:38:03 1997
From: templon@studbolt.physast.uga.edu (Jeffrey Templon)
Date: Sun, 9 Mar 1997 17:38:03 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <199703072129.QAA27844@python.org>
References: <199703072129.QAA27844@python.org>
Message-ID: <199703092238.RAA21145@studbolt.physast.uga.edu>

Hi,

Funny that we should start talking about this right now.  If we are
talking about a basic 2D plot package, take a look at the following
message.  I've looked at it, and it looks reasonable for 2D plots.
I think writing a Python wrapper for this would be pretty easy.

						JT
Robert S. Maier writes:

 > Hi, Jeff.  This is to let you know that a much enhanced version of the old
 > GNU graphics package is now available.  It's about 1.7 meg, gzipped; you
 > can get it from
 > 
 > 	ftp://platinum.math.arizona.edu/pub/plotutils.tar.gz
 > 
 > Strictly speaking, this is a pre-release version; it's billed as 
 > `release 1.0-alpha'.
 > 
 > I think that several years ago, you helped evaluate and improve an alpha
 > release of the old package?  Your name is still in the documentation.  If
 > you could look over the new (much expanded, and completely rewritten)
 > package, I'd much appreciate it.
 > 
 > The package is now called the `plotutils' package.  It includes versions of
 > libplot.a that draw 2-D vector graphics in X11, PS, xfig, and tek format.
 > It also includes a much enhanced `graph' built on top of libplot.a, a
 > version of `spline', and more.  For 2-D graphs, the package is now
 > competitive with gnuplot; it can handle multiplotting, filled regions, etc.
 > The plotting library uses both the 35 basic Postscript fonts, and a set of
 > builtin Hershey fonts.  A 50-page manual in texinfo format is included.
 > 
 > Any comments/suggestions/bug fixes, etc., would be welcome.
 > 
 > --Robert Maier
 > 
 > -- 
 > Robert S. Maier   | Internet: rsm@math.arizona.edu
 > Dept. of Math.    |
 > Univ. of Arizona  |
 > Tucson, AZ  85721 | FAX: +1 520 621 8322
 > U.S.A.            | Voice: +1 520 621 6893 (dept.), +1 520 621 2617 (office)

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From sdm7g@virginia.edu  Sun Mar  9 23:12:41 1997
From: sdm7g@virginia.edu (Steven D. Majewski)
Date: 9 Mar 97 18:12:41 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
Message-ID: <AF48AE51-C53A5@128.143.7.202>



Re: OO vs Functional:

	As another example, XlispStat has plot objects -- scatterplot-proto is
the basic 2d plot object, and spin-plot-proto is the basic 3d object. It 
also has some basic functions: plot-points, plot-lines, plot-function -
that
call scatterplot-proto's :NEW method, and return a plot object, which can
be further manipulated. ( and :NEW typically takes optional keyword args 
with other parameters. ) 
	The one problem with this scheme is that those generic functions all
create scatterplot-proto instances. This limits the ability to customize
the default behaviour of graphs.  You are forced to make changes to 
scatterplot-proto, rather than deriving new classes from it. 
	I would suggest that an extra layer of abstraction or indirection 
is needed. The generic functions should create an instance of 
"USER-PLOT-PROTO" (or whatever it's named) which by default is assigned
to another basic plot object type, but can be redefined to a new class. 


Re: S graphics vs XlispStat 

	I did quite a bit of evaluation of S++, XLispStat, and some other
math/plotting packages before I ended up choosing XlispStat for a project.
What it has that S++ doesn't is a more interactive idea of grapical objects
-- 
it's not just for producing graphical *output*, but graphical objects which
can be manipulated, sometimes with data points in one graph being linked
to data points in another graph. Some of the papers and packages on 
www.stat.ucla.edu are about "manipulating the regression line" - i.e. doing
some grapical "what-if" modeling. I'ld say XlispStat graphics are a much
better model to emulate than S. 

	This is a good realm for all you pattern enthusiasts. The major complaint
I have with XlispStat's graphics is that it's a bit too ad-hoc A network of
interactive plot and control and data objects can easily lead you into the
"spagetti objects" problem. This is what the discipline of patterns in
design
is meant to avoid.
	Python's multiple inheritance makes it possible to implement some basic
common functionality as Mixin's. ( In my xlispstat code, I've tried to use
some basic mixin's like stateful-proto ( things that have NORMAL, SELECTED,
INVISIBLE states and behaviour ) and xlinkable-proto ( things that can be
linked to other objects and broadcast their state changes. ) to simplify
some of this common behaviour of plots and plot-objects. 

- Steve Majewski 
 <sdm7g@Virginia.EDU> 
 <http://galen.med.virginia.edu/~sdm7g/> 








_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From pas@xis.xerox.com  Mon Mar 10 19:10:27 1997
From: pas@xis.xerox.com (Perry A. Stoll)
Date: Mon, 10 Mar 1997 11:10:27 PST
Subject: [PYTHON MATRIX-SIG] Coercion problems solved?
In-Reply-To: <9703090553.AA09883@oldp.nmsu.edu>
Message-ID: <199703101910.OAA29121@fantod.xis.xerox.com>

On  8 Mar, Alan Watson wrote:

>     import UserArray
>     class array32(UserArray.UserArray):
>         def __init__(self, sequence): 
>             UserArray.UserArray.__init__(self, sequence, typecode='f')
>         def __coerce__(self,other): 
>             return (self, UserArray.UserArray(other, typecode='f'))
> 
> This allows me to implement my own `principle of least
> surprise' for coercion, namely that array elements are always 32-bit
> floats. 

Quick question: does anyone know a modern machine which doesn't have a
C float as 32 bits?

FWIW, the following small change guarantees that you will _always_ get a
32 bit float (provided one is available, of course ;):

    import UserArray,Numeric
    class array32(UserArray.UserArray):
        def __init__(self, sequence): 
            UserArray.UserArray.__init__(self, sequence, typecode=Numeric.Float32)
        def __coerce__(self,other): 
            return (self, UserArray.UserArray(other, typecode=Numeric.Float32))

These constants (defined in Precision.py) are mentioned in the docs
distributed with NumPy.

-Perry
 


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From alan@oldp.nmsu.edu  Tue Mar 11 01:54:31 1997
From: alan@oldp.nmsu.edu (Alan Watson)
Date: Mon, 10 Mar 1997 18:54:31 -0700
Subject: [PYTHON MATRIX-SIG] More on Less Copying
Message-ID: <9703110154.AA31948@oldp.nmsu.edu>

Here are some further comments. These come from the perspective of
someone who likes to avoid copying data needlessly.

You may well criticize me that I'm trying to optimize prematurely.
However, some of my swap space is on a really noisy half-height disk,
so I know what it sounds like to page through of order 100 MB.

                            ========

(a) One of my needs is to read large arrays of arbitrary rank from
binary files. The size of the array is known in advance but need not
be equal to the remaining size of the file.

I think I can currently do this by reading the data into a string,
converting it into an array using fromstring(), and then changing the
shape with reshape(). With the current implementation, I cannot see
how to avoid the copying twice (once into the string and once into the
array).

I could get around the problem if a fromfile() or read() function or
method was provided to read a specified amount of data from a file.
Two ways to do this might be:

    a = Numeric.new(shape, typecode)    # create uninitialized new array
    a.read(file)                        # fill array; copy once

and:

    a = Numeric.read(file, shape, typecode)
    
Note that:

    a = zeros(shape, typecode)
    a.read(file)

would not really cut it as it would involve paging through the array
twice. However, a Numeric.new() function might be a useful
generalization of ones() and zeros():

    a = Numeric.new(shape, typecode, value=1)       # initialize to 1
    a = Numeric.new(shape, typecode, value=0)       # initialize to 0
    a = Numeric.new(shape, typecode, value=None)    # do not initialise

Similarly, I can avoid a copy if a tofile() or write() function or
method were provided.

I though about the following:

    a = zeros([ny,nx], type)
    for y in range(0, ny-1):
        str  = read(nx * bytes-in-a-type)
        line = Numeric.fromstring(str)
        a[y,:] = line
        
If Python were C, this would probably be acceptable, because I could
reuse str and line. (My desire to avoid copying is really a desire to
avoid cache and page faults.) However, in Python I have to throw away
line and str each time, so not only do I copy three times but I pump a
fair bit of memory through the garbage collector.

Am I missing something?

                            ========

(b) I've heard mutterings about in-place operations, which avoid a
copy, but they aren't implemented yet. Are these important to others
here? I'm going to assume that they are.

No operators are currently defined in the base language for in-place
operations. That means we have to explicity use methods. I think I
would be willing to live with:

    a.add_inplace(b)

if it avoided a copy. (The method name is just off the top of my head;
see below.)

                            ========

(c) However, there is a non-zero chance that at some point in-place
operations on scalars are going to appear in the base language. It
would be nice to be in a position to be upwardly compatible with that
change.

A problem is that we don't know what method names would be used (i.e.,
what the equivalent of __add__ will be for a += b). Maybe we should
propose a set of method names for these operators that could be
adopted by the base language if it were to adopt in-place operators.
That would, again, give us forwards compatibility.

                            ========

Obviously, with my limited experience I'm not going to jump in and
offer to implement these in C. But I'm aware that James Hugunin has
better things to do than cater to my every whim. I suggest a way
forward is first to discuss whether there is a need for these methods.
If there is an agreed need, we should then discuss their design and
implement them using the existing methods (i.e., implement read using
fromstring and the in-place operations using the copying operations).
At some later point, someone with the appropriate motivation and
experience could rewrite the methods in C. If you wait long enough
that person might even be me. Does that sound reasonable?

I'm very excited by Numeric Python. I wish I didn't have to actually
get any real work done this week and had more time to explore it.

Regards,

Alan

_______________
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 Mar 11 11:49:42 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 11 Mar 1997 12:49:42 +0100
Subject: [PYTHON MATRIX-SIG] More on Less Copying
In-Reply-To: <9703110154.AA31948@oldp.nmsu.edu> (message from Alan Watson on
 Mon, 10 Mar 1997 18:54:31 -0700)
Message-ID: <199703111149.MAA23338@lmspc2.ibs.fr>

> (a) One of my needs is to read large arrays of arbitrary rank from
> binary files. The size of the array is known in advance but need not
> be equal to the remaining size of the file.

You are adressing an important topic that has largely been neglected
so far: file I/O, both in binary and in text form, suitable for
interchanging data with non-Python programs (note that pickle works
fine as long as the format doesn't matter).

> Two ways to do this might be:
> 
>     a = Numeric.new(shape, typecode)    # create uninitialized new array
>     a.read(file)                        # fill array; copy once
> 
> and:
> 
>     a = Numeric.read(file, shape, typecode)

The first version is more general, since it allows to overwrite an
existing array by reading from a file. What I don't like about this
approach is that there is no control over the file format. You must
have a file that uses the same memory layout as NumPy arrays, which
in principle is not documented. In practice, you would know the file
format and want NumPy to do whatever necessary, including perhaps
number format conversion. You might also want to be able to read/write
a subarray.

> (b) I've heard mutterings about in-place operations, which avoid a
> copy, but they aren't implemented yet. Are these important to others
> here? I'm going to assume that they are.
> 
> No operators are currently defined in the base language for in-place
> operations. That means we have to explicity use methods. I think I
> would be willing to live with:
> 
>     a.add_inplace(b)

Try
  Numeric.add(a, b, a)
This will add a and b and put the result into a without creating a
copy.

> (c) However, there is a non-zero chance that at some point in-place
> operations on scalars are going to appear in the base language. It
> would be nice to be in a position to be upwardly compatible with that
> change.

I doubt this will happen. The assumption that numbers are immutable is
pretty basic in Python, and a lot of code would break if it were
violated. At best, operators like += would be added for mutable types
(e.g. lists) and classes. And even that doesn't look like a
high-priority item for future versions.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From fredrik_lundh@ivab.se  Sun Mar  2 20:10:12 1997
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Sun, 2 Mar 1997 21:10:12 +0100
Subject: [PYTHON MATRIX-SIG] Re: [PYTHON IMAGE-SIG] basic IP
In-Reply-To: <1.5.4.32.19970302135442.00665448@linkline.be> (message from Ivan
 Keller on Sun, 02 Mar 1997 14:54:42 +0100)
Message-ID: <9703022010.AA11985@arnold.image.ivab.se>


> I'm looking for a basic image processing Library for Python. I have
> to do mathematical processing, so I only need some module to easy
> manipulate image files. I'm using the pythonwin - Version 1.0 beta 1
> for Windows 95. Can you help me ?

You probably want to use PIL to read and write the files, and
Numerical Python to process them.  You should be able to find more
information via:

	http://www.python.org/sigs/matrix-sig
	http://www.python.org/sigs/image-sig/Imaging.html

There's a binary distribution of PIL available via the latter link,
which works fine with PythonWin (as long you don't use Tk, that is).

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 alan@oldp.nmsu.edu  Tue Mar 11 17:12:34 1997
From: alan@oldp.nmsu.edu (Alan Watson)
Date: Tue, 11 Mar 1997 10:12:34 -0700
Subject: [PYTHON MATRIX-SIG] More on Less Copying
Message-ID: <9703111712.AA11148@oldp.nmsu.edu>

> > (a) One of my needs is to read large arrays of arbitrary rank from
> > binary files. The size of the array is known in advance but need not
> > be equal to the remaining size of the file.
> 
> You are adressing an important topic that has largely been neglected
> so far: file I/O, both in binary and in text form, suitable for
> interchanging data with non-Python programs 

I'm not going to touch text files, but if someone else wants to they
are welcome to join in.

> (note that pickle works
> fine as long as the format doesn't matter).

Yes and no. There is nothing wrong with the interface to pickle, but
the current implementation has an additional copy implied by
tostring().

> > Two ways to do this might be:
> > 
> >     a = Numeric.new(shape, typecode)    # create uninitialized new array
> >     a.read(file)                        # fill array; copy once
> > 
> > and:
> > 
> >     a = Numeric.read(file, shape, typecode)
> 
> The first version is more general, since it allows to overwrite an
> existing array by reading from a file. 

> What I don't like about this
> approach is that there is no control over the file format. You must
> have a file that uses the same memory layout as NumPy arrays, which
> in principle is not documented.  In practice, you would know the file
> format and want NumPy to do whatever necessary, including perhaps
> number format conversion. You might also want to be able to read/write
> a subarray.

Although I cut my teeth on an IBM mainframe, I'm going to show my
UNIX-centricity.

The read() method could treat the data in the file as a byte-stream
defining a sequence of equal-sized elements without gaps or blocking.
It could map between the array and the sequence in the same way that
you map between an array and its ravel(). That way your file does not
need to know the layout of an array.

The problem is the format of the elements. You could survive on most
modern machines by assuming that the elements were either in native
format or byte-swapped native format. You would have a problem
transporting data back and forth between Cray, IBM, VAX, and IEEE
floatign point formats, but a number of tools exist for this already
and the problem gets smaller each year. (The only I interact with a
Cray vector machine nowadays as a front-end to one of their
Alpha-based MPP machines.) I note that the current version of pickle
does not do the conversion.

To my mind, the sticky interface issue is whether to have read() do
the byteswapping or not. If it does it in C, we can avoid another
copy. I'd suggest something along the lines of:

    a = Numeric.new(shape, typecode)
    a.read(file, order=...)
    a.read("file", order=...)

where value=None is implied in the new() function and order is None,
Numeric.LittleEndian, or Numeric.BigEndian in the read() method. None
implies native order. Ditto for write.

I presume you would read and write subarrays using:

    a[1,:].read(file)
    a[1,:].write(file)

Questions: 

    Whose files am I leaving out in the cold?

    What facilities for reading writing arrays as binary and text are
    there in BASIS and Yorick? Are they successful?

> Try
>   Numeric.add(a, b, a)
> This will add a and b and put the result into a without creating a
> copy.

Great. Thanks. These functions look to be exactly what I need.

> I doubt this will happen. The assumption that numbers are immutable is
> pretty basic in Python, and a lot of code would break if it were
> violated. At best, operators like += would be added for mutable types
> (e.g. lists) and classes. And even that doesn't look like a
> high-priority item for future versions.

Operators like += need not break the imutable types; they could act
as a shorthand and might save looking up the same name twice.

Alan Watson

_______________
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 Mar 11 18:34:33 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 11 Mar 1997 13:34:33 -0500
Subject: [PYTHON MATRIX-SIG] More on Less Copying
Message-ID: <01BC2E20.F520CD10@misha.lcs.mit.edu>

Alan Watson writes:
> > > (a) One of my needs is to read large arrays of arbitrary rank from
> > > binary files. The size of the array is known in advance but need not
> > > be equal to the remaining size of the file.
> >
> > You are adressing an important topic that has largely been neglected
> > so far: file I/O, both in binary and in text form, suitable for
> > interchanging data with non-Python programs

This problem can be easily solved with an extension module rather than by 
adding file io methods to array objects.  For many reasons I think this is 
the right solution.  In only the most extreme cases will the temporary 
double memory currently required for an array on file input be a problem. 
 Notice that this memory is used only for a very short time.  In general, 
if your memory is so tight that you can't afford this brief hit on a single 
array, then you're really pushing the limits of where NumPy is applicable 
(vs. hand-crafted C).

I really want to keep the basic array objects as simple as possible with 
the hopes that one day they can be added to the core python distribution. 
 This would make extension writing involving large binary arrays much 
easier for the community at large.

So, I encourage you to code up a file/io module for NumPy arrays.  If I 
like it a lot I might add it to the standard distribution, if not you can 
still easily make it available to all users of NumPy.

> > I doubt this will happen. The assumption that numbers are immutable is
> > pretty basic in Python, and a lot of code would break if it were
> > violated. At best, operators like += would be added for mutable types
> > (e.g. lists) and classes. And even that doesn't look like a
> > high-priority item for future versions.
>
> Operators like += need not break the imutable types; they could act
> as a shorthand and might save looking up the same name twice.

I don't know if his opinions have changed lately, but at the Livermore 
workshop, Guido expressed a definite willingness to consider += operators. 
 The best way to get him to take such a proposal seriously is to code up a 
nice set of patches that implement the new operators and release them for 
comment (hint, hint).

-Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From jim@ks.uiuc.edu  Tue Mar 11 18:34:38 1997
From: jim@ks.uiuc.edu (Jim Phillips)
Date: Tue, 11 Mar 97 12:34:38 -0600
Subject: [PYTHON MATRIX-SIG] Reading text files
In-Reply-To: <9703111712.AA11148@oldp.nmsu.edu>
References: <9703111712.AA11148@oldp.nmsu.edu>
Message-ID: <199703111834.AA219285281@london.ks.uiuc.edu>

Alan Watson wrote:
> I'm not going to touch text files, but if someone else wants to they
> are welcome to join in.

It has been my dream to be able to emulate the following FORTRAN idiom  
(sorry, I don't remember the syntax very well) in Python.

   READ (FILE,"F4.8, F4.8") A(I), B(I), I=1,100

It would be nice if the fortran formatting codes could be used verbatim.  I  
imagine the call would be something like...

   readFortran(file, "F4.8, F4.8", A[0:100], B[0:100])

A and B would need to be preallocated.  If the format was left out one could  
revert to the fortran "*" format, taking types from the arrays.  I like using  
sub-arrays because then one can do things like:

  I = zeros(100,'i')
  A = zeros((3,100),'f')
  readFortran(file, I, A[0], A[1], A[2])

Of course, there are many issues I haven't though about.  One would also want  
to be able to write these files.  More importantly, it would be nice to be  
able to work with FORTRAN binary files which have cryptic block-header stuff  
attached.  Perhaps those should have their own file class.

I've considered attacking this, but the task seemed to daunting.  Would the  
easiest way be to use the fortran library directly?  This would require people  
to get f2c who don't have fortran, but I imagine code would have to be stolen  
from there anyway, and it could run faster if you had an optimized fortran  
library.

-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 Mar 11 18:53:06 1997
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Tue, 11 Mar 1997 19:53:06 +0100
Subject: [PYTHON MATRIX-SIG] More on Less Copying
In-Reply-To: <01BC2E20.F520CD10@misha.lcs.mit.edu> (message from Jim Hugunin
 on Tue, 11 Mar 1997 13:34:33 -0500)
Message-ID: <9703111853.AA19362@arnold.image.ivab.se>


> I don't know if his opinions have changed lately, but at the Livermore 
> workshop, Guido expressed a definite willingness to consider += operators. 

>From the archives...

> > How about providing assignment operators? Some time one has to
> > build a thing piece-meal and this sort of operators are very
> > handy. The semantics are clear:
> >
> > <var> <op>= <expr> === <var> = <var> <op> <expr>
> >
> > Example:
> >  a = 'ba '
> >  a *= 2 # a = 'ba ba'
> >  a += 'black sheep' # a = 'ba ba black sheep'
>
> Agreed. Now that the parser can actually recognize two-character
> operators, adding these wouldn't be so hard (except that the grammar
> tables will grow again :-( ).
>
> > I would also like the capability of overloading standard operators
> > for predefined and user defined classes. Thus instead of
> >  result.append(b)
> > I should be able to say
> >  result += b
> > or better still,
> >  result += [a,b,c]
>
> The latter should automatically work if we let x += y be syntactic
> sugar for x = x+y. Note that result = result + [x] has a different
> meaning than result.append(x), although in many cases it doesn't
> matter: result.append(x) modifies the existing object that result is
> bound to, while result = result+[x] creates a new list (the
> concatenation of result and [x]) and binds result to it, forgetting
> the object to which result was bound previously. If there was another
> reference to that object, e.g., through an assignment "z = result"
> earlier on, the value of z is unchanged by the second form, but
> modified by the first form. Confusing? Yes, but this is a lot better
> than allowing arbitrary pointers!

(November 1991)

We're still waiting ;-)

Cheers	/F (http://hem1.passagen.se/eff)

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From aaron_watters@msn.com  Wed Mar 12 01:45:10 1997
From: aaron_watters@msn.com (aaron watters)
Date: Wed, 12 Mar 97 01:45:10 UT
Subject: [PYTHON MATRIX-SIG] RE: [PYTHONWIN-SIG] The difference between repr and str, and printing
 arrays
Message-ID: <UPMAIL01.199703120150180375@msn.com>

Okay, just got this in my local mail (dunno where it got stuck) so I comment
again (but just to the matrix sig this time).

Generally I think the echo in the interpreter should endeavor to give a value
which if typed back in at the prompt will generate an "equivalent" value, 
ie, the __repr__.

array([ [ [ 1, 1, 1 ], [ 2, 2, 1 ] ],  [ [11, 11, 11],  [ [22, 22, 22] ] ] )

I understand that for arrays you might want something more human-readable, 
like

   1 1 1
   2 2 2
 
   11 11 11
   22 22 22

or whatever, but this, obviously, is not a __repr__ (or a __repr__ "punt" like
<open file "blah" at 0x5643ee>)... I actually use the echo quite a lot to 
generate
constant values to paste into programs...

A compromise position might use a "formatted __repr__" for arrays, ie like

array(
[ [ [ 1, 1, 1 ],
    [ 2, 2, 1 ] ],

  [ [11, 11, 11], 
  [ [22, 22, 22] ] ] )

(if I got the parens right, not using emacs here...)  This would both format 
the
data so a human could see the structure and such that Python could read it 
back
in.  One *could* argue that it actually is more easy to see the structure this 
way,
but I'm not going to do that!  I refuse!   -- Aaron Watters

[of course I violate my own imperatives, abusing __repr__ in IPwP, but
nevermind.]

_______________
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 Mar 12 09:18:04 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 12 Mar 1997 10:18:04 +0100
Subject: [PYTHON MATRIX-SIG] Reading text files
In-Reply-To: <199703111834.AA219285281@london.ks.uiuc.edu> (message from Jim
 Phillips on Tue, 11 Mar 97 12:34:38 -0600)
Message-ID: <199703120918.KAA26775@lmspc2.ibs.fr>

> It has been my dream to be able to emulate the following FORTRAN idiom  
> (sorry, I don't remember the syntax very well) in Python.
> 
>    READ (FILE,"F4.8, F4.8") A(I), B(I), I=1,100

Check out my FortranFormat module at ftp.python.org or on my Web page
(http://www.yi.com/home/HinsenKonrad/python.html). It lets you read
and write lists of objects using a subset of Fortran format strings.

> to be able to write these files.  More importantly, it would be nice to be  
> able to work with FORTRAN binary files which have cryptic block-header stuff  
> attached.  Perhaps those should have their own file class.

I also have a somewhat experimental C extension module that can read
Fortran binary files into arrays. I'll put it on my Web page.

> I've considered attacking this, but the task seemed to daunting.  Would the  
> easiest way be to use the fortran library directly?  This would require people

I'd prefer to avoid Fortran libraries, which add a lot of overhead and
cause installation headaches.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Wed Mar 12 10:41:32 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 12 Mar 1997 11:41:32 +0100
Subject: [PYTHON MATRIX-SIG] More on Less Copying
In-Reply-To: <9703111712.AA11148@oldp.nmsu.edu> (message from Alan Watson on
 Tue, 11 Mar 1997 10:12:34 -0700)
Message-ID: <199703121041.LAA27092@lmspc2.ibs.fr>

> Yes and no. There is nothing wrong with the interface to pickle, but
> the current implementation has an additional copy implied by
> tostring().

Indeed, I hear it every time I save a big array ;-)

> The read() method could treat the data in the file as a byte-stream
> defining a sequence of equal-sized elements without gaps or blocking.
> It could map between the array and the sequence in the same way that
> you map between an array and its ravel(). That way your file does not
> need to know the layout of an array.

Sounds reasonable, assuming that we don't have to deal with files
that themselves have weird layouts. But I can't think of any right
away.

> The problem is the format of the elements. You could survive on most
> modern machines by assuming that the elements were either in native
> format or byte-swapped native format. You would have a problem

I could certainly live with that restriction.

> To my mind, the sticky interface issue is whether to have read() do
> the byteswapping or not. If it does it in C, we can avoid another
> copy. I'd suggest something along the lines of:
> 
>     a = Numeric.new(shape, typecode)
>     a.read(file, order=...)
>     a.read("file", order=...)

Agreed.

> Operators like += need not break the imutable types; they could act
> as a shorthand and might save looking up the same name twice.

In that case we wouldn't have to worry about them, since they would
be mapped to the standard __add__ etc. and would not denote in-place
modification.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Wed Mar 12 10:55:07 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 12 Mar 1997 11:55:07 +0100
Subject: [PYTHON MATRIX-SIG] More on Less Copying
In-Reply-To: <01BC2E20.F520CD10@misha.lcs.mit.edu> (message from Jim Hugunin
 on Tue, 11 Mar 1997 13:34:33 -0500)
Message-ID: <199703121055.LAA27125@lmspc2.ibs.fr>

> > > You are adressing an important topic that has largely been neglected
> > > so far: file I/O, both in binary and in text form, suitable for
> > > interchanging data with non-Python programs
> 
> This problem can be easily solved with an extension module rather than by 
> adding file io methods to array objects.  For many reasons I think this is 

It's fine with me to have I/O in a separate module or even several of
them. That seems like a minor technical detail. However, it would be
nice to have a way to create a non-initialized array at the Python
level.

> the right solution.  In only the most extreme cases will the temporary 
> double memory currently required for an array on file input be a problem. 

I couldn't disagree more. I run into that problem every day!  I have a
30 MB array in a file created by pickle, which I have to read
frequently. It takes a few minutes and the noise made by the disk
isn't pleasant at all.

>  Notice that this memory is used only for a very short time.  In general, 

That makes no difference once you need to access swap space.

> if your memory is so tight that you can't afford this brief hit on a single 
> array, then you're really pushing the limits of where NumPy is applicable 
> (vs. hand-crafted C).

Not at all. My arrays take almost all of physical memory, but there is
no problem during the calculations. Only I/O is a pain.

> I really want to keep the basic array objects as simple as possible with 
> the hopes that one day they can be added to the core python distribution. 

That makes sense, and I see no problem in moving I/O to an external module.
But we still need a good solution...
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From mclay@nist.gov  Wed Mar 12 07:27:23 1997
From: mclay@nist.gov (Michael McLay)
Date: Wed, 12 Mar 1997 02:27:23 -0500
Subject: [PYTHON MATRIX-SIG] RE: [PYTHONWIN-SIG] The difference between repr and str, and printing
 arrays
In-Reply-To: <UPMAIL01.199703120150180375@msn.com>
References: <UPMAIL01.199703120150180375@msn.com>
Message-ID: <199703120727.CAA04315@fermi.eeel.nist.gov>

 > Generally I think the echo in the interpreter should endeavor to
 > give a value 
 > which if typed back in at the prompt will generate an "equivalent" value, 
 > ie, the __repr__.
 > 
 > array([ [ [ 1, 1, 1 ], [ 2, 2, 1 ] ],  [ [11, 11, 11],  [ [22, 22, 22] ] ] )
 > 
 > I understand that for arrays you might want something more human-readable, 
 > like
 > 
 >    1 1 1
 >    2 2 2
 >  
 >    11 11 11
 >    22 22 22
 > 
 > or whatever, but this, obviously, is not a __repr__ (or a __repr__ "punt" like
 > <open file "blah" at 0x5643ee>)... I actually use the echo quite a lot to 
 > generate
 > constant values to paste into programs...

I agree with Aaron.  This is the expected behavior within Python.
Being inconsistant with Matlab user expectations isn't a good reason
to break consistancy with the Python language.  The pretty print
version is readily available by using the print statement, so the more
human readable version is also readily available.

 > 
 > A compromise position might use a "formatted __repr__" for arrays, ie like
 > 
 > array(
 > [ [ [ 1, 1, 1 ],
 >     [ 2, 2, 1 ] ],
 > 
 >   [ [11, 11, 11], 
 >   [ [22, 22, 22] ] ] )
 > 

This is what Jim had planned on doing, but somehow the NT "bug fix" ended
up reversing the use of __str__ and __repr__ in the interactive echo
and the print statement. 


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From tim_one@msn.com  Sat Mar 15 05:20:47 1997
From: tim_one@msn.com (Tim Peters)
Date: Sat, 15 Mar 97 05:20:47 UT
Subject: [PYTHON MATRIX-SIG] FW: Arbitrary precision numbers!
Message-ID: <UPMAIL09.199703150708540890@msn.com>

Lest it escape your number-crunching attentions, please note that Jurjen N.E. 
Bos posted a terrific "infinite precision" real-number library to 
comp.lang.python on Friday, under subject "Arbitrary precision numbers" 
(sorry, I got this off the Python mailing list, so can't supply a proper 
newsgroup reference).  I'll attach the short teaser from the start; the whole 
msg also contains a very clear "user manual" and complete & self-contained 
Python source.  

python!-it's-not-just-for-crappy-floating-point-anymore<wink>-ly y'rs  - tim

The start of Jurjen's msg:

Hi folks:
I just wrote a module "real.py" that allows to do computations with
arbitrary precision numbers. For details, see the file "real.doc" below.
Just to whet your appetite:
>>> from real import pa,exp,pi,sqrt
>>> pa('exp(pi()*sqrt(163))')
262537412640768743.99999999999925007259719818568887935385633733699086270753741
03
782106479101186073129511813461860645041930838879497538640449057287144771968148
52
322432039116478291488642282720131178317065010452226878014448417703469694633557
07
681723887681000923706539519386506362757657888558223948114276912100830886651107
28
471062346581129818301245913283610006498266592365172617883086371078645219552815
42
...

_______________
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 Mar 19 20:16:24 1997
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 19 Mar 1997 15:16:24 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] logical_or and logical_and and # of arguments
Message-ID: <Pine.SGI.3.95q.970319151253.6817D-100000@maigret>


Uh...

If x = arange(5), 

logical_or(greater(x, 1),
           greater(x, 2)
          )

does what I think it should.  So does:

logical_or(greater(x, 1),
           greater(x, 2),
	   greater(x, 3)
          )

[as in (x > 1 || x > 2 || x > 3) ]

but:
 
logical_or(greater(x, 1),
           greater(x, 2),
	   greater(x, 3),
	   greater(x, 4)
          )
 
complains about invalid number of arguments. 

Either logical_or can deal with a large number of arguments or it can't --
if it can't, what does the 3-argument version mean?

--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  Wed Mar 19 20:33:05 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 19 Mar 1997 15:33:05 -0500
Subject: [PYTHON MATRIX-SIG] logical_or and logical_and and # of arguments
Message-ID: <01BC347A.D75B7180@misha.lcs.mit.edu>

David Ascher writes:
...
> Either logical_or can deal with a large number of arguments or it can't 
--
> if it can't, what does the 3-argument version mean?

logical_or is a binary function (it takes two arguments).  As with all 
umath functions, it will take an optional extra argument to specify a 
preexisting array to hold the result of the computation.

All of the umath "functions" (actually they're objects) have a reduce 
method as well.  This method provides an easy way to get the behavior 
you're looking for, ie.

logical_or.reduce( [x1,x2,x3,...,xn] )

will give you what you want.  In fact, this is useful often enough that 
there's a function for it called "sometrue" which is exactly equal to 
logical_or.reduce.

Note: x1, ..., xn must have the same shapes for this to work.  If this is 
not true, then you'll need to use a combination of binary logical_or's.

-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 Mar 19 21:41:12 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 19 Mar 1997 16:41:12 -0500
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
Message-ID: <01BC3484.5B876AA0@misha.lcs.mit.edu>


This version has a number of little bug fixes (the most notable is probably 
Konrad's improved INSTALL instructions).  It also uses a new repr and str 
format for printing arrays.  Neither of these formats are exactly like the 
previous ones, but I've found I really like the new versions.  UserArray 
objects should also work much better this time around.

Incompatible Changes:
* dot now behaves like matrixmultiply used to
* diagonal and trace now work reasonably on arrays with more than 2d
* asarray and array are now much more picky about coercing their array 
arguments.  If this causes people grief I'll consider relaxing this 
restriction for array, but not for asarray.  The "correct" way to 
arbitrarily coerce an array is to use the "astype" method.
* The underlying C function PyArray_FromObject and its variants are 
similarly more strict about coercing their arguments.

It's at the usual site: http://www.sls.lcs.mit.edu/~jjh/numpy

I'm feeling really good about this distribution (except for the difficulty 
of installation under Unix, which I don't have the time or energy to work 
on).  If I don't hear about any serious bugs before this Friday I intend to 
announce this to the main python list so we can get many more novice users 
to really tickle the bugs in the system.  (I'm going to the CHI conference 
for a week leaving on Saturday, so Friday seems like a particularly 
Pythonesque date for me to announce this to the main list).

As usual, enjoy! - 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@xis.xerox.com  Wed Mar 19 21:36:59 1997
From: pas@xis.xerox.com (Perry A. Stoll)
Date: Wed, 19 Mar 1997 13:36:59 PST
Subject: [PYTHON MATRIX-SIG] logical_or and logical_and and # of argumen
 ts
In-Reply-To: <Pine.SGI.3.95q.970319151253.6817D-100000@maigret>
Message-ID: <199703192137.QAA04035@fantod.xis.xerox.com>


Isn't logical_or a ofunc_object? If so, I thought the format was:
ofunc(in1,in2,out=None), meaning you were storing the result of
the operation in the temporary array greater(x,3). Then it's gone.
Try this:

x = arange(5)
y = arange(5)

logical_or(greater(x, 1),
           greater(x, 2),
           y)
print y

Get it?
     
-Perry


On 19 Mar, David Ascher wrote:
> 
> Uh...
> 
> If x = arange(5), 
> 
> logical_or(greater(x, 1),
>            greater(x, 2)
>           )
> 
> does what I think it should.  So does:
> 
> logical_or(greater(x, 1),
>            greater(x, 2),
> 	   greater(x, 3)
>           )
> 
> [as in (x > 1 || x > 2 || x > 3) ]
> 
> but:
>  
> logical_or(greater(x, 1),
>            greater(x, 2),
> 	   greater(x, 3),
> 	   greater(x, 4)
>           )
>  
> complains about invalid number of arguments. 
> 
> Either logical_or can deal with a large number of arguments or it can't --
> if it can't, what does the 3-argument version mean?




_______________
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 Mar 19 22:37:21 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 19 Mar 1997 17:37:21 -0500
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
Message-ID: <01BC348C.3367AEB0@misha.lcs.mit.edu>

David Ascher writes:
> Is NumPyLib-1.0b2.tar.gz  different than the 1.0b1 version?

It's completely unchanged from the 1.0b1 version.  I shouldn't have bumped 
the version number on this one.  I'm too lazy to go back and fix my html, 
so it'll remain 1.0b2, but anybody who already has b1 doesn't need to pick 
this up.

-Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From alan@oldp.nmsu.edu  Thu Mar 20 03:33:54 1997
From: alan@oldp.nmsu.edu (Alan Watson)
Date: Wed, 19 Mar 1997 20:33:54 -0700
Subject: [PYTHON MATRIX-SIG] Re: Numeric Python 1.0 Beta 2 is available
Message-ID: <9703200333.AA04071@oldp.nmsu.edu>

> If I don't hear about any serious bugs before this Friday I intend to 
> announce this to the main python list

I'd like to suggest that a means to create a possibly uninitialized
array of a given shape and type should be part of the basic
functionality, rather than something people have to code in C
themselves.

Some uses of this would be creating arrays that are immediately filled
by C functions (an important special case of this is reading an array
from disk) and supporting large, sparse arrays on systems that allow
malloc() to over-commit a la Fortran.

By allowing an optional initializer, the special cases ones() and
zeros() become convenience functions.

Alan Watson

_______________
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 Mar 20 13:38:00 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 20 Mar 1997 14:38:00 +0100
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <01BC3484.5B876AA0@misha.lcs.mit.edu> (message from Jim Hugunin
 on Wed, 19 Mar 1997 16:41:12 -0500)
Message-ID: <199703201338.OAA07100@lmspc1.ibs.fr>

> I'm feeling really good about this distribution (except for the difficulty 
> of installation under Unix, which I don't have the time or energy to work 
> on).  If I don't hear about any serious bugs before this Friday I intend to 

One possibility would be to have an alternative distribution consisting
of patches to the Python 1.4 distribution. Not as elegant as a separate
extension, but I suppose most users would give preference to simplicity!

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Thu Mar 20 13:52:20 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 20 Mar 1997 14:52:20 +0100
Subject: [PYTHON MATRIX-SIG] Re: Numeric Python 1.0 Beta 2 is available
In-Reply-To: <9703200333.AA04071@oldp.nmsu.edu> (message from Alan Watson on
 Wed, 19 Mar 1997 20:33:54 -0700)
Message-ID: <199703201352.OAA07139@lmspc1.ibs.fr>

> > If I don't hear about any serious bugs before this Friday I intend to 
> > announce this to the main python list
> 
> I'd like to suggest that a means to create a possibly uninitialized
> array of a given shape and type should be part of the basic
> functionality, rather than something people have to code in C
> themselves.

Me too! And it's not just for the benefit of C extensions. It
happens frequently that I want to create an array and fill it
with known data, but different from just ones or zeros. As it is,
I have to initialize it to zero first and then change the values.
With large arrays (-> swapping) this makes a difference.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From furnish@laura.llnl.gov  Thu Mar 20 15:53:46 1997
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Thu, 20 Mar 1997 07:53:46 -0800
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703201338.OAA07100@lmspc1.ibs.fr>
References: <01BC3484.5B876AA0@misha.lcs.mit.edu>
 <199703201338.OAA07100@lmspc1.ibs.fr>
Message-ID: <199703201557.KAA05915@python.org>

Konrad Hinsen writes:
 > > I'm feeling really good about this distribution (except for the
 > > difficulty of installation under Unix, which I don't have the
 > > time or energy to work on).  If I don't hear about any serious
 > > bugs before this Friday I intend to
 > 
 > One possibility would be to have an alternative distribution
 > consisting of patches to the Python 1.4 distribution. Not as
 > elegant as a separate extension, but I suppose most users would
 > give preference to simplicity!

In my opinion, the problem is not specific to NumPy, but is rather a
general shortcoming of python's build paradigm on unix.  I would much
prefer to see Setup expunged in favor of configure --with-xxx options,
which would be more in the spirit of autoconf and would make it much
easier to setup a python with various precompiled extensions linked
in, or made into shared libs.  The drawback of this is that someone
has to revamp configure, and we all know the flamage which acrues to
him who expends effort in that area...

-- 
Geoffrey Furnish		email: furnish@llnl.gov
LLNL X/ICF			phone: 510-424-4227	fax: 510-423-0925

_______________
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 Mar 20 16:45:15 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 20 Mar 1997 17:45:15 +0100
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703201557.KAA05915@python.org> (message from Geoffrey Furnish
 on Thu, 20 Mar 1997 07:53:46 -0800)
Message-ID: <199703201645.RAA08172@lmspc1.ibs.fr>

>  > One possibility would be to have an alternative distribution
>  > consisting of patches to the Python 1.4 distribution. Not as
>  > elegant as a separate extension, but I suppose most users would
>  > give preference to simplicity!
> 
> In my opinion, the problem is not specific to NumPy, but is rather a
> general shortcoming of python's build paradigm on unix.  I would much
> prefer to see Setup expunged in favor of configure --with-xxx options,
> which would be more in the spirit of autoconf and would make it much
> easier to setup a python with various precompiled extensions linked
> in, or made into shared libs.  The drawback of this is that someone

Something like that ought to be done some day, although I am not sure
that autoconf is the way to go (I have no experience with it at all,
but the people I know who do use it seem to be a bit frustrated.)
Anyway, it probably won't happen any time soon.

Another, maybe easier, solution would be to have a better generic
Makefile for extensions, with some provision for installation.
But that won't happen soon either.

Part of the problem is that NumPy installs its Python modules in a
special subdirectory of the Python standard library. Although I like
this feature, it is not strictly necessary (the subdirectory does
not provide a separater "namespace"), and it causes a significant
part of the installation trouble. Should we perhaps drop it for now?
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hugunin@mit.edu  Thu Mar 20 17:03:15 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 20 Mar 1997 12:03:15 -0500
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
Message-ID: <01BC3526.B1A10340@misha.lcs.mit.edu>

Geoffrey Furnish writes:
> In my opinion, the problem is not specific to NumPy, but is rather a
> general shortcoming of python's build paradigm on unix.  I would much
> prefer to see Setup expunged in favor of configure --with-xxx options,
> which would be more in the spirit of autoconf and would make it much
> easier to setup a python with various precompiled extensions linked
> in, or made into shared libs.  The drawback of this is that someone
> has to revamp configure, and we all know the flamage which acrues to
> him who expends effort in that area...

If I was still working in the Unix world, I think that the solution would 
be to write a small python module install script.  This python script would 
basically go through the steps outlined in "INSTALL.txt".  It could have 
hooks for handling different platforms, and in the future could be 
generalized to a system that could work for installing any extension module 
either inside or outside the python source tree.

I really don't think that such a script would be too huge a project, though 
it's unlikely I'll have enough motivation to look into it before the end of 
the millenium...

-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 Mar 20 17:16:27 1997
From: da@maigret.cog.brown.edu (David Ascher)
Date: Thu, 20 Mar 1997 12:16:27 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703201645.RAA08172@lmspc1.ibs.fr>
Message-ID: <Pine.SGI.3.95q.970320121350.8386C-100000@maigret>


> Part of the problem is that NumPy installs its Python modules in a
> special subdirectory of the Python standard library. Although I like
> this feature, it is not strictly necessary (the subdirectory does
> not provide a separater "namespace"), and it causes a significant
> part of the installation trouble. Should we perhaps drop it for now?

I've found that all I need to do is to add NumPy to the main Makefile's
LIBSUBDIRS variable, follow the instructions in NumPy/INSTALL, and it
works fine.  What are the other problems? 

One alternative inspired from the Linux kernel config world is a GUI
configuration management (which could know about all the dependencies,
etc.).  There's a slight bootstrap problem, but it works ok on Linux w/ a
kernel, so...





_______________
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 Mar 20 18:10:55 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 20 Mar 1997 19:10:55 +0100
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <Pine.SGI.3.95q.970320121350.8386C-100000@maigret> (message from
 David Ascher on Thu, 20 Mar 1997 12:16:27 -0500 (EST))
Message-ID: <199703201810.TAA08430@lmspc1.ibs.fr>

> > Part of the problem is that NumPy installs its Python modules in a
> > special subdirectory of the Python standard library. Although I like
> > this feature, it is not strictly necessary (the subdirectory does
> > not provide a separater "namespace"), and it causes a significant
> > part of the installation trouble. Should we perhaps drop it for now?
> 
> I've found that all I need to do is to add NumPy to the main Makefile's
> LIBSUBDIRS variable, follow the instructions in NumPy/INSTALL, and it
> works fine.  What are the other problems? 

Without the added path, steps 3b and 4 of my modified instructions
could be dropped. Step 6 would be reduced to a simple "make install",
instead of the longish explanation there is now. What's left would be:

1) Unpack archives
2) Edit Modules/Setup
3) make install

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From furnish@laura.llnl.gov  Thu Mar 20 18:28:06 1997
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Thu, 20 Mar 1997 10:28:06 -0800
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <Pine.SGI.3.95q.970320121350.8386C-100000@maigret>
References: <199703201645.RAA08172@lmspc1.ibs.fr>
 <Pine.SGI.3.95q.970320121350.8386C-100000@maigret>
Message-ID: <199703201831.NAA06762@python.org>

David Ascher writes:
 > > Part of the problem is that NumPy installs its Python modules in a
 > > special subdirectory of the Python standard library. Although I like
 > > this feature, it is not strictly necessary (the subdirectory does
 > > not provide a separater "namespace"), and it causes a significant
 > > part of the installation trouble. Should we perhaps drop it for now?
 > 
 > I've found that all I need to do is to add NumPy to the main Makefile's
 > LIBSUBDIRS variable, follow the instructions in NumPy/INSTALL, and it
 > works fine.  What are the other problems? 

It all works if you follow the instructions and are willing to rebuild
your python with a modified search directroy list.  Many people have
had problems with the search path being wrong however, if they build
the extension seperately, and install the .py files under .../numpy.
Again, I regard this as a central shortcoming of Python.  The system
used in TeX/LaTeX seems a lot better to me, where directory search
paths are specified effectively as being "rooted at" some place, and
all subdirectories of that are searched.  If python worked like that,
I think many of the installation problems would go away.  However,
this really doesn't have much to do with Numpy per se, except as a
proxy for the general python extension module.

-- 
Geoffrey Furnish		email: furnish@llnl.gov
LLNL X/ICF			phone: 510-424-4227	fax: 510-423-0925

_______________
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 Mar 20 19:13:57 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 20 Mar 1997 20:13:57 +0100
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703201831.NAA06762@python.org> (message from Geoffrey Furnish
 on Thu, 20 Mar 1997 10:28:06 -0800)
Message-ID: <199703201913.UAA08626@lmspc1.ibs.fr>

> Again, I regard this as a central shortcoming of Python.  The system
> used in TeX/LaTeX seems a lot better to me, where directory search
> paths are specified effectively as being "rooted at" some place, and
> all subdirectories of that are searched.  If python worked like that,

Funny to see that suggestion -- I was about to suggest the same in my
last message, but deleted the sentence after I had half written it.
I had suddenly realized that I would definitely not want Python
to go through the subdirectories in my personal module collection,
which includes subdirectories such as "old code to be kept for a while",
"untested code by others" etc.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From furnish@laura.llnl.gov  Thu Mar 20 20:10:31 1997
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Thu, 20 Mar 1997 12:10:31 -0800
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703201913.UAA08626@lmspc1.ibs.fr>
References: <199703201831.NAA06762@python.org>
 <199703201913.UAA08626@lmspc1.ibs.fr>
Message-ID: <199703202014.PAA07311@python.org>

Konrad Hinsen writes:
 > > Again, I regard this as a central shortcoming of Python.  The system
 > > used in TeX/LaTeX seems a lot better to me, where directory search
 > > paths are specified effectively as being "rooted at" some place, and
 > > all subdirectories of that are searched.  If python worked like that,
 > 
 > Funny to see that suggestion -- I was about to suggest the same in my
 > last message, but deleted the sentence after I had half written it.
 > I had suddenly realized that I would definitely not want Python
 > to go through the subdirectories in my personal module collection,
 > which includes subdirectories such as "old code to be kept for a while",
 > "untested code by others" etc.

I'm not really sure if this objection is very strong, I think it is
probably not.  Suppose you have a python installed with
--prefix=/over/there.  Somewhere else in your filespace, you are
developing your foobar package.  You archive your old stuff under
/here/foobar/oldstuff, not under /over/there/foobar/oldstuff.  I mean
really, who develops in an install tree?  Certainly not me.  But the
advantage of the TeX kpathsea business is that you can install a
package under /over/there/foobar and have no trouble with the files
beeing seen via the search mechanism of the previously compiled
executable.  

I maintian that this would be a huge win for python extension
development. 

-- 
Geoffrey Furnish		email: furnish@llnl.gov
LLNL X/ICF			phone: 510-424-4227	fax: 510-423-0925

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From jhauser@ifm.uni-kiel.de  Thu Mar 20 20:32:12 1997
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Thu, 20 Mar 1997 21:32:12 +0100
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703201913.UAA08626@lmspc1.ibs.fr>
References: <199703201831.NAA06762@python.org> <199703201913.UAA08626@lmspc1.ibs.fr>
Message-ID: <9703202032.AA02742@caesar.ifm.uni-kiel.de>

I think this idea should be divided into two parts.

1)
There is a (Python)-systempath, normaly in /usr/local/lib/pyhton
I think it is not a bad idea to scan this directory recursiv and add
all subdirs to the pythonpath

2)
Userdefined directories with *.py files. Here is the fine control on
the userside. She wants perhaps to have modified copys of
standard-modules wich should appear before the standard pythonpath.
I think here is the user responsible for every single directory. And
there is the mechanism to control this with the env-variable
$PYTHONPATH.

__Janko

Konrad Hinsen writes:
 > > Again, I regard this as a central shortcoming of Python.  The system
 > > used in TeX/LaTeX seems a lot better to me, where directory search
 > > paths are specified effectively as being "rooted at" some place, and
 > > all subdirectories of that are searched.  If python worked like that,
 > 
 > Funny to see that suggestion -- I was about to suggest the same in my
 > last message, but deleted the sentence after I had half written it.
 > I had suddenly realized that I would definitely not want Python
 > to go through the subdirectories in my personal module collection,
 > which includes subdirectories such as "old code to be kept for a while",
 > "untested code by others" etc.
 > -- 
 > -------------------------------------------------------------------------------
 > Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
 > Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
 > Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
 > 41, av. des Martyrs                    | Deutsch/Esperanto/English/
 > 38027 Grenoble Cedex 1, France         | Nederlands/Francais
 > -------------------------------------------------------------------------------
 > 
 > _______________
 > MATRIX-SIG  - SIG on Matrix Math for Python
 > 
 > send messages to: matrix-sig@python.org
 > administrivia to: matrix-sig-request@python.org
 > _______________

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hugunin@mit.edu  Thu Mar 20 20:47:30 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 20 Mar 1997 15:47:30 -0500
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
Message-ID: <01BC3546.05895380@misha.lcs.mit.edu>


It's time for me to step in as list moderator on this one ;-)  This 
discussion should really be moved to the main python newsgroup.  I remember 
being involved in a similar discussion there not too long ago where I was 
convinced that scanning directories recursively was a terrible idea, but I 
can't recall the exact reasons any more.  I think that there are some 
strange interactions with "ni" that could cause problems here...

Anyway, if any of these ideas are to succeed, they'll need the support of 
the whole python community.

-Jim

PS - In the NT/95 world this problem is solved using the Registry (a 
database that stores important information for each program/user).  The 
installation process for any extension modules simply updates this registry 
database to include its path.  Nothing quite so simple comes to mind for 
Unix...

Janko Hauser writes:
> I think this idea should be divided into two parts.
>
> 1)
> There is a (Python)-systempath, normaly in /usr/local/lib/pyhton
> I think it is not a bad idea to scan this directory recursiv and add
> all subdirs to the pythonpath
>
> 2)
> Userdefined directories with *.py files. Here is the fine control on
> the userside. She wants perhaps to have modified copys of
> standard-modules wich should appear before the standard pythonpath.
> I think here is the user responsible for every single directory. And
> there is the mechanism to control this with the env-variable
> $PYTHONPATH.
>
> __Janko
>
> Konrad Hinsen writes:
>  > > Again, I regard this as a central shortcoming of Python.  The system
>  > > used in TeX/LaTeX seems a lot better to me, where directory search
>  > > paths are specified effectively as being "rooted at" some place, and
>  > > all subdirectories of that are searched.  If python worked like 
that,
>  >
>  > Funny to see that suggestion -- I was about to suggest the same in my
>  > last message, but deleted the sentence after I had half written it.
>  > I had suddenly realized that I would definitely not want Python
>  > to go through the subdirectories in my personal module collection,
>  > which includes subdirectories such as "old code to be kept for a 
while",
>  > "untested code by others" etc.


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From furnish@laura.llnl.gov  Thu Mar 20 21:18:03 1997
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Thu, 20 Mar 1997 13:18:03 -0800
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <9703202032.AA02742@caesar.ifm.uni-kiel.de>
References: <199703201831.NAA06762@python.org>
 <199703201913.UAA08626@lmspc1.ibs.fr>
 <9703202032.AA02742@caesar.ifm.uni-kiel.de>
Message-ID: <199703202121.QAA07761@python.org>

janko hauser writes:
 > I think this idea should be divided into two parts.
 > 
 > 1)
 > There is a (Python)-systempath, normaly in /usr/local/lib/pyhton
 > I think it is not a bad idea to scan this directory recursiv and add
 > all subdirs to the pythonpath
 > 
 > 2)
 > Userdefined directories with *.py files. Here is the fine control on
 > the userside. She wants perhaps to have modified copys of
 > standard-modules wich should appear before the standard pythonpath.
 > I think here is the user responsible for every single directory. And
 > there is the mechanism to control this with the env-variable
 > $PYTHONPATH.

I believe the TeX Kpathsea thing handles both of these simultaneously
via a distinction in the syntax used to specify the directories.  A
directory which ends in a dirname is not recurseviely searched.  One
that ends in /... is.  So, for example:

setenv PYTHONPATH  /from/here/down/...:/but/exactly/here

My knowledge of the details of kpathsea is kind of fuzzy.  Maybe
someone out there knows exactly how it works...

-- 
Geoffrey Furnish		email: furnish@llnl.gov
LLNL X/ICF			phone: 510-424-4227	fax: 510-423-0925

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From dietmar.schwertberger@student.uni-ulm.de  Thu Mar 20 21:20:04 1997
From: dietmar.schwertberger@student.uni-ulm.de (Dietmar Schwertberger)
Date: Thu, 20 Mar 1997 22:20:04 +0100 (MEZ)
Subject: [PYTHON MATRIX-SIG] ValueError: function not supported
Message-ID: <Marcel-1.09-0320212004-0b02%2U@mstore.rz.uni-ulm.de>


When using NumPy I always get an error
"ValueError: function not supported".

An example is included at the end.


Any ideas what could have gone wrong?

The System I'm using is Acorn RISC OS.



Dietmar


======================================================================


Python 1.4 (Mar 20 1997) [C]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> array([1,2.3,4])

Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "PythonLibs:NumPy.NumPy.py.Numeric", line 113, in array_repr
    return array2string(a, max_line_width, precision, suppress_small, ', ', 1)
  File "PythonLibs:NumPy.NumPy.py.ArrayPrinter", line 46, in array2string
    format, item_length = _floatFormat(data, precision, suppress_small)
  File "PythonLibs:NumPy.NumPy.py.ArrayPrinter", line 94, in _floatFormat
    non_zero = abs(Numeric.compress(not_equal(data, 0), data))
  File "PythonLibs:NumPy.NumPy.py.Numeric", line 285, in compress
    return take(m, nonzero(condition), dimension)
  File "PythonLibs:NumPy.NumPy.py.Numeric", line 263, in nonzero
    return repeat(arange(len(a)), not_equal(a, 0))
  File "PythonLibs:NumPy.NumPy.py.Numeric", line 28, in arrayrange
    m = (add.accumulate(ones((n,), Int))-1)*step + (start + stop-stop)
  File "PythonLibs:NumPy.NumPy.py.Numeric", line 301, in ones
    return zeros(shape, typecode)+array(1, typecode)
ValueError: function not supported
>>> 


_______________
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 Mar 20 21:40:13 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 20 Mar 1997 16:40:13 -0500
Subject: [PYTHON MATRIX-SIG] ValueError: function not supported
Message-ID: <01BC354D.628FB3B0@misha.lcs.mit.edu>

Dietmar writes:
>
> When using NumPy I always get an error
> "ValueError: function not supported".
>
> An example is included at the end.
>
>
> Any ideas what could have gone wrong?
>
> The System I'm using is Acorn RISC OS.

This error is being caused by the function "a+1".  The reason for it is 
that the table of basic functions for arrays has somehow not been loaded in 
your system.  This behavior is very peculiar as your "from Numeric import 
*" should handle this.  As a test, I'd try doing an explicit "import umath" 
and a
>>> dir(umath)
['__', '__doc__', '__file__', '__name__', '__version__', 'absolute', 'add', 
'arccos', 'arcsin', 'arctan', 'arctan2', 'boolean_and', 'boolean_or', 
'boolean_xor', 'ceil', 'conjugate', 'cos', 'cosh', 'divide', 'divide_safe', 
'e', 'equal', 'exp', 'fabs', 'floor', 'fmod', 'greater', 'greater_equal', 
'hypot', 'invert', 'left_shift', 'less', 'less_equal', 'log', 'log10', 
'logical_and', 'logical_not', 'logical_or', 'logical_xor', 'maximum', 
'minimum', 'multiply', 'negative', 'not_equal', 'pi', 'power', 'remainder', 
'right_shift', 'sin', 'sinh', 'sqrt', 'subtract', 'tan', 'tanh']

If you don't get what I show here, then something's very wrong.

My best guess is that you've somehow created another module called umath 
that is confusing python's importer.  Is there any chance of this?

Are you using the 1.0beta2 release?  Are you using dynamic libraries or did 
you build in the source tree?

-Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From carlosm@piper.cs.colorado.edu  Fri Mar 21 00:46:17 1997
From: carlosm@piper.cs.colorado.edu (Carlos Maltzahn)
Date: Thu, 20 Mar 1997 17:46:17 -0700 (MST)
Subject: [PYTHON MATRIX-SIG] Newbie: transpose
Message-ID: <Pine.HPP.3.93.970320173648.14935I-100000@piper.cs.colorado.edu>


Excuse me if the following has been discussed extensively (if so, could
somebody point me to the relevant archive messages?): To me
transpose() seems to act counter-intuitive:

Doing:

>>> b
array([3, 4, 5])
>>> transpose(b)
array([3, 4, 5])
>>>

I expected:

>>> transpose(b)
array([[3],
       [4],
       [5]])
>>>

Doing:

b = b[:,NewAxis]
>>> b
array([[3],
       [4],
       [5]])
>>> c = transpose(b)
>>> c
array([       [3, 4, 5]])
>>> c.shape
(1, 3)
>>>

I expected:

>>> c = transpose(b)
>>> c
array([3, 4, 5])
>>> c.shape
(3,)
>>>

???

Thanks,
Carlos


_______________
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 Mar 21 01:23:53 1997
From: da@maigret.cog.brown.edu (David Ascher)
Date: Thu, 20 Mar 1997 20:23:53 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] Newbie: transpose
In-Reply-To: <Pine.HPP.3.93.970320173648.14935I-100000@piper.cs.colorado.edu>
Message-ID: <Pine.SGI.3.95q.970320201605.9636A-100000@maigret>


> Excuse me if the following has been discussed extensively (if so, could
> somebody point me to the relevant archive messages?): To me
> transpose() seems to act counter-intuitive:

I'll go through your examples in detail, but have you looked at the
tutorial?  It is out of date, I realize, but this sort of stuff is
covered, at least superficially.  If you haven't, I'd love it for you (and
other newbies) to give it a look and suggest improvements.  I *will* work
on it, but not this month...

> Doing:
> 
> >>> b
> array([3, 4, 5])
> >>> transpose(b)
> array([3, 4, 5])
> >>>
> 
> I expected:
> 
> >>> transpose(b)
> array([[3],
>        [4],
>        [5]])
> >>>

>From the tutorial:

transpose() takes an array and returns a new array which corresponds to a
with the order of axes specified by the second argument. The default
corresponds to flipping the order of all the axes (thus it is equivalent
to a.shape[::-1]).

Now the key to understanding why that didn't do what you expected is that
the shape of your array b = array([3,4,5]) is (3,) -- it is a one-tuple --
meaning that it has only one axis (of dimension 3), which can't be swapped
with any other axis.  So transpose() doesn't do anything.

Similarly:

> b = b[:,NewAxis]
> >>> b
> array([[3],
>        [4],
>        [5]])

Now the shape of b is (3,1), so

> >>> c = transpose(b)
> >>> c
> array([       [3, 4, 5]])
> >>> c.shape
> (1, 3)

makes sense as well given the above definition.

> I expected:
> 
> >>> c = transpose(b)
> >>> c
> array([3, 4, 5])
> >>> c.shape
> (3,)

Transpose won't change the rank (number of dimensions, length of shape
tuple), so the only way to go from an array of shape (1,3) to one of shape
(3,) is to slice it.

I hope this helps.  One big issue when learning Numeric is that it is not
MATLAB -- in other words, because it is designed to deal with arrays of
arbitrary rank (and not just 2D matrices), some of the assumptions which
make sense in a linear algebra context don't transfer all that well.  The
other issue I've had is to learn to assimilate what choose, where, etc.
all do and not mix them up.  That comes with practice.

--david


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From amullhau@ix.netcom  Fri Mar 21 02:40:02 1997
From: amullhau@ix.netcom (Andrew P. Mullhaupt)
Date: Thu, 20 Mar 1997 21:40:02 -0500
Subject: [PYTHON MATRIX-SIG] Newbie: transpose
References: <Pine.SGI.3.95q.970320201605.9636A-100000@maigret>
Message-ID: <3331F502.D22@ix.netcom.com>

David Ascher wrote:
> 
> Transpose won't change the rank (number of dimensions, length of shape
> tuple), so the only way to go from an array of shape (1,3) to one of shape
> (3,) is to slice it.
> 
> I hope this helps.  One big issue when learning Numeric is that it is not
> MATLAB -- in other words, because it is designed to deal with arrays of
> arbitrary rank (and not just 2D matrices), some of the assumptions which
> make sense in a linear algebra context don't transfer all that well.  The
> other issue I've had is to learn to assimilate what choose, where, etc.
> all do and not mix them up.  That comes with practice.
> 


Cautionary tale. S is a language which has handled arbitrary rank arrays
for quite a while - I think about twenty years. As recently as version
3.1 (a couple years ago), the behavior of S was the same as what Numeric
Python does now. However, by popular demand, it was changed so that the
transpose of a vector is a 1-column matrix. Note that this gives rise to
the strange situation where transpose is not an involution.

The present behavior of Numerical Python is probably correct, since that
is the way that APL handles this. For most operations on dense
multidimensional arrays, APL provides the best semantics, since they
have been at it longer than anyone else (34 years) and they thought
about it a lot. A really good rule of thumb is that you need an
_exceptionally_ good reason to deviate from APL semantics for dense
multidimensional array semantics or else you will simply find out the
hard way.

Later,
Andrew Mullhaupt

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From R.Hooft@euromail.com  Fri Mar 21 07:51:34 1997
From: R.Hooft@euromail.com (Rob Hooft)
Date: Fri, 21 Mar 1997 08:51:34 +0100 (MET)
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <01BC3546.05895380@misha.lcs.mit.edu>
References: <01BC3546.05895380@misha.lcs.mit.edu>
Message-ID: <199703210751.IAA31837@nu>

>>>>> "JH" == Jim Hugunin <hugunin@mit.edu> writes:

 JH> PS - In the NT/95 world this problem is solved using the Registry
 JH> The installation process for any extension modules simply updates
 JH> this registry database to include its path.

Why not? /usr/lib/python/PYTHONPATH? With one pythonpath directory per
line? Then python does not have to be recompiled for each extension;
only the bootstrap directory is compiled in.

Rob
-- 
=====       R.Hooft@EuroMail.com   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 Mar 21 08:53:52 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 21 Mar 1997 09:53:52 +0100
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703202014.PAA07311@python.org> (message from Geoffrey Furnish
 on Thu, 20 Mar 1997 12:10:31 -0800)
Message-ID: <199703210853.JAA10538@lmspc1.ibs.fr>

> I'm not really sure if this objection is very strong, I think it is
> probably not.  Suppose you have a python installed with
> --prefix=/over/there.  Somewhere else in your filespace, you are
> developing your foobar package.  You archive your old stuff under
> /here/foobar/oldstuff, not under /over/there/foobar/oldstuff.  I mean
> really, who develops in an install tree?  Certainly not me.  But the

Me neither. But I am not sure whether Python could be persuaded
easily to treat just one entry in sys.path differently. Or,
alternatively, whether it can be made to add all subdirectories
in the library directory to sys.path. Either way it looks like
a major modification of the path handling code is necessary.

> I maintian that this would be a huge win for python extension
> development. 

I certainly agree!
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Fri Mar 21 09:08:22 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 21 Mar 1997 10:08:22 +0100
Subject: [PYTHON MATRIX-SIG] NumPy 1.0b2: first comments
Message-ID: <199703210908.KAA10594@lmspc1.ibs.fr>

Yesterday I did a quick installation and a few tests on the new NumPy.
Here are some first comments.

- The installation instructions are missing in the archive.

- During installation, compileall.py reports syntax error in UserArray,
  although it can later be imported without an error message. I have no
  idea how this can happen...

- Complex arrays are not printed correctly:
     >>> 1+0j
     (1+0j)
     >>> array([1+0j])
     array([ 1+j ])
  (In case anyone reports that the complex test code in LinearAlgebra.py
   fails: it doesn't; it's just wrong printing of the results.)

  Here's a quick fix. It may not produce totally correct formatting
  (I didn't check thoroughly), but at least it prints correct values.
  Replace the following function in ArrayPrinter.py:

def _formatComplex(x, real_format, imag_format):
	r = _formatFloat(x.real, real_format)
	i = _formatFloat(x.imag, imag_format, 0)
	if imag_format[-1] == 'f':
		zeros = len(i)
		while zeros > 2 and i[zeros-1] == '0': zeros = zeros-1
		i = i[:zeros] + 'j' + (len(i)-zeros)*' '
	else:
		i = i + 'j'
	return r + i

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Fri Mar 21 09:15:56 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 21 Mar 1997 10:15:56 +0100
Subject: [PYTHON MATRIX-SIG] Numeric Python 1.0 Beta 2 is available
In-Reply-To: <199703210751.IAA31837@nu> (R.Hooft@euromail.com)
Message-ID: <199703210915.KAA10625@lmspc1.ibs.fr>

> Why not? /usr/lib/python/PYTHONPATH? With one pythonpath directory per
> line? Then python does not have to be recompiled for each extension;
> only the bootstrap directory is compiled in.

Great idea! And it shouldn't be much effort to implement.  But I agree
with Jim that this should be discussed in comp.lang.python.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From dietmar.schwertberger@student.uni-ulm.de  Fri Mar 21 15:01:50 1997
From: dietmar.schwertberger@student.uni-ulm.de (Dietmar Schwertberger)
Date: Fri, 21 Mar 1997 16:01:50 +0100 (MEZ)
Subject: [PYTHON MATRIX-SIG] ValueError: function not supported
In-Reply-To: <01BC354D.628FB3B0@misha.lcs.mit.edu>
Message-ID: <Marcel-1.09-0321150150-0b02%2U@mstore.rz.uni-ulm.de>

On Don 20 Mrz, Jim Hugunin wrote:
> This error is being caused by the function "a+1".  The reason for it is 
> that the table of basic functions for arrays has somehow not been loaded in 
> your system.  This behavior is very peculiar as your "from Numeric import 
> *" should handle this.  As a test, I'd try doing an explicit "import umath" 
> and a
> >>> dir(umath)
> ['__', '__doc__', '__file__', '__name__', '__version__', 'absolute', 'add', 
> 'arccos', 'arcsin', 'arctan', 'arctan2', 'boolean_and', 'boolean_or', 
> 'boolean_xor', 'ceil', 'conjugate', 'cos', 'cosh', 'divide', 'divide_safe', 
> 'e', 'equal', 'exp', 'fabs', 'floor', 'fmod', 'greater', 'greater_equal', 
> 'hypot', 'invert', 'left_shift', 'less', 'less_equal', 'log', 'log10', 
> 'logical_and', 'logical_not', 'logical_or', 'logical_xor', 'maximum', 
> 'minimum', 'multiply', 'negative', 'not_equal', 'pi', 'power', 'remainder', 
> 'right_shift', 'sin', 'sinh', 'sqrt', 'subtract', 'tan', 'tanh']
> 
> If you don't get what I show here, then something's very wrong.
My interpreter is missing '__' and '__file__'.
What is '__'? Where does it come from?

Of course '__file__' should be there but I don't think it's causing
the problem.


> My best guess is that you've somehow created another module called umath 
> that is confusing python's importer.  Is there any chance of this?
Only umath and fast_umath from NumPy.


> Are you using the 1.0beta2 release?  Are you using dynamic libraries or did
> you build in the source tree?
I'm using the beta2 release with dynamical loading. The error was also
there with the beta1 release.

Dietmar


_______________
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 Mar 21 16:26:13 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 21 Mar 1997 11:26:13 -0500
Subject: [PYTHON MATRIX-SIG] Newbie: transpose
Message-ID: <01BC35EA.AFEA7990@misha.lcs.mit.edu>

> > Excuse me if the following has been discussed extensively (if so, could
> > somebody point me to the relevant archive messages?): To me
> > transpose() seems to act counter-intuitive:

<Chopped out explanation of how transpose does work.>

> I hope this helps.  One big issue when learning Numeric is that it is not
> MATLAB -- in other words, because it is designed to deal with arrays of
> arbitrary rank (and not just 2D matrices), some of the assumptions which
> make sense in a linear algebra context don't transfer all that well.  The
> other issue I've had is to learn to assimilate what choose, where, etc.
> all do and not mix them up.  That comes with practice.

This is exactly what I wanted to say, but I'd like to add one point.  There 
is a very small module called Matrix.py which attempts to wrap up one of 
these multidimensional array objects as something that behaves much more 
like a linear-algebra matrix.  At the moment it's functionality is minimal, 
to say the least ;-).  I would be thrilled to take improvements to this 
module (i.e. adding a transpose method which behaves as you have 
suggested).

-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 Mar 21 16:35:01 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 21 Mar 1997 11:35:01 -0500
Subject: [PYTHON MATRIX-SIG] ValueError: function not supported
Message-ID: <01BC35EB.EA24D3C0@misha.lcs.mit.edu>


This is very strange behavior!  It could have something to do with dynamic 
linking under the Acorn OS (which I know absolutely nothing about).  Are 
you in a position to build this statically linked into the interpreter? 
 I'd very much like to know if this would make the problem go away.

Another simple test case I'd like to have you try is the following.  Let me 
know how your results compare to mine.

>>> import multiarray
>>> a = multiarray.array([1,2,3])
>>> a
array([1, 2, 3], 'l')
>>> a+1
Traceback (innermost last):
  File "<interactive input>", line 0, in ?
ValueError: function not supported
>>> import umath
>>> a+1
array([2, 3, 4], 'l')

If you're in a position to do c-code debugging, I'd look closely at the 
function call to PyArray_SetNumericOps at the bottom of umathmodule.c.  If 
none of the rest of this helps, and you're not able to debug the C-code, I 
don't think there's anything else I can do to help you.

-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 Mar 21 16:59:34 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 21 Mar 1997 11:59:34 -0500
Subject: [PYTHON MATRIX-SIG] NumPy 1.0b2: first comments
Message-ID: <01BC35EF.589F9300@misha.lcs.mit.edu>

Konrad Hinsen writes:
> Yesterday I did a quick installation and a few tests on the new NumPy.
> Here are some first comments.
...
> - During installation, compileall.py reports syntax error in UserArray,
>   although it can later be imported without an error message. I have no
>   idea how this can happen...

Has anybody else seen this?  Are you sure that it wasn't happening on the 
file UserArrayOld instead?  That was an extra file sitting in the NumPy 
directory that I've elminated for future releases.

>   Here's a quick fix. It may not produce totally correct formatting
>   (I didn't check thoroughly), but at least it prints correct values.
>   Replace the following function in ArrayPrinter.py:

This one's embarrassing.  I'd say printing the correct values is much more 
important than correct formatting!  Thanks for the fix.

-Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From dietmar.schwertberger@student.uni-ulm.de  Fri Mar 21 18:17:41 1997
From: dietmar.schwertberger@student.uni-ulm.de (Dietmar Schwertberger)
Date: Fri, 21 Mar 1997 19:17:41 +0100 (MEZ)
Subject: [PYTHON MATRIX-SIG] ValueError: function not supported
In-Reply-To: <01BC35EB.EA24D3C0@misha.lcs.mit.edu>
Message-ID: <Marcel-1.09-0321181741-b492%2U@s_dschwe.dillingen.baynet.de>

On Fre 21 Mrz, Jim Hugunin wrote:
> 
> This is very strange behavior!  It could have something to do with dynamic 
> linking under the Acorn OS (which I know absolutely nothing about).  Are 
Yes, Acorns are quite seldom - especially in the US.

> you in a position to build this statically linked into the interpreter? 
I will try to do so over the weekend.


>  I'd very much like to know if this would make the problem go away.
> 
> Another simple test case I'd like to have you try is the following.  Let me 
> know how your results compare to mine.
> 
> >>> import multiarray
> >>> a = multiarray.array([1,2,3])
> >>> a
> array([1, 2, 3], 'l')
> >>> a+1
> Traceback (innermost last):
>   File "<interactive input>", line 0, in ?
> ValueError: function not supported
> >>> import umath
> >>> a+1
> array([2, 3, 4], 'l')

My result:

Python 1.4 (Mar 20 1997) [C]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import multiarray
>>> a=multiarray.array([1,2,3])
>>> a
array([1, 2, 3], 'l')
>>> a+1
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: function not supported
>>> import umath
>>> a+1
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: function not supported
>>> 


> If you're in a position to do c-code debugging, I'd look closely at the 
> function call to PyArray_SetNumericOps at the bottom of umathmodule.c.  If 
With a statically linked System, it should be possible to use the debugger.


> none of the rest of this helps, and you're not able to debug the C-code, I 
> don't think there's anything else I can do to help you.
You've already done a lot. Thanks,


Dietmar


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From carlosm@piper.cs.colorado.edu  Fri Mar 21 18:47:44 1997
From: carlosm@piper.cs.colorado.edu (Carlos Maltzahn)
Date: Fri, 21 Mar 1997 11:47:44 -0700 (MST)
Subject: [PYTHON MATRIX-SIG] LinearAlgebra.test() core dumps
In-Reply-To: <199703210908.KAA10594@lmspc1.ibs.fr>
Message-ID: <Pine.HPP.3.93.970321112300.21262D-100000@piper.cs.colorado.edu>


I installed Python 1.4 and NumPy 1.0b2 yesterday including NumPyLib. 
Everything seems to work fine except the LinearAlgebra module - it core
dumps on the test program:

raboof:NumPy[0] python LinearAlgebra.py
All numbers printed should be (almost) zero:
Floating exception (core dumped)
raboof:NumPy[136]

This happens on an Alpha with Digital UNIX V4.0A  (Rev. 464).

Carlos


_______________
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 Mar 21 21:04:31 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 21 Mar 1997 16:04:31 -0500
Subject: [PYTHON MATRIX-SIG] LinearAlgebra.test() core dumps
Message-ID: <01BC3611.90810610@misha.lcs.mit.edu>

Carlos writes:
>
> I installed Python 1.4 and NumPy 1.0b2 yesterday including NumPyLib.
> Everything seems to work fine except the LinearAlgebra module - it core
> dumps on the test program:
>
> raboof:NumPy[0] python LinearAlgebra.py
> All numbers printed should be (almost) zero:
> Floating exception (core dumped)
> raboof:NumPy[136]
>
> This happens on an Alpha with Digital UNIX V4.0A  (Rev. 464).

You're seeing this problem because of the Alpha's interesting treatment of 
IEEE exceptions.  For cases where almost every other processor would return 
either Inf or NaN, the Alpha will generally just dump core.  I've been told 
that there are some very good reasons for this, but...

There are several solutions to this problem:

1) None of this code should be generating IEEE exceptions.  If you can 
track down the code that's causing the problem, I'd be happy to fix it 
which would make this go away for this case.

2) You can convince your alpha compiler to generate code that will honor 
ieee exceptions properly.  This is done with compile time flags (should be 
obvious from the man pages) and will produce a significant performance 
penalty, but should make all of these sorts of problems go away.

3) Somebody at LLNL was working on better handling of floating point 
exceptions within python in general.  If you can get in touch with them you 
might be able to produce a "perfect" solution with a fair bit of work.

Good luck - Jim

PS - If you didn't have this problem in the beta 1 release then the problem 
is almost certainly in the array printing code (if you want a hint on where 
to look).


_______________
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 Mar 21 21:34:13 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 21 Mar 1997 16:34:13 -0500
Subject: [PYTHON MATRIX-SIG] Numeric Extensions to Python Available for Public Beta Test
Message-ID: <9703212134.AA23868@goldilocks>


What is Numeric Python?

The Numeric Extensions to Python (NumPy) add powerful multi-dimensional
array objects to the wonderful general purpose programming language Python.
These new objects give Python the number crunching power of numeric
languages like Matlab and IDL while maintaining all of the advantages of
the general-purpose programming language Python.

A little history...

There's been a project going on within one of Python's wonderful Special
Interest Groups to develop a set of extensions to support "Numerical"
programming within Python.  This project began in September, 1995.  After
about 17 releases of pre-alpha and alpha versions of the system within the
community of the matrix-sig, I have finally decided that the system is
sufficiently stable for "prime-time".

If you are interested in more information (including downloads of the
system) check out http://www.sls.lcs.mit.edu/~jjh/numpy.

Enjoy! - Jim Hugunin - hugunin@mit.edu

PS - The installation process is trivial under Windows NT/95 thanks mainly
to Mark Hammond's work on that platform.  Installation under Unix is a bit
of a headache, but this seem to be a general problem for extension modules.
 Any patches or code to improve this process are welcome.

PPS - In the grand Python tradition I will be away all next week at the CHI
conference in Atlanta, Georgia.  So, comments are welcome but don't expect
any replies until April 1.


_______________
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 Mar 21 21:40:34 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 21 Mar 1997 16:40:34 -0500
Subject: [PYTHON MATRIX-SIG] Beta 3 Released - Notes to matrix-sig community
Message-ID: <01BC3616.99D3B460@misha.lcs.mit.edu>


I just put together a beta 3 release on my web site and announced it on the 
main python list.  There were very few significant bugs found in the beta1 
or beta2 releases, and I think that it's time to try and encourage more 
people to play with this system to help track down the remaining bugs as 
quickly as possible.  This "public" release also means that I'm getting 
very serious about maintaining backwards compatibility.

I must admit that I currently have no idea how future discussion should be 
partitioned between this list and the main one in the future, but I'll 
leave that decision for another day.

The beta 3 distribution fixes the bug Konrad reported recently with 
printing arrays of complex numbers (and adds Install.txt to the tar file). 
 If you make the change he suggests in his mail to your beta2 release, you 
should have no reason to pick up beta3.

-Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From dietmar.schwertberger@student.uni-ulm.de  Fri Mar 21 23:09:36 1997
From: dietmar.schwertberger@student.uni-ulm.de (Dietmar Schwertberger)
Date: Sat, 22 Mar 1997 00:09:36 +0100 (MEZ)
Subject: [PYTHON MATRIX-SIG] ValueError: function not supported
In-Reply-To: <Marcel-1.09-0321201847-d072%2U@s_dschwe.dillingen.baynet.de>
Message-ID: <Marcel-1.09-0321230936-0b02%2U@s_dschwe.dillingen.baynet.de>

On Fre 21 Mrz, Dietmar Schwertberger wrote:
> On Fre 21 Mrz, Jim Hugunin wrote:
> > 
> > This is very strange behavior!  It could have something to do with dynamic 
> > linking under the Acorn OS (which I know absolutely nothing about).  Are 
> > you in a position to build this statically linked into the interpreter? 
> I will try to do so over the weekend.

I have tried static linking and it works all fine. It was necessary to
link both umath and multiarray statically.
Maybe I will find the problem with the dynamic linking system.

Thank you very much for your effort.


Dietmar


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From viennet@ura1507.univ-paris13.fr  Fri Mar 28 21:15:21 1997
From: viennet@ura1507.univ-paris13.fr (viennet@ura1507.univ-paris13.fr)
Date: Fri, 28 Mar 1997 22:15:21 +0100
Subject: [PYTHON MATRIX-SIG] Suggestion for pickle
Message-ID: <199703282115.WAA24382@sapporo.ibp.fr>


 I'm not totally satisfied with the current interaction between the
pickle module and NumPy.

 Numeric.py defines two sub-classes, Pickler and Unpickler to be able
to pickle/unpickle NumPy arrays. One can use these classes in the
following way: 

from Numeric import *
a = array( [1,2,3,7], Float32 )
p = Pickler( open( 'test.pck', 'w' ) )
p.dump( a )

 But NOT using the standard pickle.Pickler and pickle.Unpickler
classes, which is sometimes annoying.
I suggest to directly modify the original classes: just add

pickle.Unpickler = Unpickler
pickle.Pickler = Pickler

at the end of Numeric.py

Comments ?

Emmanuel

-- 
Emmanuel Viennet: <viennet@ura1507.univ-paris13.fr>
LIPN - Institut Galilee - Universite Paris-Nord       
93430 Villetaneuse -  France

_______________
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 Mar 31 20:02:08 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 31 Mar 1997 15:02:08 -0500
Subject: [PYTHON MATRIX-SIG] RE: Conversion
Message-ID: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu>

Guido writes:
...
> > Looking at the source, I see that complex numbers have a 3rd
> > data attribute, "conj", which returns the same as the .conjugate()
> > method. I don't like this very much (because there's already the
> > method, and because it really isn't a "component" of the complex
> > number like its real and imag components are) but am afraid to
> > remove it out of fear of breaking anything.  Am I overly worried?
>
> I'll yield to Jim & the Matrix folks on that -- I didn't know even know 
.conj
> existed, and agree that "it shouldn't".

In my opinion, .conj shouldn't exist.  I tried to get Konrad to take it out 
at some early point in the development of complexobject.c.  I wouldn't 
worry about breaking anything, but I'm cross-posting to the matrix-sig to 
give others a chance to shout if you'll be breaking their code.

-Jim

Note: for NumPy arrays there is neither a ".conj" attribute nor a 
".conjugate()" method.  Instead there is a "conjugate(a)" function which 
will work on any number-like python object in the right manner.  There 
seemed to be agreement within the SIG that this function is what everybody 
really wanted anyway.
 


_______________
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 Mar 31 20:32:57 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 31 Mar 1997 22:32:57 +0200
Subject: [PYTHON MATRIX-SIG] RE: Conversion
In-Reply-To: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu> (message from Jim Hugunin
 on Mon, 31 Mar 1997 15:02:08 -0500)
Message-ID: <199703312032.WAA03122@lmspc1.ibs.fr>

> In my opinion, .conj shouldn't exist.  I tried to get Konrad to take it out 
> at some early point in the development of complexobject.c.  I wouldn't 

And I think I agreed but never got around to actually removing it :-(
Originally I put this in because it seemed the easiest "quick hack" to
get conjugates (there was no umath at that time, and I didn't want to
add another built-in function). I agree that the cfunction conjugate()
in umath is the best solution, but since complex numbers are part of
standard Python now, whereas NumPy (and therefore umath) is not, I wonder
whether not having a conjugate function without NumPy would be OK.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________