From da@maigret.cog.brown.edu  Wed Oct  2 00:13:04 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 1 Oct 1996 19:13:04 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] gistmodule question
Message-ID: <199610012313.TAA04540@maigret>

Again, not directly NumPy related, but...

When I output from gist into a .ps file using:

	hcp_file('foo.ps')
	hcp()

I get the output just fine, but then I also get junk text at the bottom
of the page.  Has anyone else seen this?  Is this a gist bug or a
gistmodule bug?

--david

PS: does anyone have a "fast" way to go from PS to GIF?  I have to use
    ghostscript for now, which is very very slow, especially since I
    have to go through PPM...

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From Anthony Baxter <arb@connect.com.au>  Wed Oct  2 03:34:44 1996
From: Anthony Baxter <arb@connect.com.au> (Anthony Baxter)
Date: Wed, 02 Oct 1996 12:34:44 +1000
Subject: [PYTHON MATRIX-SIG] gistmodule question
In-Reply-To: Your message of "Tue, 01 Oct 1996 19:13:04 -0400."
 <199610012313.TAA04540@maigret>
Message-ID: <199610020234.MAA01805@jambu.off.connect.com.au>


>>> David Ascher wrote
> PS: does anyone have a "fast" way to go from PS to GIF?  I have to use
>     ghostscript for now, which is very very slow, especially since I
>     have to go through PPM...

Note that ghostscript can write to more useful formats, such as various
tiff formats. Once upon a time it could write gif files, but the compuserve
patent stopped that - but you can probably find the necessary driver in older
source distributions of ghostscript.

Anthony

=================
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 Oct  2 18:38:02 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 2 Oct 96 18:38:02 +0100
Subject: [PYTHON MATRIX-SIG] Pickling arrays
Message-ID: <199610021738.SAA25985@ibs.ibs.fr>

Recently seen on my computer screen:

Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/tmp/pythona05330", line 42, in ?
    pickle.dump(h, file)
  File "/usr/local/lib/python1.4/pickle.py", line 547, in dump
    Pickler(file).dump(object)
  File "/usr/local/lib/python1.4/pickle.py", line 189, in dump
    self.save(object)
  File "/usr/local/lib/python1.4/pickle.py", line 208, in save
    raise PicklingError, \
pickle.PicklingError: can't pickle 'array' objects

Didn't this work at some point? Should it work? Should I do something
else?
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jim.fulton@digicool.com  Wed Oct  2 19:16:54 1996
From: jim.fulton@digicool.com (Jim Fulton)
Date: Wed, 02 Oct 1996 14:16:54 -0400
Subject: [PYTHON MATRIX-SIG] Pickling arrays
References: <199610021738.SAA25985@ibs.ibs.fr>
Message-ID: <3252B196.3189@digicool.com>

Konrad Hinsen wrote:
> 
> Recently seen on my computer screen:
> 
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
>   File "/usr/tmp/pythona05330", line 42, in ?
>     pickle.dump(h, file)
>   File "/usr/local/lib/python1.4/pickle.py", line 547, in dump
>     Pickler(file).dump(object)
>   File "/usr/local/lib/python1.4/pickle.py", line 189, in dump
>     self.save(object)
>   File "/usr/local/lib/python1.4/pickle.py", line 208, in save
>     raise PicklingError, \
> pickle.PicklingError: can't pickle 'array' objects
> 
> Didn't this work at some point? 

Not without a modified pickle module.

> Should it work? Should I do something
> else?

The pickle module in 1.4 will allow built-in objects that
behave like instances to be pickled.  Objects must have a
__class__ attribute that is bound to a callable object that
is not a python or C function.

In a couple of weeks I will release an "Extension Class"
module that will, among other things, facilitate building 
built-in types that behave like classes and whos instances
behave like python instances.  In particular, built-in 
instances based on extension classes will be picklable.

The primary benefit of extension classes is that they
can be subclassed in Python.

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  Wed Oct  2 21:58:10 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 2 Oct 1996 16:58:10 -0400
Subject: [PYTHON MATRIX-SIG] Pickling arrays
Message-ID: <9610022055.AA25885@goldilocks.LCS.MIT.EDU>

> > Recently seen on my computer screen:
> > pickle.PicklingError: can't pickle 'array' objects
> > 
> > Didn't this work at some point? 
> 
> Not without a modified pickle module.
> 
> > Should it work? Should I do something
> > else?

Numeric.py (or Core.py if using packages) subclasses the pickle object, so
if you use Numeric.dump(object, fp) it will work for all types handled by
pickle as well as arrays.

See the source code to Numeric.py for details ;-)
-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@anchor.cs.colorado.edu  Thu Oct  3 00:33:18 1996
From: carlosm@anchor.cs.colorado.edu (Carlos Maltzahn)
Date: Wed, 2 Oct 1996 17:33:18 -0600 (MDT)
Subject: [PYTHON MATRIX-SIG] compile problems
Message-ID: <199610022333.RAA05706@anchor.cs.colorado.edu>

I tried to compile NumPy 1.0a4 with Python 1.3 and got a lot of error messages
(see below). To me it looks like you are assuming Python 1.4, maybe? 
Since for some reason I can't get Python 1.4 to compile on my alpha+osf1 
machine: is there a working version that compiles with Python 1.3? Or am
I missing something else?

Thanks,
Carlos

-------
gcc -O4 -I./../Include -I.. -DHAVE_CONFIG_H  -I../NumPy/Include -c ./../NumPy/ar
rayobject.c
../NumPy/arraytypes.c: In function `CFLOAT_to_OBJECT':
In file included from ./../NumPy/arrayobject.c:201:
../NumPy/arraytypes.c:477: warning: assignment makes pointer from integer withou
t a cast
../NumPy/arraytypes.c: In function `CFLOAT_getitem':
../NumPy/arraytypes.c:479: warning: return makes pointer from integer without a 
cast
../NumPy/arraytypes.c: In function `CDOUBLE_to_OBJECT':
../NumPy/arraytypes.c:532: warning: assignment makes pointer from integer withou
t a cast
../NumPy/arraytypes.c: In function `CDOUBLE_getitem':
../NumPy/arraytypes.c:534: warning: return makes pointer from integer without a 
cast
./../NumPy/arrayobject.c: At top level:
./../NumPy/arrayobject.c:524: parse error before `*'
./../NumPy/arrayobject.c: In function `slice_GetIndices':
./../NumPy/arrayobject.c:527: `r' undeclared (first use this function)
./../NumPy/arrayobject.c:527: (Each undeclared identifier is reported only once
./../NumPy/arrayobject.c:527: for each function it appears in.)
./../NumPy/arrayobject.c:528: `step' undeclared (first use this function)
./../NumPy/arrayobject.c:534: `start' undeclared (first use this function)
./../NumPy/arrayobject.c:534: `length' undeclared (first use this function)
./../NumPy/arrayobject.c:541: `stop' undeclared (first use this function)
./../NumPy/arrayobject.c: In function `get_slice':
./../NumPy/arrayobject.c:560: `PySliceObject' undeclared (first use this functio
n)
./../NumPy/arrayobject.c:560: parse error before `)'
./../NumPy/arrayobject.c: In function `parse_subindex':
./../NumPy/arrayobject.c:591: `Py_Ellipses' undeclared (first use this function)
./../NumPy/arrayobject.c: In function `parse_index':
./../NumPy/arrayobject.c:629: `Py_Ellipses' undeclared (first use this function)
./../NumPy/arrayobject.c: In function `array_cast':
./../NumPy/arrayobject.c:1184: `PyComplex_Type' undeclared (first use this funct
ion)
make[1]: *** [arrayobject.o] Error 1
make[1]: Leaving directory `/nfs/lheureux/research/db/h2o/carlos/Python-1.3/Modu
les'
make: *** [python] Error 2
raboof:python[2]  


=================
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 Oct  3 10:10:01 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 3 Oct 96 10:10:01 +0100
Subject: [PYTHON MATRIX-SIG] Pickling arrays
In-Reply-To: <3252B196.3189@digicool.com> (message from Jim Fulton on Wed, 02
 Oct 1996 14:16:54 -0400)
Message-ID: <199610030910.KAA28258@ibs.ibs.fr>

> > Didn't this work at some point? 
> 
> Not without a modified pickle module.

Then that's what we had once. I found some old code which used pickle to
store some complicated list whose elements included arrays, and I know
it worked...

> The pickle module in 1.4 will allow built-in objects that
> behave like instances to be pickled.  Objects must have a
> __class__ attribute that is bound to a callable object that
> is not a python or C function.

I wonder what the point of the last restriction is - if a C function
were acceptable, then it would be straightforward to implement a fake
class attribute.

> In a couple of weeks I will release an "Extension Class"
> module that will, among other things, facilitate building 
> built-in types that behave like classes and whos instances
> behave like python instances.  In particular, built-in 
> instances based on extension classes will be picklable.
>
> The primary benefit of extension classes is that they
> can be subclassed in Python.

Sounds like what I have always wanted...

Of course the solution that Jim (the other one) pointed out works, but
if for every new C type someone writes a specialized pickle
look-alike, we will end up with a big mess and no way to pickle
e.g. lists that contain various such types.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Thu Oct  3 18:11:15 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 3 Oct 1996 13:11:15 -0400
Subject: [PYTHON MATRIX-SIG] compile problems
Message-ID: <9610031708.AA07823@goldilocks.LCS.MIT.EDU>

> I tried to compile NumPy 1.0a4 with Python 1.3 and got a lot of error
messages
> (see below). To me it looks like you are assuming Python 1.4, maybe? 
> Since for some reason I can't get Python 1.4 to compile on my alpha+osf1 
> machine: is there a working version that compiles with Python 1.3? Or am
> I missing something else?

NumPy1.0a4 will only work with Python1.4.  There are a number of small
changes that have been made to Python 1.4 in order to support NumPy (and
similar extensions), and I take full advantage of them.  NumPy0.36 is the
last version that works with Python1.3.

I have had no problem building Python1.4 on my alpha/osf machine using gcc.
 I'd reccommend going that route for now until the official release of 1.4
(which knowing Guido will compilke out of the box just about everywhere).

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Thu Oct  3 18:14:18 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 3 Oct 1996 13:14:18 -0400
Subject: [PYTHON MATRIX-SIG] Thanks for your help
Message-ID: <9610031711.AA07874@goldilocks.LCS.MIT.EDU>


I'd like to thank almost all of you for your endorsements of this project. 
I passed my OQE with no problems, one of my examiners even said it was the
most enjoyable OQE talk she'd ever been to.

Thanks for your help and I'll try and return the favor with a speedy
release of beta1.

-Jim

=================
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 Oct  3 19:28:19 1996
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Thu, 3 Oct 1996 20:28:19 +0200
Subject: [PYTHON MATRIX-SIG] Pickling arrays
In-Reply-To: <199610021738.SAA25985@ibs.ibs.fr>
References: <9610031708.AA07823@goldilocks.LCS.MIT.EDU> <9610031711.AA07874@goldilocks.LCS.MIT.EDU> <3252B196.3189@digicool.com> <199610030910.KAA28258@ibs.ibs.fr> <199610022333.RAA05706@anchor.cs.colorado.edu> <9610022055.AA25885@goldilocks.LCS.MIT.EDU> <199610021738.SAA25985@ibs.ibs.fr>
Message-ID: <9610031828.AA31216@caesar.ifm.uni-kiel.de>


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From Rob.Hooft@embl-heidelberg.de  Fri Oct  4 20:02:10 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Fri, 4 Oct 1996 21:02:10 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] LinearAlgebra on Alpha.
Message-ID: <199610041902.VAA20065@nu>

I just tried some LinearAlgebra routines on DEC ALPHA, and got some
unexpected results: All zero's. What can I do to debug this?

>>> import ni,Numeric
>>> import Numeric.LinearAlgebra
>>> LA=Numeric.LinearAlgebra
>>> a=Numeric.array([[1.,0.,0.],[0.,1.,0.],[0.,0.,1.]])
>>> LA.eigenvectors(a)
( 0.  0.  0.,  0.  0.  0.
 0.  0.  0.
 0.  0.  0.)
>>> LA.singular_value_decomposition(a)
( 0.  0.  0.
 0.  0.  0.
 0.  0.  0.,  0.  0.  0.,  0.  0.  0.
 0.  0.  0.
 0.  0.  0.)
>>> LA.generalized_inverse(a) 
 0.  0.  0.
 0.  0.  0.
 0.  0.  0.

Regards,
-- 
=== Rob.Hooft@EMBL-Heidelberg.DE   http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling?  http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures?  http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux!  Free Software Rules The World! =============

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From drh@oasis.unl.edu  Fri Oct  4 22:00:13 1996
From: drh@oasis.unl.edu (Doug Heisterkamp)
Date: Fri, 4 Oct 1996 16:00:13 -0500
Subject: [PYTHON MATRIX-SIG] RE: LinearAlgebra on Alpha.
Message-ID: <199610042100.QAA16487@oasis.unl.edu>

From: Rob.Hooft@embl-heidelberg.de
To: matrix-sig@python.org
Subject: [PYTHON MATRIX-SIG] LinearAlgebra on Alpha.
Mime-Version: 1.0 (generated by tm-edit 7.89)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-matrix-sig@python.org
Precedence: bulk
Status: OR

Hi,

Are you using existing LAPACK libraries or the source sent with
NumPy?  

In either case, make sure that the typedef of f2c_complex and 
f2c_doublecomplex at the begining of lapack_litemodule.c matches
the form with which your LAPACK library was built.  Now that f2c.h is
distributed with NumPy, the lapack module should read it so all
the type changes are in one file.

Doug Heisterkamp
drh@oasis.unl.edu


> I just tried some LinearAlgebra routines on DEC ALPHA, and got some
> unexpected results: All zero's. What can I do to debug this?
>
> >>> import ni,Numeric
> >>> import Numeric.LinearAlgebra
> >>> LA=Numeric.LinearAlgebra
> >>> a=Numeric.array([[1.,0.,0.],[0.,1.,0.],[0.,0.,1.]])
> >>> LA.eigenvectors(a)
> ( 0.  0.  0.,  0.  0.  0.
>  0.  0.  0.
>  0.  0.  0.)
> >>> LA.singular_value_decomposition(a)
> ( 0.  0.  0.
>  0.  0.  0.
>  0.  0.  0.,  0.  0.  0.,  0.  0.  0.
>  0.  0.  0.
>  0.  0.  0.)
> >>> LA.generalized_inverse(a) 
>  0.  0.  0.
>  0.  0.  0.
>  0.  0.  0.
>
> Regards,
> -- 
> === Rob.Hooft@EMBL-Heidelberg.DE   http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
> ==== In need of protein modeling?  http://www.Sander.EMBL-Heidelberg.DE/whatif/
> Validation of protein structures?  http://biotech.EMBL-Heidelberg.DE:8400/ ====
> == PGPid 0xFA19277D == Use Linux!  Free Software Rules The World! =============


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jhauser@ifm.uni-kiel.de  Tue Oct  8 13:06:10 1996
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Tue, 8 Oct 1996 14:06:10 +0200
Subject: [PYTHON MATRIX-SIG] Creating grid object
Message-ID: <9610081206.AA04295@flores.ifm.uni-kiel.de>

Hello, I want to use Numpy (is this name "official"?) to build an
analysis package for a numerical model. At the moment I implement some
simple functions, which are working on array-arguments. Now I get the
idea, that it would nice to have an array-object of a variable say
salinity, with an attribut about the edges of the grid the variable is
defined on, so that I can work on arbitray blocks and can get the
information where this block is later.

I want to define the hole grid as a global variable and let the edges
in the new object point at a subregion of the grid. I'm new to python
and object-oriented programming, but I think that I must define my own
class. My problem now is, that I want to do normal math directly with
this object, like

    sal_anomaly_on_grid = sal_on_grid - mean_sal_in_depth_on_this_grid

	 ^new object        ^new object     ^normal 1d array

At the moment I know only to do something like

    sal_anomaly_on_grid = sal_on_grid.data - mean_sal_in_depth_on_this_grid

	^normal array       ^new object        ^normal array

My grid is defined in two 2d-arrays x_loc,y_loc and one 3d-array  z with
depth of x,y in n layers. My first idea is to have an attribut in the new
object, wich is a list of 16 points

	x_loc(index_of_x_starting_location)
	x_loc(index_of_y_starting_location)
	x_loc(index_of_x_stop_location)
	x_loc(index_of_y_stop_location)
	4 y_loc(...)
	8 z

But it would be better, to have references to each gridpoint, to allow
more flexibel grids, but this is perhaps memory-consuming. Is it
possible to build something like this?  Is the definition of such
classes covered in one of the new python-books? Or must I program
something in C (I hope not).

Last but not least, is this group the right place to ask? I think I
will have more questions in the future.

TIA

	Janko Hauser


=================
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 Oct  8 13:06:10 1996
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Tue, 8 Oct 1996 14:06:10 +0200
Subject: [PYTHON MATRIX-SIG] Creating grid object
Message-ID: <9610081206.AA04295@flores.ifm.uni-kiel.de>

Hello, I want to use Numpy (is this name "official"?) to build an
analysis package for a numerical model. At the moment I implement some
simple functions, which are working on array-arguments. Now I get the
idea, that it would nice to have an array-object of a variable say
salinity, with an attribut about the edges of the grid the variable is
defined on, so that I can work on arbitray blocks and can get the
information where this block is later.

I want to define the hole grid as a global variable and let the edges
in the new object point at a subregion of the grid. I'm new to python
and object-oriented programming, but I think that I must define my own
class. My problem now is, that I want to do normal math directly with
this object, like

    sal_anomaly_on_grid = sal_on_grid - mean_sal_in_depth_on_this_grid

	 ^new object        ^new object     ^normal 1d array

At the moment I know only to do something like

    sal_anomaly_on_grid = sal_on_grid.data - mean_sal_in_depth_on_this_grid

	^normal array       ^new object        ^normal array

My grid is defined in two 2d-arrays x_loc,y_loc and one 3d-array  z with
depth of x,y in n layers. My first idea is to have an attribut in the new
object, wich is a list of 16 points

	x_loc(index_of_x_starting_location)
	x_loc(index_of_y_starting_location)
	x_loc(index_of_x_stop_location)
	x_loc(index_of_y_stop_location)
	4 y_loc(...)
	8 z

But it would be better, to have references to each gridpoint, to allow
more flexibel grids, but this is perhaps memory-consuming. Is it
possible to build something like this?  Is the definition of such
classes covered in one of the new python-books? Or must I program
something in C (I hope not).

Last but not least, is this group the right place to ask? I think I
will have more questions in the future.

TIA

	Janko Hauser


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From managan@llnl.gov  Wed Oct  9 09:32:39 1996
From: managan@llnl.gov (Rob Managan)
Date: Wed, 9 Oct 1996 09:32:39 +0100
Subject: [PYTHON MATRIX-SIG] plplot module
Message-ID: <v03007803ae8111b6f3a1@[128.115.186.111]>

Tom,

I downloaded your plmodule and trimodule to look at. In particular I was
interested in the plotting interface.

The plmodule on your ftp server works with python lists. Has anyone written
a version of it that works with array arguments from NumPy? The tutorial
for your triangulation code sounded like it worked with NumPy arrays so I
thought you might have a version for arrays.

Anyone else written such a module?

PS. I have the list oriented version working on my Mac, a 7600 and can send
it to anyone interested. I hope to clean up the project files and send them
off to the plplot archive.

*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
Rob Managan       mailto://managan@llnl.gov
LLNL                      ph:  510-423-0903
P.O. Box 808, L-178       FAX: 510-423-5804
Livermore, CA  94551-0808




=================
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 Oct 10 20:57:43 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Thu, 10 Oct 1996 15:57:43 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Creating grid object
In-Reply-To: <9610081206.AA04295@flores.ifm.uni-kiel.de> from "janko hauser" at Oct 8, 96 02:06:10 pm
Message-ID: <199610101957.PAA21232@maigret>

> Hello, I want to use Numpy (is this name "official"?) to build an
> analysis package for a numerical model. At the moment I implement some
> simple functions, which are working on array-arguments. Now I get the
> idea, that it would nice to have an array-object of a variable say
> salinity, with an attribut about the edges of the grid the variable is
> defined on, so that I can work on arbitray blocks and can get the
> information where this block is later.

I didn't see any response to this message, so I'll give it a shot.

I'm not sure I entirely understand your requirements, but here's what I
think I read in your message. 

     You want to define a new object type (call it a class) which 
     has some of the attributes of a python multiarray, and some
     attributes which are specific to your application (salinity, etc.).

This I would do by subclassing the UserArray class which is part of the
Lib directory of NumPy.  It is basically a class wrapper around the
builtin python type.

> I want to define the hole grid as a global variable and let the edges
> in the new object point at a subregion of the grid. I'm new to python
> and object-oriented programming, but I think that I must define my own
> class. My problem now is, that I want to do normal math directly with
> this object, like
> 
>     sal_anomaly_on_grid = sal_on_grid - mean_sal_in_depth_on_this_grid
> 
> 	 ^new object        ^new object     ^normal 1d array
> 
> At the moment I know only to do something like
> 
>     sal_anomaly_on_grid = sal_on_grid.data - mean_sal_in_depth_on_this_grid
> 
> 	^normal array       ^new object        ^normal array
> 
> My grid is defined in two 2d-arrays x_loc,y_loc and one 3d-array  z with
> depth of x,y in n layers. My first idea is to have an attribut in the new
> object, wich is a list of 16 points
> 
> 	x_loc(index_of_x_starting_location)
> 	x_loc(index_of_y_starting_location)
> 	x_loc(index_of_x_stop_location)
> 	x_loc(index_of_y_stop_location)
> 	4 y_loc(...)
> 	8 z
> 
> But it would be better, to have references to each gridpoint, to allow
> more flexibel grids, but this is perhaps memory-consuming. 

Ah, I think I understand better now.  You want to have a big array which
stores all your data, and then have other objects which are in some ways
like 'enhanced slices'.  In other words, they point to a subset of the
big array, but they are not just slices because they have other
properties.  In other words, you want a UserSlice object, I think.  That
doesn't exist to my knowledge, but it certainly seems a worthy project.
Am I paraphrasing your needs correctly?  I suspect that the key to doing
this is understanding UserArray.py and slice() well.  Remember that the
slice() operator returns an 'array by reference':

	>>> a = arange(10)
	>>> a
	0 1 2 3 4 5 6 7 8 9
	>>> b = a[3:5]
	>>> b
	3 4 
	>>> a[3] = 0
	>>> a 
	0 1 2 0 4 5 6 7 8 9
	>>> b
	0 4

[Jim: is UserArray up to date?]

> Is it
> possible to build something like this?  Is the definition of such
> classes covered in one of the new python-books? Or must I program
> something in C (I hope not).

I suspect that Mark and Aaron's books cover class creation, maybe
'class-around-type' creation, but probably not the specific numeric
array object.  I don't think you need to do any C for this.

> Last but not least, is this group the right place to ask? I think I
> will have more questions in the future.

Yes.

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jay@elec.gla.ac.uk  Fri Oct 11 12:33:49 1996
From: jay@elec.gla.ac.uk (Jeppe Sigbrandt)
Date: Fri, 11 Oct 1996 12:33:49 +0100
Subject: [PYTHON MATRIX-SIG] graphics
Message-ID: <10136.199610111133@eeapp.gla.ac.uk>

Hiya,

Am following Numerical Python development, but am not yet a user.
(i.e. have not yet found time to discover how to compile/install it)

Just curious about the plans to include graphics abilities into python,
and decided to ask here, since NumPy would seriously benefit from this.

Matlabs graphics abilities are about the best I've come across.
Octave is interfaced with GnuPlot, and though gnuplot is GPL, its no
panacea (I find it hard to control, and lacking in features)  
Rlab reputedly uses something better than gnuplot, but I've
never tried or even seen it.  Must admit that it was the www pages on
LispStat (recently mentioned in the newsgroup) that prompted me to 
finally send a message:
http://galen.med.virginia.edu/~sdm7g/XES/Docs/xesapp.html
Nice graphics :)

There must be some code in the public domain that can be quickly added
onto python for plotting.  

Are there any plans or new developments ?

Regards,
jay

=================
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 Oct 11 21:45:30 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 11 Oct 1996 16:45:30 -0400
Subject: [PYTHON MATRIX-SIG] graphics
Message-ID: <9610112042.AA26979@goldilocks.LCS.MIT.EDU>

> Just curious about the plans to include graphics abilities into python,
> and decided to ask here, since NumPy would seriously benefit from this.

I've personally done very little along these lines (my own work uses the
much too general purpose OpenGL).  Folks at LLNL have developed interfaces
to both Narcisse and GIST which seem like very nice graphics packages.  I'm
not sure if these work with NumPy1.0, or only 0.36.

There's also been work on a plplotmodule, but its been abandonded.

-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@anchor.cs.colorado.edu  Sun Oct 13 23:57:26 1996
From: carlosm@anchor.cs.colorado.edu (Carlos Maltzahn)
Date: Sun, 13 Oct 1996 16:57:26 -0600 (MDT)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
Message-ID: <199610132257.QAA12561@anchor.cs.colorado.edu>

When I import ni I get the following error. I use Python 1.4b3 with 
NumPy-1.0a4. Any ideas?

Thanks,
Carlos

-----------
Python 1.4b3 (Oct 13 1996) [C]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> import ni
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/home/big/carlosm/numpython/Lib/ni.py", line 435, in ?
    install()
  File "/home/big/carlosm/numpython/Lib/ni.py", line 399, in install
    ihooks.install(PackageImporter(None, v))
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 360, in install
    current_importer.install()
  File "/home/big/carlosm/numpython/Lib/ni.py", line 390, in install
    self.loader.init_package(package)
  File "/home/big/carlosm/numpython/Lib/ni.py", line 239, in init_package
    self.call_init_module(package)
  File "/home/big/carlosm/numpython/Lib/ni.py", line 261, in call_init_module
    m = self.load_module(package.__name__ + '.__init__', stuff)
  File "/home/big/carlosm/numpython/Lib/ni.py", line 204, in load_module
    return ModuleLoader.load_module(self, name, stuff)
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 259, in load_module
    return self.hooks.load_source(name, filename, file)
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 170, in load_source
    return imp.load_source(name, filename, file)
  File "/home/big/carlosm/numpython/Lib/Numeric/__init__.py", line 1, in ?
    import Core
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 320, in import_module
    return self.loader.load_module(name, stuff)
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 259, in load_module
    return self.hooks.load_source(name, filename, file)
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 170, in load_source
    return imp.load_source(name, filename, file)
  File "/home/big/carlosm/numpython/Lib/Numeric/Core.py", line 107, in ?
    from ArrayPrinter import arrayToString
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 320, in import_module
    return self.loader.load_module(name, stuff)
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 259, in load_module
    return self.hooks.load_source(name, filename, file)
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 170, in load_source
    return imp.load_source(name, filename, file)
  File "/home/big/carlosm/numpython/Lib/Numeric/ArrayPrinter.py", line 9, in ?
    import Numeric
  File "/home/big/carlosm/numpython/Lib/ihooks.py", line 319, in import_module
    raise ImportError, "No module named %s" % name
ImportError: No module named Numeric
>>> 


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Mon Oct 14 00:31:30 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Sun, 13 Oct 1996 19:31:30 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
In-Reply-To: <199610132257.QAA12561@anchor.cs.colorado.edu> from "Carlos Maltzahn" at Oct 13, 96 04:57:26 pm
Message-ID: <199610132331.TAA25460@maigret>

> When I import ni I get the following error. I use Python 1.4b3 with 
> NumPy-1.0a4. Any ideas?

Yes, I was having exactly the same problem.  I can't remember which of
the two of the following fixes the problem:

1) in ArrayPrinter.py, change
	import Numeric
to:
	import ni, Numeric

2) add an empty file called __init__.py in /usr/local/lib/python1.4/

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From Carlos Fonseca <fonseca@gaivota.demon.co.uk>  Mon Oct 14 00:22:10 1996
From: Carlos Fonseca <fonseca@gaivota.demon.co.uk> (Carlos Fonseca)
Date: Mon, 14 Oct 1996 00:22:10 +0100 (BST)
Subject: [PYTHON MATRIX-SIG] compile problems
In-Reply-To: <9610031708.AA07823@goldilocks.LCS.MIT.EDU>
Message-ID: <Pine.LNX.3.95.961013234417.54A-100000@gaivota.demon.co.uk>

On Thu, 3 Oct 1996, Jim Hugunin wrote:

> I have had no problem building Python1.4 on my alpha/osf machine using gcc.
>  I'd reccommend going that route for now until the official release of 1.4
> (which knowing Guido will compilke out of the box just about everywhere).
> 
> -Jim
> 

Hello again (at last!),

I had the following problem when compiling Python1.4beta3 on Linux ELF:
If mathmodule.c is dynamically linked, then

import ni
import math

does not import math properly. However, it works correctly if mathmodule.c
is statically linked with the python executable (all other modules
dynamic). This seems to be a bug in Python1.4beta3 itself.

The good news: I was able to (dynamically) link lapack_litemodule against
a full, shared liblapack (compiled with g77, again under Linux. Got
patches for the lapack makefiles from sunsite). Linking the module
required -lgcc in addition to -llapack and -lblas, but it seems to work
now.

Finally, shouldn't the function "determinate()" be "determinant()"?  This
would be easy enough to fix.

Carlos



=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From carlosm@anchor.cs.colorado.edu  Mon Oct 14 00:39:05 1996
From: carlosm@anchor.cs.colorado.edu (Carlos Maltzahn)
Date: Sun, 13 Oct 1996 17:39:05 -0600 (MDT)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
In-Reply-To: <199610132331.TAA25460@maigret> from "David Ascher" at Oct 13, 96 07:31:30 pm
Message-ID: <199610132339.RAA12704@anchor.cs.colorado.edu>

> 
> > When I import ni I get the following error. I use Python 1.4b3 with 
> > NumPy-1.0a4. Any ideas?
> 
> Yes, I was having exactly the same problem.  I can't remember which of
> the two of the following fixes the problem:
> 
> 1) in ArrayPrinter.py, change
> 	import Numeric
> to:
> 	import ni, Numeric
> 
> 2) add an empty file called __init__.py in /usr/local/lib/python1.4/
> 
> --david

The second! Thanks a bunch!

Carlos

=================
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 Oct 14 00:49:41 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Sun, 13 Oct 1996 19:49:41 -0400
Subject: [PYTHON MATRIX-SIG] Ellipses -> Ellipsis
Message-ID: <199610132349.TAA22852@monty>

As Ka-Ping Yee mentioned, "Ellipses" should have been "Ellipsis".

I'm making this change for the final 1.4 release (scheduled for Oct 25).
I plan to leave two backward compatibility measures in: Python code can
still use "Ellipses" as well as "Ellipsis", and C code can still use
Py_Ellipses (or whatever it was).

However, such backward compatibility measures tend to stop people from
actually fixing their code.  How much would the NumPy community be
inconvenienced if I simply removed all references to Ellipses?

--Guido van Rossum (home page: http://www.python.org/~guido/)

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Mon Oct 14 03:47:54 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Sun, 13 Oct 1996 22:47:54 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] autocorrelation functions?
Message-ID: <199610140247.WAA25699@maigret>

What's a smart (read efficient, and possibly neat) way of doing
autocorrelation in NumPython?  I'm looking for both 1D and 2D with
a city-block metric to start with (a cartesian metric would be good
too, but I suspect that's harder to optimize).

I'm sure there's a good way to do this, I just can't figure it out...

Let me make it more explicit.  I want to compute the average product of
pairs of elements for each distance in "indices" between the two
elements.  So I want the average product of x[i] and x[i+1], the average
product of x[i] and x[i+2], etc.  

--david

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Mon Oct 14 10:01:46 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 14 Oct 96 10:01:46 +0100
Subject: [PYTHON MATRIX-SIG] Ellipses -> Ellipsis
In-Reply-To: <199610132349.TAA22852@monty> (message from Guido van Rossum on
 Sun, 13 Oct 1996 19:49:41 -0400)
Message-ID: <199610140908.KAA13284@ibs.ibs.fr>

> However, such backward compatibility measures tend to stop people from
> actually fixing their code.  How much would the NumPy community be
> inconvenienced if I simply removed all references to Ellipses?

We are still in alpha stage and therefore used to incompatible changes ;-)
Better clean it up now than have generations of Python programmers
wonder about the two different spellings!

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Mon Oct 14 10:00:34 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 14 Oct 96 10:00:34 +0100
Subject: [PYTHON MATRIX-SIG] autocorrelation functions?
In-Reply-To: <199610140247.WAA25699@maigret> (da@maigret.cog.brown.edu)
Message-ID: <199610140906.KAA13269@ibs.ibs.fr>

> What's a smart (read efficient, and possibly neat) way of doing
> autocorrelation in NumPython?  I'm looking for both 1D and 2D with

The standard procedure using FFTs should be efficient in NumPython
(although of course I didn't try it). Both the FFTs and the
multiplication are handled in C code.

> a city-block metric to start with (a cartesian metric would be good
> too, but I suspect that's harder to optimize).

Sorry, I don't know what all that means :-(

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From Rob.Hooft@embl-heidelberg.de  Mon Oct 14 09:48:29 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Mon, 14 Oct 1996 10:48:29 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] autocorrelation functions?
In-Reply-To: <199610140247.WAA25699@maigret>
References: <199610140247.WAA25699@maigret>
Message-ID: <199610140848.KAA20538@nu>

>>>>> "DA" == David Ascher <da@maigret.cog.brown.edu> writes:

 DA> What's a smart (read efficient, and possibly neat) way of doing
 DA> autocorrelation in NumPython?  I'm looking for both 1D and 2D
 DA> with a city-block metric to start with (a cartesian metric would
 DA> be good too, but I suspect that's harder to optimize).

 DA> I'm sure there's a good way to do this, I just can't figure it
 DA> out...

Isn't the O(n^2) operation of autocorrelation mathematically
equivalent to the O(n ln n) auto-convolution operation?

    ac(x)=inverse_fft(fft(x)^2)

Rob
-- 
=== Rob.Hooft@EMBL-Heidelberg.DE   http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling?  http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures?  http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux!  Free Software Rules The World! =============

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From Rob.Hooft@embl-heidelberg.de  Mon Oct 14 09:51:00 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Mon, 14 Oct 1996 10:51:00 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
In-Reply-To: <199610132339.RAA12704@anchor.cs.colorado.edu>
References: <199610132331.TAA25460@maigret>
 <199610132339.RAA12704@anchor.cs.colorado.edu>
Message-ID: <199610140851.KAA26266@nu>

>>>>> "CM" == Carlos Maltzahn <carlosm@anchor.cs.colorado.edu> writes:

 CM>  When I import ni I get the following error. I use Python 1.4b3
 CM>  with NumPy-1.0a4. Any ideas?

 DA> Yes, I was having exactly the same problem.  I can't remember
 DA> which of the two of the following fixes the problem:
     [...]
 DA> 2) add an empty file called __init__.py in
 DA> /usr/local/lib/python1.4/

 CM> The second!

Are you both sure you are not using a "python" with $PYTHONLIB/Numeric
in the PYTHONPATH or sys.path? I can imagine that could cause an error
like this.

Rob.
-- 
=== Rob.Hooft@EMBL-Heidelberg.DE   http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling?  http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures?  http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux!  Free Software Rules The World! =============

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Mon Oct 14 11:55:28 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 14 Oct 96 11:55:28 +0100
Subject: [PYTHON MATRIX-SIG] autocorrelation functions?
In-Reply-To: <199610140848.KAA20538@nu> (Rob.Hooft@embl-heidelberg.de)
Message-ID: <199610141101.MAA13942@ibs.ibs.fr>

> Isn't the O(n^2) operation of autocorrelation mathematically
> equivalent to the O(n ln n) auto-convolution operation?
> 
>     ac(x)=inverse_fft(fft(x)^2)

Almost. The difference between convolution and correlation is
a conjugation: 
  xfft = fft(x)
  inverse_fft(xfft*conjugate(xfft))
(untested, as always).

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Mon Oct 14 15:15:47 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Mon, 14 Oct 1996 10:15:47 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] autocorrelation functions?
In-Reply-To: <199610141101.MAA13942@ibs.ibs.fr> from "Konrad Hinsen" at Oct 14, 96 11:55:28 am
Message-ID: <199610141415.KAA26163@maigret>

> > Isn't the O(n^2) operation of autocorrelation mathematically
> > equivalent to the O(n ln n) auto-convolution operation?
> > 
> >     ac(x)=inverse_fft(fft(x)^2)
> 
> Almost. The difference between convolution and correlation is
> a conjugation: 
>   xfft = fft(x)
>   inverse_fft(xfft*conjugate(xfft))
> (untested, as always).

Great, this is perfect.  Two more questions

1) I can do 2d fft's and 2d inverse fft's -- what kind of
   autocorrelation metric would that use (meaning if autocorrelation is
   the function relating distance between elements and their
   correlation, what distance metric does it use)?

2) I'd really appreciate a reference on these sorts of tidbits --
   computational algorithms which cross standard boundary distinctions.
   Can anyone recommend such a book?

Thanks.

--david

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Mon Oct 14 16:37:26 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 14 Oct 96 16:37:26 +0100
Subject: [PYTHON MATRIX-SIG] autocorrelation functions?
In-Reply-To: <199610141415.KAA26163@maigret> (da@maigret.cog.brown.edu)
Message-ID: <199610141543.QAA15566@ibs.ibs.fr>

> 1) I can do 2d fft's and 2d inverse fft's -- what kind of
>    autocorrelation metric would that use (meaning if autocorrelation is
>    the function relating distance between elements and their
>    correlation, what distance metric does it use)?

If you apply everything to 2d arrays, you end up with a 2d answer,
meaning a correlation function of two variables, i.e. a distance
*vector*. I suspect that you can get your total correlation by
averaging over all array elements corresponding to a fixed
"distance", whatever its definitions. For cartesian distance
that would mean averaging over "circles" (with the problem that
there will be very few points with exactly the same cartesian
distance), and for city-block distance averaging over pairs
of diagonal-parallels.

But I strongly recommend checking this before believing it!
I spent less than a minute thinking about it ;-)

> 2) I'd really appreciate a reference on these sorts of tidbits --
>    computational algorithms which cross standard boundary distinctions.
>    Can anyone recommend such a book?

Numerical Recipes did a good start, treating FFT together with
"ordinary" numerical algorithms (and it does say something about
convolutions and correlations). In general, the walls between
subfields seem to be too high to permit useful books like this.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
41, 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 carlosm@anchor.cs.colorado.edu  Mon Oct 14 18:41:01 1996
From: carlosm@anchor.cs.colorado.edu (Carlos Maltzahn)
Date: Mon, 14 Oct 1996 11:41:01 -0600 (MDT)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
In-Reply-To: <199610140851.KAA26266@nu> from "Rob.Hooft@EMBL-Heidelberg.de" at Oct 14, 96 10:51:00 am
Message-ID: <199610141741.LAA18386@anchor.cs.colorado.edu>

> 
> >>>>> "CM" == Carlos Maltzahn <carlosm@anchor.cs.colorado.edu> writes:
> 
>  CM>  When I import ni I get the following error. I use Python 1.4b3
>  CM>  with NumPy-1.0a4. Any ideas?
> 
>  DA> Yes, I was having exactly the same problem.  I can't remember
>  DA> which of the two of the following fixes the problem:
>      [...]
>  DA> 2) add an empty file called __init__.py in
>  DA> /usr/local/lib/python1.4/
> 
>  CM> The second!
> 
> Are you both sure you are not using a "python" with $PYTHONLIB/Numeric
> in the PYTHONPATH or sys.path? I can imagine that could cause an error
> like this.
> 
> Rob.
> -- 
> === Rob.Hooft@EMBL-Heidelberg.DE   http://www.Sander.EMBL-Heidelberg.DE/rob/ ==

You are right! So why is that?

Carlos

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From Rob.Hooft@embl-heidelberg.de  Mon Oct 14 18:52:19 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Mon, 14 Oct 1996 19:52:19 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
In-Reply-To: <199610141741.LAA18386@anchor.cs.colorado.edu>
References: <199610140851.KAA26266@nu>
 <199610141741.LAA18386@anchor.cs.colorado.edu>
Message-ID: <199610141752.TAA32149@nu>

>>>>> "CM" == Carlos Maltzahn <carlosm@anchor.cs.colorado.edu> writes:

 >>  Are you both sure you are not using a "python" with
 >> $PYTHONLIB/Numeric in the PYTHONPATH or sys.path? I can imagine
 >> that could cause an error like this.

 CM> You are right! So why is that?

Because in that case the "import Numeric" will find
"$PYTHONLIB/Numeric/Numeric.py" instead of using "ni" to import the
package.

Regards,

Rob.
-- 
=== Rob.Hooft@EMBL-Heidelberg.DE   http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling?  http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures?  http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux!  Free Software Rules The World! =============

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From carlosm@anchor.cs.colorado.edu  Mon Oct 14 21:31:00 1996
From: carlosm@anchor.cs.colorado.edu (Carlos Maltzahn)
Date: Mon, 14 Oct 1996 14:31:00 -0600 (MDT)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
In-Reply-To: <199610141752.TAA32149@nu> from "Rob.Hooft@EMBL-Heidelberg.de" at Oct 14, 96 07:52:19 pm
Message-ID: <199610142031.OAA21210@anchor.cs.colorado.edu>

> 
> >>>>> "CM" == Carlos Maltzahn <carlosm@anchor.cs.colorado.edu> writes:
> 
>  >>  Are you both sure you are not using a "python" with
>  >> $PYTHONLIB/Numeric in the PYTHONPATH or sys.path? I can imagine
>  >> that could cause an error like this.
> 
>  CM> You are right! So why is that?
> 
> Because in that case the "import Numeric" will find
> "$PYTHONLIB/Numeric/Numeric.py" instead of using "ni" to import the
> package.
> 
> Regards,
> 
> Rob.

... I guess that means "go and read the source code yourself", right?
I should have done that in the first place. Never mind.

Carlos

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From Rob.Hooft@embl-heidelberg.de  Tue Oct 15 09:45:08 1996
From: Rob.Hooft@embl-heidelberg.de (Rob.Hooft@embl-heidelberg.de)
Date: Tue, 15 Oct 1996 10:45:08 +0200 (MET DST)
Subject: [PYTHON MATRIX-SIG] missing Numeric.py?
In-Reply-To: <199610142031.OAA21210@anchor.cs.colorado.edu>
References: <199610141752.TAA32149@nu>
 <199610142031.OAA21210@anchor.cs.colorado.edu>
Message-ID: <199610150845.KAA00656@nu>

>>>>> "CM" == Carlos Maltzahn <carlosm@anchor.cs.colorado.edu> writes:

 >>  Because in that case the "import Numeric" will find
 >> "$PYTHONLIB/Numeric/Numeric.py" instead of using "ni" to import
 >> the package.

 CM> ... I guess that means "go and read the source code yourself",
 CM> right? I should have done that in the first place. Never mind.

It doesn't mean that. If it came across like that: I'm sorry. My
diagnosis was based on an absolute minimal knowledge of the "ni"
system, and a large number of guesses, so I just don't know any more
than I stated.....

Rob.
-- 
=== Rob.Hooft@EMBL-Heidelberg.DE   http://www.Sander.EMBL-Heidelberg.DE/rob/ ==
==== In need of protein modeling?  http://www.Sander.EMBL-Heidelberg.DE/whatif/
Validation of protein structures?  http://biotech.EMBL-Heidelberg.DE:8400/ ====
== PGPid 0xFA19277D == Use Linux!  Free Software Rules The World! =============

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Tue Oct 15 19:22:30 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 15 Oct 1996 14:22:30 -0400
Subject: [PYTHON MATRIX-SIG] Ellipses -> Ellipsis
Message-ID: <9610151820.AA08159@goldilocks.LCS.MIT.EDU>

> As Ka-Ping Yee mentioned, "Ellipses" should have been "Ellipsis".
> 
> I'm making this change for the final 1.4 release (scheduled for Oct 25).
> I plan to leave two backward compatibility measures in: Python code can
> still use "Ellipses" as well as "Ellipsis", and C code can still use
> Py_Ellipses (or whatever it was).
> 
> However, such backward compatibility measures tend to stop people from
> actually fixing their code.  How much would the NumPy community be
> inconvenienced if I simply removed all references to Ellipses?

I'd personally strongly prefer it if you did NOT maintain backward
compatibility.  I've been warning people on the SIG all along that
successive versions of NumPy are not in any way guaranteed to be backward
compatible until I announce a beta1 release (which will be after the final
release of Python1.4).

So, I'd say get it right now before Ellipses becomes part of a "final"
release and you become obligated to support it forever.  Besides, I expect
that there are very few NumPy users other than myself who actually use
"Ellipses" in their code (as opposed to "...").

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Tue Oct 15 21:26:45 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Tue, 15 Oct 1996 15:26:45 -0500
Subject: [PYTHON MATRIX-SIG] Bug in LinearAlgebra
Message-ID: <199610152022.QAA05303@python.org>


I just found the following bug - appologies if it's allready been
reported and I missed it.

Determinant doestn't work correctly in LinearAlgebra. I think this may
be indicative of a problem in singular value decomposition, but I'm
not sure 'cause my memory of SVDs is fuzzy at best. Here's a case that
doesn't work:

a = Numeric.array([[-1,0,0],[0,1,0],[0,0,1]])
print a
print
print Numeric.LinearAlgebra.determinate(a)
print
================
-1  0  0
 0  1  0
 0  0  1

1.0

Investigating this further I noted that the eigenvalues were computed
as the product of the diagonal term (s) of the SVD. That seems fine,
since I believe s should be composed of the matrices
eigenvalues. However, when I checked out the value of s for this
simple case I got a suprise:

u, s, vt = Numeric.LinearAlgebra.singular_value_decomposition(a)
print u
print
print s
print
print vt
================
 1.  0.  0.
 0.  1.  0.
 0.  0.  1.

 1.  1.  1.    # These are not the eigenvalues, where is -1.

-1.  0.  0.
 0.  1.  0.
 0.  0.  1.


So either a) my memory of how SVD works AND the way determinant is
implemented is wrong, or b) svd is messed up somehow. Someone who
remembers their linear algebra wanna' help me out here?


-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+






=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jac@gandalf.llnl.gov  Tue Oct 15 22:08:56 1996
From: jac@gandalf.llnl.gov (James Crotinger)
Date: Tue, 15 Oct 96 14:08:56 PDT
Subject: [PYTHON MATRIX-SIG] Bug in LinearAlgebra
In-Reply-To: <199610152022.QAA05303@python.org>
References: <199610152022.QAA05303@python.org>
Message-ID: <9610152108.AA29143@gandalf.llnl.gov>

tim@lassi.ece.uiuc.edu writes:
 > ================
 >  1.  0.  0.
 >  0.  1.  0.
 >  0.  0.  1.
 > 
 >  1.  1.  1.    # These are not the eigenvalues, where is -1.

Singular values are, by definition, positive. The nonzero singular
values are the positive square root of the eigenvalues of A' * A
(where ' denotes transpose).

But the determinant is indeed wrong. 

  Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Tue Oct 15 22:33:10 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Tue, 15 Oct 1996 16:33:10 -0500
Subject: [PYTHON MATRIX-SIG] Bug in LinearAlgebra
In-Reply-To: <9610152108.AA29143@gandalf.llnl.gov> (message from James
 Crotinger on Tue, 15 Oct 96 14:08:56 PDT)
Message-ID: <199610152128.RAA05471@python.org>


James Crotinger <jac@gandalf.llnl.gov> writes:
>
>tim@lassi.ece.uiuc.edu writes:
> > ================
> >  1.  0.  0.
> >  0.  1.  0.
> >  0.  0.  1.
> > 
> >  1.  1.  1.    # These are not the eigenvalues, where is -1.
>
>Singular values are, by definition, positive. The nonzero singular
>values are the positive square root of the eigenvalues of A' * A
>(where ' denotes transpose).

Ooops! OK, then LinearAlgebra.determinant is indeed wrong. Well I
'fixed' it by using LinearAlgebra.eigenvalues instead, only to uncover
a problem with multiply.reduce. Check this out:

c = Numeric.array([1.-1j, 1+1j,1])
print c
print
print c[0]*c[1]*c[2]
print
print Numeric.product(c)
print
print Numeric.multiply.reduce(c)
================
 (1.-1.j)  (1.+1.j)  (1.+0.j)

(2+0j)

(2+1j)

(2+1j)

This is not right!


Here's the fixed (but not really tested) version of determinant:

def determinate(a):
    _assertRank2(a)
    _assertSquareness(a)
    ev = eigenvalues(a)
    return Numeric.product(ev)


-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Tue Oct 15 23:30:53 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 15 Oct 1996 18:30:53 -0400
Subject: [PYTHON MATRIX-SIG] Bug in LinearAlgebra
Message-ID: <9610152228.AA11468@goldilocks.LCS.MIT.EDU>

> only to uncover
> a problem with multiply.reduce. Check this out:
...

This is a really terrible bug.  It only shows up when doing multiply (or
divide) as a reduction on an array of complex numbers, but still this is
ugly.  The problem lies in the low-level C functions in fast_umath and
umath modules.  You should replace the following two functions with the
forms given below to fix it (in fast_umathmodule.c and umathmodule.c). 
This one's bad enough I thought I'd post a patch right away.

A gold star to anyone who can explain what stupid mistake I made when
writing these functions the first time.

static void CFLOAT_multiply(char **args, int *dimensions, int *steps, void
*func) {
  int i, is1=steps[0],is2=steps[1],os=steps[2], n=dimensions[0];
  char *i1=args[0], *i2=args[1], *op=args[2];
  float tmp;
  for(i=0; i<n; i++, i1+=is1, i2+=is2, op+=os) {
    tmp=((float *)i1)[0] * ((float *)i2)[0] - ((float *)i1)[1] * ((float
*)i2)[1]; ((float *)op)[1]=((float *)i1)[1] * ((float *)i2)[0] + ((float
*)i1)[0] * ((float *)i2)[1];
	((float *)op)[0]=tmp;
  }
}

static void CDOUBLE_multiply(char **args, int *dimensions, int *steps, void
*func) {
  int i, is1=steps[0],is2=steps[1],os=steps[2], n=dimensions[0];
  char *i1=args[0], *i2=args[1], *op=args[2];
  double tmp;
  for(i=0; i<n; i++, i1+=is1, i2+=is2, op+=os) {
    tmp=((double *)i1)[0] * ((double *)i2)[0] - ((double *)i1)[1] *
((double *)i2)[1]; ((double *)op)[1]=((double *)i1)[1] * ((double *)i2)[0]
+ ((double *)i1)[0] * ((double *)i2)[1];
	((double *)op)[0]=tmp;
  }
}


> Here's the fixed (but not really tested) version of determinant:
> 
> def determinate(a):
>     _assertRank2(a)
>     _assertSquareness(a)
>     ev = eigenvalues(a)
>     return Numeric.product(ev)

If somebody more LA familiar than myself can confirm and test this I'll
make the change in the standard distribution.

-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  Wed Oct 16 04:21:27 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 15 Oct 1996 23:21:27 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] autocorrelation functions? (fwd)
Message-ID: <199610160321.XAA29568@maigret>

[I wrote:]
> 
> 2) I'd really appreciate a reference on these sorts of tidbits --
>    computational algorithms which cross standard boundary distinctions.
>    Can anyone recommend such a book?

As a follow-up, I've been reminded to check out Numerical Recipes (duh)
and also I've been learning a lot from Golub & Ortega's ``Scientific
Computing and Differential Equations -- An Introduction to Numerical
Methods.''  

Just thought that others in the 'lurker' community might be curious.

--david

PS: Say, Matrix-sig coordinator, how many subscribers are there to this
    illustrious list?


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From nigel@maths.su.oz.au  Wed Oct 16 05:26:29 1996
From: nigel@maths.su.oz.au (Nigel O'Brian)
Date: Wed, 16 Oct 1996 14:26:29 +1000 (EST)
Subject: [PYTHON MATRIX-SIG] Calling NumPy from C
Message-ID: <199610160426.OAA22014@milan.maths.su.oz.au>


Sorry if this is a bit long -- it is more a suggestion than a request.

In NumPy1.0a4 the routine 
------------------------------------------------------------------------
  array_from_existing_data
    = PyArray_FromDimsAndData(n_dims, dims[n_dims], item_type, old_data);
------------------------------------------------------------------------
is declared in arraymodule.h but, *not recommended*. But it seems to me that
this ought to be a useful feature of the C API.

Checking through the archive, I see this matter was raised about
a year ago by Paul Dubois, but apparently dismissed --  e.g.
------------------------------------------------------------------------
From: hinsenk@ere.umontreal.ca (Hinsen Konrad)
Subject: Re: [PYTHON MATRIX-SIG] A related idea

KH: As for C, the best way would be to leave allocation completely to
KH: Python. The matrix module would provide functions to allocate and free
KH: matrices that can be called from the C code just like malloc() and
KH: free(). These functions would take care of the reference from the C
KH: code.
KH: 
KH: Of course the C code is also free to handle its own matrices and
KH: manage them completely (e.g. workspace in library functions). These
KH: would never be accessed from Python; in fact, Python wouldn't even
KH: know about their existence.
------------------------------------------------------------------------
But suppose I have a canned optimization routine in C, which is
finding the minimum of an `objective function' F of N real variables.

This routine expects to be given an array of N doubles, containing the
initial guess as input and in which it leaves the minimizing solution
as output.  The routine also gets passed the calling address of the
objective function F.

Inside the routine, the objective function F gets called with an argument
specifying a (possibly different) array of N doubles on which F is to
be evaluated. This array may be workspace allocated by the optimization
routine itself, unknown to Python.

Suppose one wants a Python interface to the optimization routine,
which can set parameters and allocate an array for input and output.
This is easy enough, but a difficulty arises if one wants to define
the objective function in Python, so the C/Python interface needs a
*callback* to the Python interpreter (using PyEval_CallObject, I
guess). Then F would be a C wrapper for this callback.

But suppose the optimization routine just gives F a pointer to a block
of data allocated by the routine itself. For this to make any sense to
the Numerical Python routines it needs to be `wrapped' inside an array
object and `FromDimsAndData' is the obvious way to do this.

The problem then arises (and this seems to be the source of the
warning) of how to delete the Python array structure without also
freeing the enclosed data (to the surprise of the optimization routine
which allocated it).

This seems to be a general problem which arises when one wants
to fully wrap numerical routines which have functions as parameters -
optimization routines, differential equation integrators, etc.

Question: Is it possible to place a flag in the PyArray structure to
indicate the ownership of the enclosed data? If the array is created
from pre-existing data it would then be possible for Python, or the
C API, to delete the enclosing structure without freeing the data.

I can easily work around this problem by just copying the data into an
existing Python array on each function call, which is probably not a
serious performance overhead. Just less elegant.

Possibly Related Question: If B is a subarray of A, created by e.g. B
= A[3:6].  How does B get deleted without attempting to free the data
it shares with A?

Or is there a better way to look at this whole thing?
--------------------------------------------------------------------
Nigel O'Brian                             obrian_n@maths.usyd.edu.au
School of Mathematics                     Ph: (02)-9351-4083
University of Sydney                      FAX: (02)-9351-4534                
Sydney NSW 2006, Australia

=================
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 Oct 16 12:08:55 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 16 Oct 96 12:08:55 +0100
Subject: [PYTHON MATRIX-SIG] Bug in LinearAlgebra
In-Reply-To: <9610152228.AA11468@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610161115.MAA05689@ibs.ibs.fr>

> > Here's the fixed (but not really tested) version of determinant:
> > 
> > def determinate(a):
> >     _assertRank2(a)
> >     _assertSquareness(a)
> >     ev = eigenvalues(a)
> >     return Numeric.product(ev)
> 
> If somebody more LA familiar than myself can confirm and test this I'll
> make the change in the standard distribution.

That is indeed a correct way to calculate the determinant, although
not the most efficient one (LU decomposition is faster). If I find the
time I'll do something better, but this one is of course much
preferable to the current (wrong) function. But please also correct
the name to "determinant"!

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Wed Oct 16 14:50:02 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 16 Oct 96 14:50:02 +0100
Subject: [PYTHON MATRIX-SIG] Slice expressions
Message-ID: <199610161356.OAA07227@ibs.ibs.fr>

What happened to the slice generator that was in Numeric in earlier
versions? It seems to have disappeared, with no visible replacement.

Just in case someone else needs it, here's the definition that I just
put into my copy of Core.py:

----------------------------------------------------------------------
class _index_expression_class:

    def __getitem__(self, item):
        if type(item) != type(()):
            return (item,)
        else:
            return item

index_expression = _index_expression_class()
----------------------------------------------------------------------

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From drh@cse.unl.edu  Wed Oct 16 15:04:22 1996
From: drh@cse.unl.edu (Doug Heisterkamp)
Date: Wed, 16 Oct 1996 09:04:22 -0500 (CDT)
Subject: [PYTHON MATRIX-SIG] Bug in LinearAlgebra
In-Reply-To: <199610161115.MAA05689@ibs.ibs.fr> from "Konrad Hinsen" at Oct 16, 96 12:08:55 pm
Message-ID: <199610161404.JAA08876@cse.unl.edu>

> 

I added the determinant function to LinAlg.py as an afterthought just before 
sending it to Jim.  It was a very poor thought, considering it was wrong and
the name was not even spelled right!

Just want people to know that Jim did not mess up the determinate.

Doug Heisterkamp
drh@cse.unl.edu


> > > Here's the fixed (but not really tested) version of determinant:
> > > 
> > > def determinate(a):
> > >     _assertRank2(a)
> > >     _assertSquareness(a)
> > >     ev = eigenvalues(a)
> > >     return Numeric.product(ev)
> > 
> > If somebody more LA familiar than myself can confirm and test this I'll
> > make the change in the standard distribution.
> 
> That is indeed a correct way to calculate the determinant, although
> not the most efficient one (LU decomposition is faster). If I find the
> time I'll do something better, but this one is of course much
> preferable to the current (wrong) function. But please also correct
> the name to "determinant"!
> 
> Konrad.
> -- 
> -------------------------------------------------------------------------------
> Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
> Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
> Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
> 41, av. des Martyrs                    | Deutsch/Esperanto/English/
> 38027 Grenoble Cedex 1, France         | Nederlands/Francais
> -------------------------------------------------------------------------------
> 
> =================
> MATRIX-SIG  - SIG on Matrix Math for Python
> 
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================
> 


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From phil@geog.ubc.ca  Wed Oct 16 16:17:49 1996
From: phil@geog.ubc.ca (Phil Austin)
Date: Wed, 16 Oct 1996 08:17:49 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610161356.OAA07227@ibs.ibs.fr>
References: <199610161356.OAA07227@ibs.ibs.fr>
Message-ID: <199610161517.IAA09508@coot.geog.ubc.ca>

>>>>> "Konrad" == Konrad Hinsen <hinsen@ibs.ibs.fr> writes:

    Konrad> What happened to the slice generator that was in Numeric
    Konrad> in earlier versions? It seems to have disappeared, with no
    Konrad> visible replacement.

    Konrad> Just in case someone else needs it, here's the definition
    Konrad> that I just put into my copy of Core.py:

    Konrad> ----------------------------------------------------------------------
    Konrad> class _index_expression_class:

    Konrad>     def __getitem__(self, item): if type(item) !=
    Konrad> type(()): return (item,) else: return item

    Konrad> index_expression = _index_expression_class()
    Konrad> ----------------------------------------------------------------------


An ignorant question: does this give the functionality of
a Fortran90 array mask (or logical indexes in Splus)?

i.e. is there a NumPy equivalent to this Splus expression, which finds
the warm, dark, sea-surface in a cloudy satellite image for which I
have temperature and reflectivity:

seaSurfaceIndex -> (temp > 280) & (reflec < 0.10)
meanSST -> mean(temp[seaSurfaceIndex])


Phil Austin		INTERNET: phil@geog.ubc.ca
(604) 822-2175		FAX:	  (604) 822-6150

http://www.geog.ubc.ca/~phil
Associate Professor
Atmospheric Sciences Programme
Geography #217
University of British Columbia
1984 W Mall
Vancouver, BC  V6T 1Z2
CANADA


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Wed Oct 16 17:52:33 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 16 Oct 96 17:52:33 +0100
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610161517.IAA09508@coot.geog.ubc.ca> (message from Phil
 Austin on Wed, 16 Oct 1996 08:17:49 -0700 (PDT))
Message-ID: <199610161658.RAA09080@ibs.ibs.fr>

> An ignorant question: does this give the functionality of
> a Fortran90 array mask (or logical indexes in Splus)?

Probably not, although I am not sure what you are talking about ;-)

> i.e. is there a NumPy equivalent to this Splus expression, which finds
> the warm, dark, sea-surface in a cloudy satellite image for which I
> have temperature and reflectivity:
> 
> seaSurfaceIndex -> (temp > 280) & (reflec < 0.10)
> meanSST -> mean(temp[seaSurfaceIndex])

No, that's something else, which you would do using repeat()
in NumPy:

  repeat(temp, logical_and(greater(temp, 280), less(reflec, 0.10)))

would give you all elements of temp corresponding to the selected
condition.


My code for index_expression lets you build up multidimensional index
expressions from pieces. You need this to index arrays whose
dimensionality is unknown when you write the code. An example: I have
written a class that represents a function given numerically on a grid
(with operations such as interpolation, integration, differentiation,
and polynomial fitting), which works for functions of any number of
variables. It must sometimes index along a particular axis given
as a number, i.e.

   a[::,::,::, ... ,::, 0]
     ---n times :: ---

Piecing together index expressions is no problem, as they are just
tuples, but *making* them requires a trick, because notations like ::
are syntactically legal only inside brackets. My index_expression code
just allows you to extract the tuple generated by indexing instead
of applying it directly.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From klm@CNRI.Reston.Va.US  Wed Oct 16 17:12:35 1996
From: klm@CNRI.Reston.Va.US (Ken Manheimer)
Date: Wed, 16 Oct 1996 12:12:35 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] autocorrelation functions? (fwd)
In-Reply-To: <199610160321.XAA29568@maigret>
Message-ID: <Pine.SOL.3.95.961016110025.9131Z-100000@glyph>

> PS: Say, Matrix-sig coordinator, how many subscribers are there to this
>     illustrious list?

It's easier for me to just take a look at the distribution list file -
the answer is 126.

Ken


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Wed Oct 16 19:10:23 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Wed, 16 Oct 1996 13:10:23 -0500
Subject: [PYTHON MATRIX-SIG] Keyword arguments for ufuncs
Message-ID: <199610161805.OAA08728@python.org>


Aren't unfunc methods supposed to support keyword arguments?

a = Numeric.array(([1,2,3,4],[1,2,3,4]))
print a
print
print Numeric.product(a, 1)
print Numeric.product(a, axis=1)
================
1 2 3 4
1 2 3 4

24 24
Traceback (innermost last):
  File "<stdin>", line 19, in ?
TypeError: this function ta

-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From pas@lems.brown.edu  Wed Oct 16 20:53:36 1996
From: pas@lems.brown.edu (Perry A. Stoll)
Date: Wed, 16 Oct 1996 15:53:36 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610161356.OAA07227@ibs.ibs.fr>
Message-ID: <Pine.SUN.3.91.961016153234.13308C-100000@lems34>


I keep making this mistake...can someone put some documentation somewhere
that this index_expression _must_ be indexed with all three numbers to ensure
correct results, which is not the case with an actual array object. 

>>> index_expression[2:-2]                       
Traceback (innermost last):
  File "<stdin>", line 1, in ?
AttributeError: __len__
>>> index_expression[2:-2:1]
(slice(2, -2, 1),)

Thanks,
  -Perry
   <pas@lems.brown.edu>

On Wed, 16 Oct 1996, Konrad Hinsen wrote:

> Just in case someone else needs it, here's the definition that I just
> put into my copy of Core.py:
> 
> ----------------------------------------------------------------------
> class _index_expression_class:
> 
>     def __getitem__(self, item):
>         if type(item) != type(()):
>             return (item,)
>         else:
>             return item
> 
> index_expression = _index_expression_class()
> ----------------------------------------------------------------------

=================
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 Oct 17 10:14:13 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 17 Oct 96 10:14:13 +0100
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <Pine.SUN.3.91.961016153234.13308C-100000@lems34>
 (pas@lems.brown.edu)
Message-ID: <199610170920.KAA11592@ibs.ibs.fr>

> I keep making this mistake...can someone put some documentation somewhere
> that this index_expression _must_ be indexed with all three numbers to ensure
> correct results, which is not the case with an actual array object. 
> 
> >>> index_expression[2:-2]                       
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> AttributeError: __len__
> >>> index_expression[2:-2:1]
> (slice(2, -2, 1),)

Unfortunately there is no way to remove that restriction completely.
I could make standard slices work for the case where both indices
are specified (by implementing __getslice__ and a dummy __len__ that
always returns zero), but you'd get a wrong answer if you leave out
the second index (which would then be set to zero). You could
obtain the correct result if __len__ could return None, but it must
return a non-negative integer...

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From pas@lems.brown.edu  Thu Oct 17 15:52:06 1996
From: pas@lems.brown.edu (Perry A. Stoll)
Date: Thu, 17 Oct 1996 10:52:06 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610170920.KAA11592@ibs.ibs.fr>
Message-ID: <Pine.SUN.3.91.961017104229.14138A-100000@lems34>



On Thu, 17 Oct 1996, Konrad Hinsen wrote:

> > I keep making this mistake...can someone put some documentation somewhere
> > that this index_expression _must_ be indexed with all three numbers to ensure
> > correct results, which is not the case with an actual array object. 
> > 
> 
> Unfortunately there is no way to remove that restriction completely.

Agree, not within the index_expression_class. How about going back to
something from NumPy.03? to make it a little more forgiving:

def slice_generator(i=None, j=None, k=1):
    if i == None:
        if j == None:
            return index_expression[::k]
        else:
            return index_expression[:j:k]
    else:
        if j == None:
            return index_expression[i::k]
        else:
            return index_expression[i:j:k]


 -Perry


=================
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 Oct 17 17:42:26 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 17 Oct 96 17:42:26 +0100
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <Pine.SUN.3.91.961017104229.14138A-100000@lems34>
 (pas@lems.brown.edu)
Message-ID: <199610171648.RAA14862@ibs.ibs.fr>

> Agree, not within the index_expression_class. How about going back to
> something from NumPy.03? to make it a little more forgiving:
> 
> def slice_generator(i=None, j=None, k=1):
>     if i == None:
>         if j == None:
>             return index_expression[::k]
>         else:
>             return index_expression[:j:k]
>     else:
>         if j == None:
>             return index_expression[i::k]
>         else:
>             return index_expression[i:j:k]

Fine, but then you use another syntax. What I like about the
index_expression stuff is that it is exactly the indexing syntax
(except for simple slices), in all its variants, including
NewAxis, ellipses etc. Of course there is no reason not to
have both...

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Thu Oct 17 19:09:28 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Thu, 17 Oct 1996 13:09:28 -0500
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610170920.KAA11592@ibs.ibs.fr> (message from Konrad Hinsen on
 Thu, 17 Oct 96 10:14:13 +0100)
Message-ID: <199610171805.OAA11845@python.org>


Konrad Hinsen <hinsen@ibs.ibs.fr> writes

Someone else says (sorry!):
>> I keep making this mistake...can someone put some documentation somewhere
>> that this index_expression _must_ be indexed with all three numbers to ensure
>> correct results, which is not the case with an actual array object. 
>> 
>> >>> index_expression[2:-2]                       
>> Traceback (innermost last):
>>   File "<stdin>", line 1, in ?
>> AttributeError: __len__
>> >>> index_expression[2:-2:1]
>> (slice(2, -2, 1),)

>Unfortunately there is no way to remove that restriction completely.
>I could make standard slices work for the case where both indices
>are specified (by implementing __getslice__ and a dummy __len__ that
>always returns zero), but you'd get a wrong answer if you leave out
>the second index (which would then be set to zero). You could
>obtain the correct result if __len__ could return None, but it must
>return a non-negative integer...

How about something like this (maxint should be safe because you can't
index past maxint anyway...):

class Index_expression_class:
    import sys
    maxint = sys.maxint

    def __getitem__(self, index):
	if type(index) == type(()):
	    return index
	else:
	    return (index,)

    def __len__(self):
	return self.maxint

    def __getslice__(self, start, stop):
	if stop == self.maxint:
	    stop = None
	return self[start:stop:1]

index_expression = Index_expression_class()



-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Thu Oct 17 19:15:20 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Thu, 17 Oct 1996 13:15:20 -0500
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610170920.KAA11592@ibs.ibs.fr> (message from Konrad Hinsen on
 Thu, 17 Oct 96 10:14:13 +0100)
Message-ID: <199610171810.OAA11862@python.org>


Or better yet (for aethetic reasons...), replace the 1 with None:

class Index_expression_class:

    ....

    def __getslice__(self, start, stop):
	if stop == self.maxint:
	    stop = None
	return self[start:stop:None]





-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From pas@lems.brown.edu  Thu Oct 17 19:44:16 1996
From: pas@lems.brown.edu (Perry A. Stoll)
Date: Thu, 17 Oct 1996 14:44:16 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610171820.OAA04926@maigret>
Message-ID: <Pine.SUN.3.91.961017143048.14344A-100000@lems34>



On Thu, 17 Oct 1996, David Ascher wrote:

> I'm asleep.  What's the point of the index_expression thing y'all have
> been talking about?

Dave, I thought this might be useful to a more general audiance, so I'm
copying it to the list.

Let's say you want to compute the forward difference between successive 
elements in a 1d array. Pretty simple:

answer = input[1:] - input[:-1]

But now do it for an n-dimensional input along any dimension. You need to
be able to construct an object capable of indexing an array, a la the 
index_expression.

forward_indicies = indexing_magic()
backward_indicies = idexing_magic()
answer = input[forward_indicies] - input[backward_indicies]

I've attached my file for forward, backward, and central differences for
N-dimensional arrays computing the difference along any dimension. (this
worked, last I checked with, an old release...your mileage WILL vary. ;-)

-Perry

# array_differencing.py

import Numeric

class _index_expression_class:
    #
    def __getitem__(self, item):
        if type(item) != type(()):
            return (item,)
        else:
	    return item

index_expression = _index_expression_class()

def _computeGeneralSlice(start,end=None,skip=None,paddims=0):
    """Return an expression which slices any one dimension of an array
    object.

    Note that paddims has basically the opposite meaning from a normal
    axis specification, namely paddims=0 == axis=-1, paddims=1 ==
    axis=-2,etc."""

    if paddims < 0:
	raise ValueError,"paddims must be non-negative"
    outindex = (index_expression[...], \
		index_expression[start:end:skip]) \
		+ (index_expression[::],) * paddims
    return outindex

def _copyAndZero(arr):
    return apply(Numeric.zeros,arr.shape + (arr.typecode(),))

def _computePadDims(arr,axis):
    """Compute the number of dimensios needed in an index expression to
    select the specified (possibly negative) axis."""
    p = -(axis + 1)
    if axis >= 0:
	p = p + len(arr.shape)
    return p

def central_diff(arr,n=1,axis=-1):
    paddims  = _computePadDims(arr,axis)
    outindex = _dimensionalSlice(1,-1,paddims=paddims)
    index1   = _computeGeneralSlice(2, None, paddims=paddims)
    index2   = outindex
    index3   = _computeGeneralSlice(None,-2, paddims=paddims)
    # do the actual computation
    outarr   = _copyAndZero(arr)
    outarr[outindex] = arr[index1] - 2*arr[index2] + arr[index3]
    if n > 1:
	outarr[outindex] = central_diff(outarr[outindex],n-1,axis)
    return outarr

def forward_diff(arr,diff=1,n=1,axis=-1):
    paddims  = _computePadDims(arr,axis)
    outindex = _computeGeneralSlice(None,-diff, paddims=paddims)
    index1   = _computeGeneralSlice(diff, None, paddims=paddims)
    index2   = outindex
    # do the actual computation
    outarr   = _copyAndZero(arr)
    outarr[outindex] = arr[index1] - arr[index2]
    if n > 1:
	outarr[outindex] = forward_diff(outarr[outindex],diff,n-1,dimension)
    return outarr

def backward_difference(arr,diff=1,n=1,axis=-1):
    paddims  = _computePadDims(arr,axis)
    outindex = _computeGeneralSlice(diff,None,paddims=paddims)
    index1   = outindex
    index2   = _computeGeneralSlice(None,-diff,paddims=paddims)
    # do the actual computation
    outarr   = _copyAndZero(arr)
    outarr[outindex] = arr[index1] - arr[index2]
    if n > 1:
	outarr[outindex] = backward_diff(outarr[outindex],diff,n-1,dimension)
    return outarr

=================
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 Oct 17 20:37:21 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Thu, 17 Oct 1996 15:37:21 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Creating grid object
In-Reply-To: <9610110753.AA05438@flores.ifm.uni-kiel.de> from "janko hauser" at Oct 11, 96 09:53:22 am
Message-ID: <199610171937.PAA05147@maigret>

> Thanks for your reply. I tried it that way, but the problem is, that I
> can't use normal functions on the new class, like
> shape(new_class_instance) 
> Here I must use at the moment
> shape(new_class_instance.array)
> or I must add this function to MyUserArray in the same way sin and cos
> are added. But I think this is not a generally good way.

Yes.  It's a point worth raising.  I too care about UserArray
subclasses, and I'd want functions which take arrays as argument to be
able to work with userarrays.

It shouldn't be too bad of a problem if UserArray is kept up to date --
as long as it has the same attributes as the arrays it wraps, then all
functions which work on arrays will work on it (correct?).

Given that I just said that, it doesn't really work right now.  I would
have guessed that shape(x) returns x.shape, but a little testing shows
that that is not true in 1.4b3.  Shouldn't it be?

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Fri Oct 18 11:29:14 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 18 Oct 96 11:29:14 +0100
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <199610171904.UAA15715@ibs.ibs.fr> (tim@lassi.ece.uiuc.edu)
Message-ID: <199610181035.LAA18358@ibs.ibs.fr>

> How about something like this (maxint should be safe because you can't
> index past maxint anyway...):
> ...

Hmmm... I am not particularly fond of such tricks, but I am willing
to make an exception because
1) it works
2) there seems to be no other solution
3) users don't have to know about it.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jhauser@ifm.uni-kiel.de  Fri Oct 18 12:47:41 1996
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Fri, 18 Oct 1996 13:47:41 +0200
Subject: [PYTHON MATRIX-SIG] Something broken with __mul__?
Message-ID: <9610181147.AA09006@flores.ifm.uni-kiel.de>


I try to build a class similar to UserArray, and have some
problems. Here is my attempt.

#! /home/caesar/u1/hauser/bin/python 
#
#from multiarray import array, zeros, arraytype
#from fast_umath import *
import ni
from Numeric.Core import *
from Numeric.UserArray  import UserArray
from fast_umath import *
import string

    
def _as_array(a):
    if hasattr(a, "array"):
	return a.array
    else:
	return a


class a_mesh:
    def __init__(self, data, dx, dz, typecode=None):
	# More testing later
	if shape(data) != shape(dx):
	    raise ValueError, 'Inconsistent dimensions'
	if typecode == None:
	    self.array = array(data)
	    self.gx= array(dx)
	    self.gz= array(dz)
	else:
	    self.array = array(data, typecode)
	    self.gx= array(dx, typecode)
	    self.gz= array(dz, typecode)

	self.shape = self.array.shape
	self.name = string.split(str(self.__class__))[1]

    def __repr__(self):
	return str(self.array)[:] 

    # Array as sequence
    def __len__(self): return len(self.array)
    def __getitem__(self, index): 
	return self._return_constructor(self.array[index],self.gx[index],self.gz[index])
    def __getslice__(self, i, j): 
	return self._return_constructor(self.array[i:j],self.gx[i:j],self.gz[i:j])

    def __setitem__(self, index, value): self.array[index] = _as_array(value)
    def __setslice__(self, i, j, value): self.array[i:j] = _as_array(value)

    def __abs__(self): return self._return_constructor(abs(self.array),self.gx,self.gz)
    def __neg__(self): return self._return_constructor(-self.array,self.gx,self.gz)
    def __mul__(self, other): 
	return self._return_constructor(_as_array(self)*_as_array(other),self.gx,self.gz)
    __rmul__ = __mul__

    def __less__(self,other): 
	print 'test'
 	tmp=_as_array(self).less(_as_array(other))
 	print tmp
 	return self._return_constructor(tmp,self.gx,self.gz)


a_mesh._return_constructor=a_mesh

#def less(dat,other):
#    if hasattr(dat,"array"):
#	return a_mesh(less(dat.array,other),dat.gx,dat.gz)
#    else:
#	return less(dat,other)


#############################################
# Test
#############################################

if __name__ == '__main__':

    data=array([[[1,2,3],[4,5,6],[7,8,9]],
	       [[1,2,3],[4,5,6],[7,8,9]],
	       [[1,2,3],[4,5,6],[7,8,9]]])
    dx=data
    dz=data
    data=sqrt(data)

    a=a_mesh(data,dx,dz,Float32)
    b=a[:,:,0:2]
    print b.shape, type(b)
    # print less(b,2.)  #this give an error, too
    c=UserArray([1,2,3,4,5])
    print c,c*4
    print b*3.
    print b*3

### Output ######
(3, 3, 2) <type 'instance'>
1 2 3 4 5  4  8 12 16 20
 3.          4.24264061
 6.          6.70820403
 7.93725371  8.48528123

 3.          4.24264061
 6.          6.70820403
 7.93725371  8.48528123

 3.          4.24264061
 6.          6.70820403
 7.93725371  8.48528123
Traceback (innermost last):
  File "<stdin>", line 91, in ?
  File "<stdin>", line 52, in __mul__
TypeError: cannot perform this operation on these types

If I change * to multiply in the definition, this is ok. But with the
definition of 'less' I have no success. And if less is really a
function and not a method, do I need a definition at all?

Thanks to Konrad Hinsen, to convince me, that I don't make a stupid
mistake :-).

__Janko


=================
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 Oct 18 17:36:34 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 18 Oct 96 17:36:34 +0100
Subject: [PYTHON MATRIX-SIG] Something broken with __mul__?
In-Reply-To: <9610181147.AA09006@flores.ifm.uni-kiel.de> (message from janko
 hauser on Fri, 18 Oct 1996 13:47:41 +0200)
Message-ID: <199610181643.RAA20685@ibs.ibs.fr>

> I try to build a class similar to UserArray, and have some
> problems. Here is my attempt.
> ...
>     a=a_mesh(data,dx,dz,Float32)
                          ^^^^^^^
> ...
>     print b*3
              ^
> ...
> If I change * to multiply in the definition, this is ok. But with the
> definition of 'less' I have no success. And if less is really a
> function and not a method, do I need a definition at all?

Just to add *why* multiplication with * fails: it doesn't
accept an integer and a Float32 as arguments. Making either
or both arguments float solves the problem.

I don't remember exactly the result of the long debate about
coercion and combination of different data types, but somehow
I think this is not correct...

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Fri Oct 18 17:08:20 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 18 Oct 1996 12:08:20 -0400
Subject: [PYTHON MATRIX-SIG] Slice expressions
Message-ID: <9610181605.AA21211@goldilocks.LCS.MIT.EDU>


Python1.4beta3 now has the builtin function slice which serves this
function beautifully.  If you still need the index_expression function then
something's wrong.

-Jim

> What happened to the slice generator that was in Numeric in earlier
> versions? It seems to have disappeared, with no visible replacement.


=================
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 Oct 18 17:27:09 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 18 Oct 1996 12:27:09 -0400
Subject: [PYTHON MATRIX-SIG] Something broken with __mul__?
Message-ID: <9610181624.AA21409@goldilocks.LCS.MIT.EDU>


> Just to add *why* multiplication with * fails: it doesn't
> accept an integer and a Float32 as arguments. Making either
> or both arguments float solves the problem.
> 
> I don't remember exactly the result of the long debate about
> coercion and combination of different data types, but somehow
> I think this is not correct...

This was the best compromise I could come up with after all of the many
debates.  I don't think it's reasonable to have a long int multiplied by a
32-bit float return a 32-bit float (which is usually what I want when doing
this calculation).  As you say, it's not to hard to work around this
problem by making the integer a float, ie.

 print b*3.

I like this feature of having to think and add the decimal point because it
makes clear that the array you are going to get back will contain doubles
and not floats.

-Jim


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Fri Oct 18 18:00:38 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Fri, 18 Oct 1996 12:00:38 -0500
Subject: [PYTHON MATRIX-SIG] Something broken with __mul__?
In-Reply-To: <199610181643.RAA20685@ibs.ibs.fr> (message from Konrad Hinsen on
 Fri, 18 Oct 96 17:36:34 +0100)
Message-ID: <199610181656.MAA03440@python.org>



Konrad Hinsen writes:

<...>

>Just to add *why* multiplication with * fails: it doesn't
>accept an integer and a Float32 as arguments. Making either
>or both arguments float solves the problem.

I just looked and PyArray_CanCastSafely in arrayobject.c is set up
only to allow conversions from ints, longs, etc. to doubles, not to
floats. Why? I'm betting it's a typo, but I've been known to be wrong
before. If int->float is meant to be allowed, it's an easy fix:

	case PyArray_LONG:
		return (totype > PyArray_FLOAT); 

is changed to:

	case PyArray_LONG:
		return (totype >= PyArray_FLOAT); 
	

in lines 1709-10 of arrayobject.c.

>I don't remember exactly the result of the long debate about
>coercion and combination of different data types, but somehow
>I think this is not correct...

That would be my guess as well...

-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Fri Oct 18 18:07:17 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Fri, 18 Oct 1996 12:07:17 -0500
Subject: [PYTHON MATRIX-SIG] Something broken with __mul__?
In-Reply-To: <9610181624.AA21409@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610181702.NAA03457@python.org>


Jim Hugunin writes:

>This was the best compromise I could come up with after all of the many
>debates.  I don't think it's reasonable to have a long int multiplied by a
>32-bit float return a 32-bit float (which is usually what I want when doing
>this calculation).  As you say, it's not to hard to work around this
>problem by making the integer a float, ie.

Ooops. Scratch what I just said about it probably being a
typo. Sorry!!

> print b*3.
>
>I like this feature of having to think and add the decimal point because it
>makes clear that the array you are going to get back will contain doubles
>and not floats.

What if I want to use and array of floats without going to doubles
(because of space issues, say) ?

OK, nevermind, I can just use a single element float array to force
that behaviour.






-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Fri Oct 18 19:44:59 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 18 Oct 96 19:44:59 +0100
Subject: [PYTHON MATRIX-SIG] Slice expressions
In-Reply-To: <9610181605.AA21211@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610181851.TAA21215@ibs.ibs.fr>

> Python1.4beta3 now has the builtin function slice which serves this
> function beautifully.  If you still need the index_expression function then
> something's wrong.

Indeed something is wrong: I don't have the documentation for
Python 1.4 ;-)

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Fri Oct 18 19:17:43 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 18 Oct 1996 14:17:43 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] IMSL bindings
Message-ID: <199610181817.OAA07129@maigret>

It would make some people here very happy if there were Python
bindings to the IMSL Fortran libraries (and C, but they're less
complete).

Have people come up with tools which make binding to Fortran
libraries relatively automatic?  IMSL is fairly big.

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Fri Oct 18 19:24:05 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 18 Oct 1996 14:24:05 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
Message-ID: <199610181824.OAA07181@maigret>

Along similar lines as the IMSL bindings I just mentioned, has
anyone wrapped the numerical recipes in C?  

--david

=================
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 Oct 18 21:11:00 1996
From: jim.fulton@digicool.com (Jim Fulton)
Date: Fri, 18 Oct 1996 16:11:00 -0400
Subject: [PYTHON MATRIX-SIG] IMSL bindings
References: <199610181817.OAA07129@maigret>
Message-ID: <3267E454.2635@digicool.com>

David Ascher wrote:
> 
> It would make some people here very happy if there were Python
> bindings to the IMSL Fortran libraries (and C, but they're less
> complete).
> 
> Have people come up with tools which make binding to Fortran
> libraries relatively automatic?  IMSL is fairly big.

You want fidl:

NAME
       fidl - Fortran interface description language for building
       Python modules

SYNOPSIS
       fidl [ -c ] [ -l library ] foomodule.fidl  ...

DESCRIPTION
       The Fortran interface description language (fidl) provides
       a  mechanism  for calling Fortran routines from the Python
       object-oriented interpreter.  In addition, the  interfaces
       to  routines  may be significantly simplified, because the
       interface created by a fidl compiler is able  to  generate
       many arguments automatically.

       When  a  Fortran program requires an input array argument,
       any Python sequence object may be passed.  For example, if
       a  two-dimensional  array  is  expected, any Python object
       that behaves as a sequence of  sequences  may  be  passed,
       such  as  a  list  of lists, a tuple of tuples, a database
       table, and so on.

       Routines are described by writing fidl  specification  for
       each  routine.  A fidl compiler converts a fidl specifica-
       tion into a C python module that  interfaces  between  the
       python interpreter and the Fortran routines.

       The fidl spec is provided in a file.  The name of the file
       is given as the last argument to the fidl command and must
       consist  of  a  module  name  concatinated with the suffix
       "module.py".  For example, to create a Python module named
       "spam",  create  a  fidl  spec named spammodule.fidl.  The
       generated C file will have the same name as the fidl  spec
       except  that  the  ".fidl"  suffix is changed to ".c".  If
       requested, the generated  C  file  will  be  compiled  and
       linked  with  any specified Fortran libraries to produce a
       shared object library that may be  imported  into  python.
       The  shared  object library will have the same name as the
       fidl spec except that the ".fidl"  suffix  is  changed  to
       ".so".

       A  fidl specification consists of a routine return type, a
       routine name, and a list of argument specifications  sepa-
       rated by commas. For example:

         c Fit an Akima spline function

         subroutine dcsakm(in integer ndata,
                     in double xdata(ndata),
                           in double fdata(ndata),
                     out double csbreak(ndata),
                     out double cscoef(ndata,4));

       specifies  a routine of type subroutine, named dcsakm, and
       taking 5 arguments.  Valid return types  are:  subroutine,
       real,  double,  integer  (or  int),  integer*1, integer*2,
       integer*4, and character.  A  return  type  of  subroutine
       means  that  the routine does not return a value from For-
       tran.  The return type may be ommitted, in  which  case  a
       subroutine is assumed.

       Note  that  Fortran-style comments can be included in fidl
       specs.  They will be  retained  as  documentation  strings
       (which  can  be  accessed  from  Python)  of the generated
       python-callable functions.  Comments may also be  provided
       for  empty fidl specifications, in which case the comments
       are used to build the module documentation string for  the
       generated module.

       Each  argument  definition  consists of an argument direc-
       tion, type, name, and optional dimension.  Valid  argument
       types  are:  real,  double,  integer  (or int), integer*1,
       integer*2, integer*4, and character. The argument type may
       be  ommitted,  in  which  case  the  argument type will be
       inferred from the argument name using usual  Fortran  con-
       ventions.  Valid  argument  directions  are in, expr, out,
       modify, work, ok, and error. If the argument direction  is
       ommitted,  then  a direction of "in" will be assumed. Each
       of these directions are described below.

       Arguments that have direction of "in" are input arguments.
       Only  input  and  modify  arguments need to be passed from
       python scripts, and only if they can not be  infered  from
       other  information.   In  particular, input dimensions are
       inferred from the dimensions of the arrays passed, because
       the  generated  C code can determine the sizes of sequence
       objects passed.  For example, in the specification  above,
       the input argument, ndata, is not passed because it can be
       inferred from the dimension of xdata.  The  dimensions  of
       xdata  and  fdata  are  checked  to make sure they are the
       same.

       Arguments that are direction "expr" are  used  for  scalar
       arguments  that  can  be  computed from other arguments or
       from  argument  dimensions.   For  these  arguments,  a  C
       expression  is  provided  in parentheses where a dimension
       would otherwise be expected.

       Arguments that have direction "out" are output  arguments.
       Even  though  they are passed to the fortran routine, they
       are not passed from Python, but are  generated  by  the  C
       interface  generated by fidl.  Python functions can return
       multiple arguments (by returning  tuples).   Output  argu-
       ments are returned along with the Fortran return value, if
       any.  For example, the function  dcsakm   specified  above
       will  return  two values to python, the arrays csbreak and
       cscoef.

       Arguments that have direction "modify" are treated as both
       input  and  output  arguments.   The argument is passed in
       from python and is returned to python as one of the  func-
       tion  return  values.   Note  that  the object passed from
       Python will not be modified unless it is a  Matrix  object
       with  the  same  data type that is required by the Fortran
       routine.

       Arguments that have direction "work" are used for  Fortran
       routines  that  need extra memory to perform computations.
       They are neither passed in  from  Python  or  returned  to
       python,  but  are  allocated  prior to calling the Fortran
       routine and freed after calling the Fortran routine.

       Arguments that have direction "ok" or "error" are used for
       output  arguments that indicate the success of the Fortran
       routine call.  They are not returned to  python  directly.
       If the value of an "ok" argument is zero after the Fortran
       routine is called, then a Python exception  is  raised  to
       indicate  the  error.  If the value of an "error" argument
       is non-zero after the Fortran routine is  called,  then  a
       Python  exception  is  raised  to indicate the error.  The
       type of the exception will be the  string  "module.error",
       where "module" is the name of the Fortran module.

OPTIONS
       -c      If  the  -c  option is given, then the generated C
               code will be compiled.  This  is  useful,  because
               special  compiler options needed by Python modules
               (for example, to specify the location of Python  C
               include  files) are provided.  The command used to
               compile the module is echod to standard output.

       -l library
               Specify a library to be linked  with  the  module.
               This  option may be given multiple times, once for
               each library specified.  The  libraries  specified
               should be Fortran libraries.

               If  any libraries are specified, then the compiled
               C code will be linked with the libraries to create
               a shared object library.  The command used to link
               the files and create the shared object library  is
               echod to standard output.


EXAMPLES
       Given  the  following  fidl  specification  (in  the  file
       interpmodule.fidl):

       c Spline interpolation using Akima algorithm
       c
       c Demonstration fidl module
       ;

       c Fit an Akima spline function
       subroutine dcsakm(in integer ndata,
                   in double xdata(ndata),
                         in double fdata(ndata),
                   out double csbreak(ndata),
                   out double cscoef(ndata,4));

       c Use a fitted spline function to interpolate a point
       double dcsval(in double x,
                     expr int nintv(ndata-1),
                     in double csbreak(ndata),
                  in double cscoef(ndata,4));

       The following Python code shows how the module might be used:

       import interp

       b,c = dcsakm([0, .1, .2, .5], [100, 200, 10, 50])

       for i in range(50):
         print dcsval(i/100.0,b,c)


SEE ALSO
       python(1), f77(1)

BUGS
       This tool is still in a very preliminary form.


Note that the above example is for an IMSL routine.
FIDL has been in a beta testing state for some time because
I haven't been able to get any beta testers to actually
test it, or at least to let me know how it works.  
If you are interested in *really* being a beta tester, 
let me know and I'll point you at the current version.

Note that fidl uses a precursor to NumPy arrays.  It should 
work with NumPy with a little extra copying.  I'm planning
to integrate NumPy with FIDL, but it hasn't been a high 
priority since I changed jobs and no longer need fidl myself.

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 jim.fulton@digicool.com  Fri Oct 18 21:15:24 1996
From: jim.fulton@digicool.com (Jim Fulton)
Date: Fri, 18 Oct 1996 16:15:24 -0400
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
References: <199610181824.OAA07181@maigret>
Message-ID: <3267E55C.755A@digicool.com>

David Ascher wrote:
> 
> Along similar lines as the IMSL bindings I just mentioned, has
> anyone wrapped the numerical recipes in C?

The routines in numerical recipes are copyrighted.

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 da@maigret.cog.brown.edu  Fri Oct 18 22:32:01 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 18 Oct 1996 17:32:01 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
In-Reply-To: <3267E55C.755A@digicool.com> from "Jim Fulton" at Oct 18, 96 04:15:24 pm
Message-ID: <199610182132.RAA07539@maigret>

> > Along similar lines as the IMSL bindings I just mentioned, has
> > anyone wrapped the numerical recipes in C?
> 
> The routines in numerical recipes are copyrighted.

I don't mean to rewrite the routines, just provide wrappers.  If the
user has the C library (licensed or whatever), then they can build a
Python module.  Do they copyright the *interface*?

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Fri Oct 18 22:32:01 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 18 Oct 1996 17:32:01 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
In-Reply-To: <3267E55C.755A@digicool.com> from "Jim Fulton" at Oct 18, 96 04:15:24 pm
Message-ID: <199610182132.RAA07539@maigret>

> > Along similar lines as the IMSL bindings I just mentioned, has
> > anyone wrapped the numerical recipes in C?
> 
> The routines in numerical recipes are copyrighted.

I don't mean to rewrite the routines, just provide wrappers.  If the
user has the C library (licensed or whatever), then they can build a
Python module.  Do they copyright the *interface*?

--david


=================
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 Oct 18 23:20:55 1996
From: jim.fulton@digicool.com (Jim Fulton)
Date: Fri, 18 Oct 1996 18:20:55 -0400
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
References: <199610182132.RAA07539@maigret>
Message-ID: <326802C7.280E@digicool.com>

David Ascher wrote:
> 
> > > Along similar lines as the IMSL bindings I just mentioned, has
> > > anyone wrapped the numerical recipes in C?
> >
> > The routines in numerical recipes are copyrighted.
> 
> I don't mean to rewrite the routines, just provide wrappers.  If the
> user has the C library (licensed or whatever), then they can build a
> Python module.  Do they copyright the *interface*?

I don't know.

-- 
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 Oct 18 23:42:10 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 18 Oct 1996 18:42:10 -0400
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
Message-ID: <9610182239.AA25672@goldilocks.LCS.MIT.EDU>


Time for one of my usual Friday releases.

I've just put together the alpha5 release and also threw together a web
page in preparation for a soon to be public release of NumPy.  I think that
most of the major issues are straightened out now and my main concern is to
beat on this a little bit for stability and to make sure it works on as
many platforms as possible (and also for David Ascher to find the time to
update his tutorial).

So, please pick this release up and give it a try.  I'm particularly
interested in what platforms it does/does not compile on as well as any
tips for building it on "difficult" platforms.

This is also your last chance to make any major design changes to the
system.  If there's something about how NumPy works that you really don't
like, speak up now while I'm still willing to sacrifice backward
compatibility.  I have a farily extensive set of tools built using this
stuff (as I'm sure others do) and I don't want to rebuild it all ever again
;-)

You can get this latest distribution at:

http://www.sls.lcs.mit.edu/~jjh/numpy/download.html

Yes, I've finally moved up in the world from ftp to http ;-)

This site contains a source distribution that should work just about
anywhere, and a binary distribution for Windows NT/95 (untested).

As usual, if you get this please let me know what platforms you succeed or
fail to compile this on.

Enjoy - Jim

Major Changes from alpha4

No more packages (I think ni is a great idea who's time has not yet
come...)
umath is now the default math library.  If you REALLY want speed, do "from
fast_umath import *"
determinant is spelled and implemented correctly


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Sat Oct 19 02:20:29 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Fri, 18 Oct 1996 20:20:29 -0500
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
In-Reply-To: <9610182239.AA25672@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610190344.XAA04931@python.org>


>Time for one of my usual Friday releases.

Oh goody it's just like Christmas!

>This is also your last chance to make any major design changes to the
>system.  If there's something about how NumPy works that you really don't
>like, speak up now while I'm still willing to sacrifice backward
>compatibility.

I think someone may have answered this once allready, but if so I
forget what they said:

Why is the imaginary component of a matrix M M.imaginary while that of
a complex number Z is Z.imag. There have been several simple functions
that I've writen that wouldn't have cared whether they were dealing
with matrices or numbers except for this. 

Am I missing something obvious here...?


-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Sat Oct 19 17:46:00 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sat, 19 Oct 96 17:46:00 +0100
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
In-Reply-To: <326802C7.280E@digicool.com> (message from Jim Fulton on Fri, 18
 Oct 1996 18:20:55 -0400)
Message-ID: <199610191652.RAA23519@ibs.ibs.fr>


> > I don't mean to rewrite the routines, just provide wrappers.  If the
> > user has the C library (licensed or whatever), then they can build a
> > Python module.  Do they copyright the *interface*?
> 
> I don't know.

First, I doubt that would be possible. Second, it would be stupid.
They provide the routines with the intention that people can use
them, so if using them would imply a breach of copyright, they
could as well stop distributing them.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From dubois1@llnl.gov  Sat Oct 19 17:57:16 1996
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Sat, 19 Oct 1996 09:57:16 -0700
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
Message-ID: <9610191701.AA21309@icf.llnl.gov.llnl.gov>

A great example of the Dubois Lemma: If you don't abbreviate anything, you
can't forget which abbreviation you used.

The usual counter-argument is, "I don't like all that typing." To which I
reply, either, "Get over it!", or "Mavis Beacon". (:->.

At least we aren't using aimag, like Fortran!

Your friend,

Paul, the touch typist

----------
> From: tim@lassi.ece.uiuc.edu
> To: hugunin@mit.edu
> Cc: matrix-sig@python.org
> Subject: Re: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
> Date: Friday, October 18, 1996 6:20 PM
> 
> 
> >Time for one of my usual Friday releases.
> 
> Oh goody it's just like Christmas!
> 
> >This is also your last chance to make any major design changes to the
> >system.  If there's something about how NumPy works that you really don't
> >like, speak up now while I'm still willing to sacrifice backward
> >compatibility.
> 
> I think someone may have answered this once allready, but if so I
> forget what they said:
> 
> Why is the imaginary component of a matrix M M.imaginary while that of
> a complex number Z is Z.imag. There have been several simple functions
> that I've writen that wouldn't have cared whether they were dealing
> with matrices or numbers except for this. 
> 
> Am I missing something obvious here...?
> 
> 
> -- 
> 	-tim
> 
> +--------------------------------------------------------------------+
> | Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
> | tim@lassi.ece.uiuc.edu              University of Illinois         |
> | http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
> +--------------------------------------------------------------------+
> 
> =================
> MATRIX-SIG  - SIG on Matrix Math for Python
> 
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================

=================
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  Sat Oct 19 18:18:29 1996
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Sat, 19 Oct 1996 10:18:29 -0700
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
Message-ID: <9610191718.AA21538@icf.llnl.gov.llnl.gov>

Taking a set of functional numerical software and creating a functional
interface to it is IMHO not a good choice, although it may be easy for Python
considering the power of the language and the various automatic tools such as
FIDL and SWIG.

However, you can do a much nicer job of presenting these facilities to the
user if you use a real OO encapsulation. Also, certain technical issues may
arise, such as when the software expects a function as an argument but the
function you want to pass, such as to an integration routine, is a Python
function, not a C function.

I did a consulting job that involved encapsulating the NAG C library in
Eiffel, which is a compiled OOPL, strongly typed. The result of this work is
in a book just appearing from Prentice Hall, "Object Technology for
Scientific Computing".  If someone got serious about encapsulating various
numerical libraries for Python it might be worth digesting what I did first. 

Disclaimer: I did this library and book on my own time, not for LLNL, which
therefore does not endorse either. However, LLNL has a strong interest in the
creation of numerical facilities for Python and I would be glad to confer
with anyone beginning such a task.

----------
> From: Konrad Hinsen <hinsen@ibs.ibs.fr>
> To: jim.fulton@digicool.com
> Cc: da@maigret.cog.brown.edu; matrix-sig@python.org
> Subject: Re: [PYTHON MATRIX-SIG] Numerical Recipes
> Date: Saturday, October 19, 1996 9:46 AM
> 
> 
> > > I don't mean to rewrite the routines, just provide wrappers.  If the
> > > user has the C library (licensed or whatever), then they can build a
> > > Python module.  Do they copyright the *interface*?
> > 
> > I don't know.
> 
> First, I doubt that would be possible. Second, it would be stupid.
> They provide the routines with the intention that people can use
> them, so if using them would imply a breach of copyright, they
> could as well stop distributing them.
> -- 
>
------------------------------------------------------------------------------
-
> Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
> Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
> Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
> 41, av. des Martyrs                    | Deutsch/Esperanto/English/
> 38027 Grenoble Cedex 1, France         | Nederlands/Francais
>
------------------------------------------------------------------------------
-
> 
> =================
> MATRIX-SIG  - SIG on Matrix Math for Python
> 
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Sat Oct 19 19:38:56 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sat, 19 Oct 96 19:38:56 +0100
Subject: [PYTHON MATRIX-SIG] Numerical Recipes
In-Reply-To: <9610191718.AA21538@icf.llnl.gov.llnl.gov> (dubois1@llnl.gov)
Message-ID: <199610191846.TAA23788@ibs.ibs.fr>

> Taking a set of functional numerical software and creating a functional
> interface to it is IMHO not a good choice, although it may be easy for Python
> considering the power of the language and the various automatic tools such as
> FIDL and SWIG.

But having an automatically generated low-level Python interface makes
it a lot easier to implement the "real" interface that users will see,
just as for LAPACK.

> therefore does not endorse either. However, LLNL has a strong interest in the
> creation of numerical facilities for Python and I would be glad to confer
> with anyone beginning such a task.

Now that the low-level stuff is coming to a first final point, maybe
we should use this mailing list to discuss exactly such things.  I see
the main problem in the huge to-do list; there are just too many
numerical methods out there that ought to be implemented.

Something I have started on myself is implementing the concept of a
function (in the mathematical/numerical sense). My idea was to have
different types of function objects (polynomials, interpolated
functions, splines...) that have, as far as possible, the same
interface.  I did implement those that I needed, which is
interpolating functions (i.e. functions defined by a grid of values
with linear interpolation) and polynomials.  Both types support
evaluation (obvious), differentiation, and integration.  Interpolating
functions also have subrange extraction and polynomial fit (which, of
course, returns a polynomial function). Of course there remains
a lot to be done.

Other fields I expect to be useful for my own work are:
- linear algebra (i.e. real matrix objects, including variants
  for symmetric matrices etc.)
- ordinary differential equations
- data analysis/statistics

Certainly others will have different preferences. We might in fact
need several mailing lists...

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Sun Oct 20 17:13:52 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Sun, 20 Oct 1996 12:13:52 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] round?
Message-ID: <199610201613.MAA10656@maigret>

Why is there no `round' ufunc?  

--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  Sun Oct 20 18:23:55 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Sun, 20 Oct 1996 13:23:55 -0400
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
Message-ID: <9610201739.AA14124@goldilocks.LCS.MIT.EDU>

> > Why is the imaginary component of a matrix M M.imaginary while that of
> > a complex number Z is Z.imag. There have been several simple functions
> > that I've writen that wouldn't have cared whether they were dealing
> > with matrices or numbers except for this. 
> > 
> > Am I missing something obvious here...?

Konrad wrote the complex number object and I wrote the array object and we
clearly got our signals crossed.  When designing this system we more or
less agreed on the use of no abbreviations in the naming conventions.  The
only exception to this that I'm aware of is the trig functions "sin",
"tan", "arcsin", etc. where the abbreviations are used almost universally.

I'd personally reccommend that we try and convince Guido to change the
complex number attributes to Z.imaginary in order to maintain this
consistent avoidence of abbreviations.  If he is unwilling to make this
change this soon before the 1.4 final release, then I'll change the array
objects for consistency.  Any objections?

On a similar note, Konrad has been suggesting for quite some time that
there should be ufuncs for real, imaginary and conjugate.  The advantage to
these functions is that they'd work on floats as expected, and they could
also work on user defined types.  I'll probably find time to add them
before the beta release.

-Jim

=================
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  Sun Oct 20 19:59:46 1996
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Sun, 20 Oct 1996 20:59:46 +0200
Subject: [PYTHON MATRIX-SIG] Where to go (was Numerical Recipes)
Message-ID: <9610201859.AA14694@caesar.ifm.uni-kiel.de>

I have some questions regarding the future of Numpy.

Will the numerical extension become a huge package, or is it better to
build some more packages, wich need the numerical extension.

Is it always better, to take some routines in languages like Fortran
or C and build a python-extension, or should the routines build in
python. I think the last way is not so efficent but more flexibel and
the enduser can change some things directly in the code. This is not
so easy, if you have a mix of python and (C,Fortran).

How is Numpy mainly used? Allways as a programing language for large
scripts, or as tool to apply functions (or methods) to some data
arrays interactiv and to plot the results. (For me this is one
favorite point in using Numpy at the moment) 

Is it possible to use OOP generaly? The longer I think about my own
little and special problems, the more possibilities I encounter. Each
view of the problem is very different. Perhaps I don't have the right
view at the moment :-).

How should the many evolving packages be documented? Are there any
plans to build a help system, perhaps something like the one in the
gist-extension? 

At the moment I describe for myself the Numpy-system with:
"A simple to use OOP-scripting language with an extension like Matlab
but more powerful, because of the higher dimensionality, for example
and with the great advantage to extent it in every direction." (...more
hype in my thoughts)

But is this "Matlab-like"-approach the right view. I'm not sure.

What are the views of the other people in this mailing list?

Ok, enough, hopefully not too boring. He, it's sunday evening!!

__Janko

=================
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  Sun Oct 20 20:30:32 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Sun, 20 Oct 1996 15:30:32 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Where to go (was Numerical Recipes)
In-Reply-To: <9610201859.AA14694@caesar.ifm.uni-kiel.de> from "janko hauser" at Oct 20, 96 08:59:46 pm
Message-ID: <199610201930.PAA11168@maigret>

> I have some questions regarding the future of Numpy.

Indeed, quite a few.  I'm sure lots of people on this list have
different views.  Here's mine.

The Numeric module is what I think of as part of a necessary
infrastructure for building tools for use by scientists and engineers.
It is something without which Python is almost useless in this regard.
I'm eternally grateful to Jim H. (and Jim F. before him) for this great
tool.  But it's just the beginning.

> Will the numerical extension become a huge package, or is it better to
> build some more packages, wich need the numerical extension.

Numeric as a module will not grow very much, I don't think.  What will
grow is the list of modules like LinearAlgebra, FFT, RandomArray, which
all depend on arrays and ufuncs.  
 
> Is it always better, to take some routines in languages like Fortran
> or C and build a python-extension, or should the routines build in
> python. I think the last way is not so efficent but more flexibel and
> the enduser can change some things directly in the code. This is not
> so easy, if you have a mix of python and (C,Fortran).

In an ideal world, I think that writing things from scratch using the
functionality offered by arrays and ufuncs is the "right" thing to do.
The problem with that is that writing good numerical routines is an art.
Also, getting a numerical routine right takes time.  This is why I was
arguing (and I think that Paul and Konrad agree with me) that by putting
well thought-out OO wrappers around "traditional" routines, one gets the
robustness of existing tools and the friendly face (etc.) of a
class-based interface.

> How should the many evolving packages be documented? Are there any
> plans to build a help system, perhaps something like the one in the
> gist-extension? 

Good question.  I've been spending way too much of my weekend updating
the tutorial for release 1.0. It covers the "standard release", meaning
that it includes LinearAlgebra, FFT, etc.  I've switched from writing
straight HTML (yuck) to writing in TIM, Bill Janssen's TexInfo
superset (which is part of the ILU distribution, but is also available
separately).  So far, I'm quite happy with the results.  The TeX output
looks pretty good, the HTML is quite reasonable, and the plain text and
info-file outputs are nice.  The only missing output formats are one
for the Mac and one for Windows.  I suspect the latter is easier than
the former.  I might even give it a try when I have free time (ha!).

The reason why I like the 'info' format is that I've already written a
tool which allows navigation of info-files from a unix python shell.  If
anyone is interested, ask me about it (it's on my website as well).  It
allows keyword searching, so that one could do:

	>>> from ihelp import *   # that's my module's name
	>>> help('choose')        # --> will bring up the info
				  #     viewer and point at the
                                  #     'choose()' node.

 
I think the same type of help interface could pop up the Windows
helpfile viewer, or the Xinfo viewer if that's what it's configured to
do.

I think that this is a more powerful mechanism than the gist helpfile
system, which seemed to me to be less hierarchical.  I could be wrong.

Clearly this would make most sense if all Python docs were available in
a TIM-like format.  Maybe it's time to ask the DOC-SIG what's up.  The
Reference manual has been converted to FrameMaker, which might actually
allow conversion to SGML and from there TIM?  The other manuals were
last I checked available in info format (in fact it's with the library
reference in mind that I wrote the `ihelp' module, when some users were
complaining that Python had lousy help facilities compared to
matlab...).

--david

PS: I'll try and have a draft of the tutorial available (in its many
    formats =) for review in a few days.  

=================
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 Oct 21 10:02:39 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 21 Oct 96 10:02:39 +0100
Subject: [PYTHON MATRIX-SIG] Where to go (was Numerical Recipes)
In-Reply-To: <9610201859.AA14694@caesar.ifm.uni-kiel.de> (message from janko
 hauser on Sun, 20 Oct 1996 20:59:46 +0200)
Message-ID: <199610210908.KAA27309@ibs.ibs.fr>

> Will the numerical extension become a huge package, or is it better to
> build some more packages, wich need the numerical extension.

The already existing add-ons (linear algebra, FFT etc.) point in the
second direction, and I can't see any reason not to proceed in that
way.

> Is it always better, to take some routines in languages like Fortran
> or C and build a python-extension, or should the routines build in
> python. I think the last way is not so efficent but more flexibel and

Ideally, one would start designing a Python interface, write as much
as possible in Python, and resort to C when efficiency demands it.  In
practice, I expect the use of existing C/Fortran/whatever code to be
so attractive that people will prefer to design Python wrappers around
them instead of starting from scratch. I just hope they'll do it
right.

> How is Numpy mainly used? Allways as a programing language for large
> scripts, or as tool to apply functions (or methods) to some data
> arrays interactiv and to plot the results. (For me this is one

I have done both and intend to continue. My applications of NumPy range
from throw-away scripts (reading an array and interpolating from it or
things like that) to a large (4000 lines and constantly growing) package
for molecular modelling.

> Is it possible to use OOP generaly? The longer I think about my own

I've found an OO approach to be the best solution to any problem that
exceeds the throw-away script level. And with Python it's so easy and
quick to define classes that there is no excuse for not doing so!

> How should the many evolving packages be documented? Are there any
> plans to build a help system, perhaps something like the one in the
> gist-extension? 

Good point. I try to put doc strings (at least at the module level) into
all my code, in the hope that some day someone will produce a nice
help browser using them. For large packages, some additional documentation
will be necessary. Unfortunately the current proliferation of popular
text formats (HTML, TeX, GNU-info, plain ASCII) creates a lot of chaos...

> But is this "Matlab-like"-approach the right view. I'm not sure.

If it works for you, then it is. There is no point in forcing a
single view on everyone. As long as we are all happy with NumPy,
we can afford to have different views...

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From sean@embl-grenoble.fr  Mon Oct 21 11:20:41 1996
From: sean@embl-grenoble.fr (Sean McSweeney)
Date: Mon, 21 Oct 1996 12:20:41 +0200
Subject: [PYTHON MATRIX-SIG] IMSL bindings
In-Reply-To: <3267E454.2635@digicool.com>
References: <199610181817.OAA07129@maigret>
 <3267E454.2635@digicool.com>
Message-ID: <199610211020.MAA12061@classic.embl-grenoble.fr>

Jim Fulton writes:

 > 
 > Note that the above example is for an IMSL routine.
 > FIDL has been in a beta testing state for some time because
 > I haven't been able to get any beta testers to actually
 > test it, or at least to let me know how it works.  
 > If you are interested in *really* being a beta tester, 
 > let me know and I'll point you at the current version.
 > 

Okay I'll bite, I want/need to interface to a large number of fortran
routines so I would be willing to try to use fidl to do this, and let
you know the problems.

 > Note that fidl uses a precursor to NumPy arrays.  It should 
 > work with NumPy with a little extra copying.  I'm planning
 > to integrate NumPy with FIDL, but it hasn't been a high 
 > priority since I changed jobs and no longer need fidl myself.

It would be very useful to use the speed of the NumPy stuff with the
project am attempting to start. Would it be lots of work to
interface to the NumPy array types ? 

cheers

Sean

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From friedric@rose.rsoc.rockwell.com  Mon Oct 21 15:41:20 1996
From: friedric@rose.rsoc.rockwell.com (Robin Friedrich)
Date: Mon, 21 Oct 1996 09:41:20 -0500
Subject: [PYTHON MATRIX-SIG] Where to go (was Numerical Recipes)
Message-ID: <199610211441.JAA00648@darwin.rsoc.rockwell.com>

|> From: da@maigret.cog.brown.edu (David Ascher)
|> Subject: Re: [PYTHON MATRIX-SIG] Where to go (was Numerical Recipes)
|> To: jhauser@ifm.uni-kiel.de (janko hauser)
|> Date: Sun, 20 Oct 1996 15:30:32 -0400 (EDT)
|>  
|> Clearly this would make most sense if all Python docs were available in
|> a TIM-like format.  Maybe it's time to ask the DOC-SIG what's up.  The
|> Reference manual has been converted to FrameMaker, which might actually
|> allow conversion to SGML and from there TIM?  The other manuals were
|> last I checked available in info format (in fact it's with the library
|> reference in mind that I wrote the `ihelp' module, when some users were
|> complaining that Python had lousy help facilities compared to
|> matlab...).
|> 
|> --david
|> 

It should be made clear that the Language Reference and Tutorial
are the only docs converted to FrameMaker. The Lib Ref is still
up in the air as to format. The last view I heard was that it should
be written in a very easy system that's text-based and assembled
into it's entirety with some higher level tools. TIM looks to be the
odds on favorite here but there needs to be a whole lot more 
concurrence among module writers. The structured text standard
for doc strings needs to be considered and incorporated as well.
A TIM formatter for gendoc is an obvious approach.

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Mon Oct 21 20:53:06 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Mon, 21 Oct 1996 15:53:06 -0400
Subject: [PYTHON MATRIX-SIG] Re: NumPy in Python 1.4
References: <b9budw5fe1.fsf@laura.llnl.gov>
Message-ID: <326BD4A2.1CFB@maigret.cog.brown.edu>

Geoffrey Furnish wrote:
> 
> I am working with Numerical Python extension 1.0a2 in a Python 1.4b3
> context.  Lots of code I wrote previously under Python 1.3 and
> whatever version of NumPy it was that went wtih that, is now broken.

Yes, we know.  It's because of the pesky little 'a' in 1.0a2 -- it is an
alpha release, and we've been discussing just these issues on the
matrix-sig for months.

> I have been in the habit of instantiating my arrays with the "zeros"
> thing.  I used to say, for example:
> 
> x = zeros(100)
> 
> to get an array of 100 zero's.  Well, in the new version, this still
> gives 100 zero's, but ...  now they're integers, they used to be
> doubles.  This change in the type returned by this function broke
> skads of code.  I have had to change this to:
> 
> x = zeros(100,'d')
> 
> which I can live with, but I /much/ prefered the prior behavior.  IMO,
> if you're gonna have a "default" number type, it should be float, not
> int.  Converting to requiring the type specifier puts them on equal
> footing, but I like the defaultability--if it defaults to double, not
> int.

The reasoning (as I recall it) was that in all other methods, the array
type created corresponds to the smallest type which can represent all of
the elements.  Since 0 and 1 can be represented accurately as integers,
that's what zeros() and ones() returns.

Note that the recommended typecodes are now Int, Float, etc.:

	x = zeros(100, Float)

> Secondly, instantiating 2-d arrays has changed.  I used to be able to
> do:
> 
>     z = zeros(XPTS,YPTS)
> 
> Now I have to do:
> 
>     z = reshape( zeros( XPTS*YPTS, 'd' ), (XPTS, YPTS) )
> 
> Curiously, the obvious:
> 
>     z = zeros( (XPTS,YPTS), 'd' )
> 
> did not work on my Linux box, forcing me to use the reshape business
> exhibited above.  I could not reproduce the same failure on my HP/UX
> box at work this morning, even though the same versions of Python and
> NumPy are involved.

	>>> zeros((4,4), Float)
	 0.  0.  0.  0.
	 0.  0.  0.  0.
	 0.  0.  0.  0.
	 0.  0.  0.  0.

This works at least on my machines with the latest alpha release.  If
you could try this with the 1.0a5 release and let us know the results,
that'd be great.

> Finally, I used to be able to do:
> 
>     zmin = min(zz.reshape())
>     zmax = max(zz.reshape())
> 
> where zz was a 2-d array, but that syntax isn't accepted now, and so
> I've been driven to:
> 
>     zmin = min(min(zz))
>     zmax = max(max(zz))
> 
> Again, I prefered the former.  What I would most like is for min(x)
> applied to an N-d x, to return the single minimum value, not just an
> N-1-d set of minimum values.  Similarly for other reduction operations
> like max.

I don't have an argument as to why this was chosen over the old version,
but note that you can do:

	zmin = min(ravel(zz))

I am in the process of updating the tutorial to NumPy to document these
changes from the early alpha releases.  

I for one am sorry that you seem frustrated with NumPy in some respects
-- it is however inevitable when dealing with an alpha release -- they
are released just to iron out what the best interface is.  I'd recommend
that you check out the 1.0a5 release
(http://www.sls.lcs.mit.edu/~jjh/numpy) and make comments before it goes
beta (and the interface is frozen).

--david ascher [just a documenter, not the author]

=================
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  Mon Oct 21 21:13:21 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Mon, 21 Oct 1996 13:13:21 -0700
Subject: [PYTHON MATRIX-SIG] Re: NumPy in Python 1.4
In-Reply-To: <326BD4A2.1CFB@maigret.cog.brown.edu>
References: <b9budw5fe1.fsf@laura.llnl.gov>
 <326BD4A2.1CFB@maigret.cog.brown.edu>
Message-ID: <199610212015.QAA13546@python.org>

Thanks for the comments.

David Ascher writes:
 > 	>>> zeros((4,4), Float)
 > 	 0.  0.  0.  0.
 > 	 0.  0.  0.  0.
 > 	 0.  0.  0.  0.
 > 	 0.  0.  0.  0.
 > 
 > This works at least on my machines with the latest alpha release.  If
 > you could try this with the 1.0a5 release and let us know the results,
 > that'd be great.

Yes, well, it wouldn't fail when typed in this way.  It had to be
inside a function.  Shouldda brought an actual clipping in with me
today, but I forgot.  Anyway, I'll try the new release of NumPy.

 > I don't have an argument as to why this was chosen over the old version,
 > but note that you can do:
 > 
 > 	zmin = min(ravel(zz))
 > 
 > I am in the process of updating the tutorial to NumPy to document these
 > changes from the early alpha releases.  

More documentation on NumPy would be most desirable.  Also, I find the
distribution format of the 1.0a2 to be more difficult to work with
than the ones that were for 1.3.  It was easier to use when it was
distributed as a direct patch to the main Python source tree.  I say
this b/c the (maybe just my) goal is to add the numerical extension to
the Python I am using for general system use, not merely to build a
new python with the numerical extension.

 > I for one am sorry that you seem frustrated with NumPy in some respects
 > -- it is however inevitable when dealing with an alpha release -- they
 > are released just to iron out what the best interface is.  I'd recommend
 > that you check out the 1.0a5 release
 > (http://www.sls.lcs.mit.edu/~jjh/numpy) and make comments before it goes
 > beta (and the interface is frozen).

I understand.  OTOH, when a package is in "alpha" for extremely long
periods of time, people are driven to just use it as is, since waiting
is not practical for all users, if the wait will be measured in
months.  I know--I am the author of a package which has been in
"alpha" distribution status for 3+ years.  :-).  Drives even the most
stability conscious of would-be users into alpha testers.

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

=================
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 Oct 21 22:11:53 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 21 Oct 1996 17:11:53 -0400
Subject: [PYTHON MATRIX-SIG] Re: NumPy in Python 1.4
Message-ID: <9610212117.AA01720@goldilocks.LCS.MIT.EDU>


>  > I don't have an argument as to why this was chosen over the old
version,
>  > but note that you can do:
>  > 
>  > 	zmin = min(ravel(zz))
>  > 
>  > I am in the process of updating the tutorial to NumPy to document
these
>  > changes from the early alpha releases.  

The last time I checked, there was no min function that works as you're
requesting.  the following will work: minimum.reduce(zz.flat).  The problem
here is that min is a builtin python function with a different meaning from
the expected one for arrays.

Notice that while reshape is no longer a method on array objects, but
rather a function, a new data member has been added called flat which will
give a 1d flat indexed version of any array.

> More documentation on NumPy would be most desirable.  Also, I find the
> distribution format of the 1.0a2 to be more difficult to work with
> than the ones that were for 1.3.  It was easier to use when it was
> distributed as a direct patch to the main Python source tree.  I say
> this b/c the (maybe just my) goal is to add the numerical extension to
> the Python I am using for general system use, not merely to build a
> new python with the numerical extension.

There are two ways of building NumPy1.0a5.  One of those (and by far the
easiest) is directly in the Python source tree.  This should be as easy to
work with as the previous releases.

> I understand.  OTOH, when a package is in "alpha" for extremely long
> periods of time, people are driven to just use it as is, since waiting
> is not practical for all users, if the wait will be measured in
> months.  I know--I am the author of a package which has been in
> "alpha" distribution status for 3+ years.  :-).  Drives even the most
> stability conscious of would-be users into alpha testers.

Well, I don't mind "early adopters", but on the other hand, I make no
apologies for the fact that you will have to change skads of code when
switching to later versions.  I've probably had to change far more code
(and for each new revision) than any other users, so I'm a bit short on
sympathy here.

OTOH - The point of the current release is that it should be stable.  I'm
finally happy enough with how things work to be willing to worry about
minor issues like backwards compatibilty.

-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  Tue Oct 22 11:27:08 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 22 Oct 96 11:27:08 +0100
Subject: [PYTHON MATRIX-SIG] Re: NumPy in Python 1.4
In-Reply-To: <326BD4A2.1CFB@maigret.cog.brown.edu> (message from David Ascher
 on Mon, 21 Oct 1996 15:53:06 -0400)
Message-ID: <199610221033.LAA03120@ibs.ibs.fr>

> The reasoning (as I recall it) was that in all other methods, the array
> type created corresponds to the smallest type which can represent all of
> the elements.  Since 0 and 1 can be represented accurately as integers,
> that's what zeros() and ones() returns.

Exactly. Note also that ints will be coerced to floats if necessary, whereas
the opposite has to be done explicitly. The only reason to call zeros()
with a specific type is to create an array with "arbitrary" values that
are to be overwritten by element assignment.

> I don't have an argument as to why this was chosen over the old version,
> but note that you can do:
> 
> 	zmin = min(ravel(zz))

Still I would recommend minimum.reduce(ravel(zz)). min() will work in
this special case, but can cause lots of unpleasant surprises in other
circumstances. For example, min(a,b), with a and b arrays, will return
a or b depending on which has the lower address in memory!

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Tue Oct 22 12:40:52 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 22 Oct 96 12:40:52 +0100
Subject: [PYTHON MATRIX-SIG] slice()
Message-ID: <199610221146.MAA03478@ibs.ibs.fr>

Does anyone know why the new slice() function insistis on getting at
least argument? I need the equivalent of a[::], which would most
obviously be obtained just by slice(). As it is, I have to use
slice(None), although end users are not supposed to know about the
special meaning of None in this context.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Tue Oct 22 12:54:47 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 22 Oct 96 12:54:47 +0100
Subject: [PYTHON MATRIX-SIG] Building index tuples
Message-ID: <199610221200.NAA03635@ibs.ibs.fr>

I like the new style of building up index tuples less and less.
The bits and pieces I need are:

1) The built-in function slice() that needs at least one argument
   and shares the strange feature of range() that the *first*
   argument is optional.
2) The special meaning of None as an argument to slice().
3) The object NewAxis, to be imported from Numeric.
4) The object Ellipses (soon to be Ellipsis), which is built-in in
   Python 1.4.

*I* don't want to explain all this to a new user (whom I just told how
terribly consistent Python is)!

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Tue Oct 22 15:04:51 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 22 Oct 1996 10:04:51 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Building index tuples
In-Reply-To: <199610221200.NAA03635@ibs.ibs.fr> from "Konrad Hinsen" at Oct 22, 96 12:54:47 pm
Message-ID: <199610221404.KAA16355@maigret>

> I like the new style of building up index tuples less and less.
> The bits and pieces I need are:
> 
> 1) The built-in function slice() that needs at least one argument
>    and shares the strange feature of range() that the *first*
>    argument is optional.
> 2) The special meaning of None as an argument to slice().
> 3) The object NewAxis, to be imported from Numeric.
> 4) The object Ellipses (soon to be Ellipsis), which is built-in in
>    Python 1.4.
> 
> *I* don't want to explain all this to a new user (whom I just told how
> terribly consistent Python is)!

I think you meant these are the bits and pieces you don't need, no?

Methinks the most elegant solution to your qualms is to have NewAxis
have the same privileged status as Ellipsis, i.e. a builtin type.  It's
hard to see why guido would let that happen purely on 'esthetic'
grounds.

An alternative is to do something like Numeric.Ellipses = Ellipses, that
way at least we can 'pretend' that Ellipsis is like NewAxis and part of
Numeric.  Is there a use for Ellipsis outside of Numeric?

This doesn't address the fact that NewAxis is None.  I agree that this
is confusing.

It doesn't address either the arrayrange(f=None,t,s=1,typecode=None)
oddity.  I've found that the uses of arrayrange I usually want are:

	arrayrange(10)
	arrayrange(10, typecode=Float)
	arrayrange(10, 20)   
	arrayrange(10, 20, typecode=Float)

which would be supported if arrayrange did kw recognition.  In fact I
wouldn't mind if

	arrayrange(10, Float)

was supported, but that violates the so-far consistent attitude towards
the fact that a function doesn't infer which argument is which by its
type.  IMHO, this is not necessarily a good thing, but I can see that
it's "different".

--david

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Tue Oct 22 16:26:49 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 22 Oct 96 16:26:49 +0100
Subject: [PYTHON MATRIX-SIG] Building index tuples
In-Reply-To: <199610221404.KAA16355@maigret> (da@maigret.cog.brown.edu)
Message-ID: <199610221556.QAA05331@ibs.ibs.fr>

> I think you meant these are the bits and pieces you don't need, no?

These are the bits and pieces I must use but don't like.

> Methinks the most elegant solution to your qualms is to have NewAxis
> have the same privileged status as Ellipsis, i.e. a builtin type.  It's
> hard to see why guido would let that happen purely on 'esthetic'
> grounds.

I agree.

> An alternative is to do something like Numeric.Ellipses = Ellipses, that
> way at least we can 'pretend' that Ellipsis is like NewAxis and part of
> Numeric.  Is there a use for Ellipsis outside of Numeric?

Not as yet, but there might be. But then the same would be valid for
NewAxis. The only difference is that, for historical reasons, NewAxis
is None and Ellipsis is a special object. I don't really care about
that, but don't like that every user has to know these implementation
details. Setting Numeric.Ellipsis = Ellipsis would already be
a step toward unification. But then we should do the same with slice().
That leaves the weird interpretation of arguments by slice() as a problem.
At first sight making it compatible with range() seems clever, but
in reality it is never used like range(). In particular, range() always
needs an upper bound, whereas slice() doesn't. The syntax of slice()
should mirror as closely as possible the syntax of slice indexing, not
the syntax of range().

I suppose that I'll end up reintroducing my index_expression code; I
can just make a new module for that. It has the enormous advantage
that you don't have to know anything about the implementation details
of multidimensional indexing, except that index expressions are
sequences.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From furnish@laura.llnl.gov  Tue Oct 22 19:08:24 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Tue, 22 Oct 1996 11:08:24 -0700
Subject: [PYTHON MATRIX-SIG] Re: NumPy in Python 1.4
In-Reply-To: <9610212117.AA01720@goldilocks.LCS.MIT.EDU>
References: <9610212117.AA01720@goldilocks.LCS.MIT.EDU>
Message-ID: <199610221810.OAA17019@python.org>

Jim Hugunin writes:
 > There are two ways of building NumPy1.0a5.  One of those (and by
 > far the easiest) is directly in the Python source tree.  This
 > should be as easy to work with as the previous releases.

Thanks, yes, this is better than how it was with 1.0a2.  However, I
have found several defficiencies in the INSTALL instructions, which
should be corrected to spare people some grief.

1) Makefile.in (in top level), needs to have Numeric added to the list
   of things to install.  Search for "tkinter", add Numeric next to
   it. 

2) Setup needs more than what is shown.  It is also extremely helpful
   to add something like NUMPYPATH to the search path, as is done for
   TKPATH. 

3) The headers also need to be installed.  Softlinking them directly
   into Include should do it.

And as a relatively minor point,

4) The files still have wacky permission bits.  The x bit is on all
   over the place, for instance.  Although this is not "wrong", it is
   certainly worth fixing.

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

=================
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 Oct 22 19:19:50 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 22 Oct 1996 14:19:50 -0400
Subject: [PYTHON MATRIX-SIG] Re: NumPy in Python 1.4
Message-ID: <9610221825.AA16200@goldilocks.LCS.MIT.EDU>

> 1) Makefile.in (in top level), needs to have Numeric added to the list
>    of things to install.  Search for "tkinter", add Numeric next to
>    it. 

Did you make the symbolic link from Numeric into the Lib directory?  I
think that this should fix the problem, but if it doesn't I'll add the note
(and a patched version of Makefile.in).

> 2) Setup needs more than what is shown.  It is also extremely helpful
>    to add something like NUMPYPATH to the search path, as is done for
>    TKPATH. 

I agree the path is needed, anything else?

> 3) The headers also need to be installed.  Softlinking them directly
>    into Include should do it.

I usually just directly add NumPy to my include directories, I need to
think about this one.

> And as a relatively minor point,
> 
> 4) The files still have wacky permission bits.  The x bit is on all
>    over the place, for instance.  Although this is not "wrong", it is
>    certainly worth fixing.

When you're building a system on both Solaris and Windows NT, strange
things can happen to your files.  Just be glad that this time I remembered
to strip the "^M"'s from the Unix distribution.  ;-)

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Tue Oct 22 21:25:59 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Tue, 22 Oct 1996 15:25:59 -0500
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
In-Reply-To: <9610182239.AA25672@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610222021.QAA17378@python.org>



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

<...>

>This is also your last chance to make any major design changes to the
>system.  If there's something about how NumPy works that you really don't
>like, speak up now while I'm still willing to sacrifice backward
>compatibility.  I have a farily extensive set of tools built using this
>stuff (as I'm sure others do) and I don't want to rebuild it all ever again
>;-)

I was thinking about comparison operators (<, ==, etc) today and I had
a question. I understand that there is no good way for <, >, etc to
work on matrices because you have to return and integer value. And,
apparently, there is no way to raise an exception here
either. However, it seems like A == B, and A != B are perfectly valid
matrix expressions that should evaluate to true and false respectively
if A and B are the same shape and have equal values. In other words, 
A == B <=> A.shape == B.shape and and.reduce(equal(ravel(A), ravel(B))).

Yes? No?

<...>

-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Tue Oct 22 22:21:42 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 22 Oct 1996 17:21:42 -0400
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
Message-ID: <9610222118.AA18131@goldilocks.LCS.MIT.EDU>


> I was thinking about comparison operators (<, ==, etc) today and I had
> a question. I understand that there is no good way for <, >, etc to
> work on matrices because you have to return and integer value. And,
> apparently, there is no way to raise an exception here
> either. However, it seems like A == B, and A != B are perfectly valid
> matrix expressions that should evaluate to true and false respectively
> if A and B are the same shape and have equal values. In other words, 
> A == B <=> A.shape == B.shape and and.reduce(equal(ravel(A), ravel(B))).
> 
> Yes? No?

I just had to explain to someone yesterday how to determine if A == B, and
let me tell you it wasn't pleasant.  I'll add this in before the beta
release, as it's better than the current approach.  I'm a little
uncomfortable that I might be giving sanction to this sort of equality
comparision for arrays of floats, but since it's allowed for python floats
I probably shouldn't worry.

BTW - There's going to be at least one more alpha release coming out fairly
soon in order to be compatible with the new name for Ellipsis in
Python1.4Final.  It'll also probably have small changes like this one in
it.  Nothing that'll break user code though.  Unless you depend on the
current behavior of "a == b" always being false, in which case your code is
already broken ;-)

-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  Wed Oct 23 02:43:17 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 22 Oct 1996 21:43:17 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Alpha release of new tutorial for 1.0a5
Message-ID: <199610230143.VAA20782@maigret>


I'm putting up an alpha version of the tutorial for people to get both
some documentation (some is better than none, assuming it's mostly
correct) and a chance to give me some feedback before the beta
release.  It's far from finished, but I suspect it'd be helpful even
now to many readers of matrix-sig (and even more to non-readers of
matrix-sig!).

I have to get back to work (real work, I mean), so I'm going to stop
for a little while.  I will find the time to fix mistakes and
incorporate new ideas which are pointed out to me (it's the original
thinking which I don't have the time for).  Specifically, I know that
I need good tutorial descriptions and examples for the uses of:

	compress()
	sort()
	argsort()
	binarysearch()
	indices()
	matrixmultiply()

and everywhere else there are XXX's.  I'd take replacement examples
for all the others, if they have good didactic value.

Oh, and the LinearAlgebra and Matrix packages are almost not
documented (I couldn't remember what a generalized inverse or SVD
was... shame on me).  A good example of the linear least squares fit
would be nice too.  

Anyway, it's at 

	http://maigret.cog.brown.edu/Python/Extensions/Numeric

And there are HTML, DVI, TeX, Info, Text and PS versions (TIM is
pretty cool really!).

--david

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Wed Oct 23 03:39:01 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 22 Oct 1996 22:39:01 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Alpha release of new tutorial for 1.0a5
In-Reply-To: <199610230227.TAA01304@coot.geog.ubc.ca> from "Phil Austin" at Oct 22, 96 07:27:50 pm
Message-ID: <199610230240.WAA21033@maigret>

> An initial problem trying to retrieve array.ps:
> 
> <HEAD><TITLE>File Not found</TITLE></HEAD>
> <BODY><H1>File Not found</H1>
> The requested URL /Python/Extensions/Numeric/array.ps was not found on this server.<P>
> </BODY>

Fixed.  Bug in my makefile. 

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Wed Oct 23 10:13:11 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 23 Oct 96 10:13:11 +0100
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
In-Reply-To: <199610222021.QAA17378@python.org> (tim@lassi.ece.uiuc.edu)
Message-ID: <199610230918.KAA08295@ibs.ibs.fr>

> either. However, it seems like A == B, and A != B are perfectly valid
> matrix expressions that should evaluate to true and false respectively
> if A and B are the same shape and have equal values. In other words, 
> A == B <=> A.shape == B.shape and and.reduce(equal(ravel(A), ravel(B))).
> 
> Yes? No?

If you ask me, yes! And of course it is possible. Here is the
definition of __cmp__ of my tensor class, which is basically
a wrapper around a special kind of array:

    def __cmp__(self, other):
	if self.rank != other.rank:
	    return 1
	else:
	    return not umath.logical_and.reduce(
		umath.equal(self.array, other.array).flat)

In this case, self.rank completely specifies shape, so it doesn't have
to be compared separately.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Wed Oct 23 14:27:43 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 23 Oct 96 14:27:43 +0100
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
Message-ID: <199610231333.OAA09920@ibs.ibs.fr>

Reading David's excellent tutorial has made me aware of a few
peculiarities that I had forgotten, and which should be cleaned
up before the beta release:

1) where() is just a special case of choose() and should be
   eliminated.

2) compress() is just a special case of repeat() and should be
   eliminated.

3) binarysearch() should be called just search(), or find().
   The name of a function should not indicate the algorithm
   that is uses, however obvious the choice of the algorithm
   is.

4) I am a bit confused about the exact meaning of the parameters
   to diagonal() and trace(). Shouldn't that simply be to integers,
   indicating the two axes along which the diagonal is constructed,
   and defaulting to -2 and -1?

5) There's dot() and matrixmultiply(). Dot() does something for which
   I have never found a direct need, and which anyway should not be
   called dot() because it doesn't work like what linear algebra
   users expect dot() to mean. How about having just dot() with a
   useful generalization of the dot product, i.e. summing along
   the last axis of the first and the first axis of the second argument?
   (I think we have discussed this before, but I don't remember details...)

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From fredrik_lundh@ivab.se  Wed Oct 23 14:23:43 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Wed, 23 Oct 1996 15:23:43 +0200
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <199610231333.OAA09920@ibs.ibs.fr> (message from Konrad Hinsen on
 Wed, 23 Oct 96 14:27:43 +0100)
Message-ID: <9610231323.AA06667@arnold.image.ivab.se>


> binarysearch() should be called just search(), or find().
> The name of a function should not indicate the algorithm
> that is uses, however obvious the choice of the algorithm
> is.

To me, "binarysearch" implies that data must be sorted beforehand,
while a "search" function wouldn't bother about such issues (compare
bsearch and lsearch in the standard C library).

Maybe a better name, but not as generic as "search".

	/F (just an ordinary programmer)

=================
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 Oct 23 19:07:19 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 23 Oct 1996 14:07:19 -0400
Subject: [PYTHON MATRIX-SIG] Problems building alpha5 (Linux)
Message-ID: <9610231812.AA03290@goldilocks.LCS.MIT.EDU>

> From: Oliver Gathmann <gathmann@scar.utoronto.ca>
> 
> I have trouble with your last Friday release (alpha5): On my Linux box,
> (Linux 2.0, gcc 2.7.0) I keep getting "unresolved symbol" errors when
> trying to import math,cmath,time,regex and other standard Python modules
-
> which I didn't get before. Linking against the math library helps for
math
> and cmath, but not for the other modules. Do you have an idea what's
wrong
> there?

Anybody else recognize this problem (particularly all of you out there
who've buit alpha5 under linux?)  I can't really imagine what's going wrong
here.

-Jim


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Wed Oct 23 18:57:06 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 23 Oct 1996 13:57:06 -0400
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
Message-ID: <9610231811.AA03260@goldilocks.LCS.MIT.EDU>


> Reading David's excellent tutorial has made me aware of a few
> peculiarities that I had forgotten, and which should be cleaned
> up before the beta release:
> 
> 1) where() is just a special case of choose() and should be
>    eliminated.

I find that almost everybody I've explained it to understands the where
function.  For some reason the increased generality of choose is confusing
to many people.  So I plan on leaving the where function in.  It serves the
same purpose as sum == add.reduce and similar convenient abbreviations.

I do see the value in making the seperation a little bit mnore clear in the
tutorial between core functions and convenience functions.  If you look at
my own docs you'll see that I went out of my way to make this point.

> 2) compress() is just a special case of repeat() and should be
>    eliminated.

Similarly for compress, the main addition is that it makes sure the
arguments are either zero or one before doing the repeat operation and this
is just a lot easier for some people to understand.

> 3) binarysearch() should be called just search(), or find().
>    The name of a function should not indicate the algorithm
>    that is uses, however obvious the choice of the algorithm
>    is.

Frederick's point that this function name helps to make it clear to people
that this function requires a sorted array is my original reasoning.  I've
always been a little bit concerned that this function can be easily misused
by naive users and there's no efficient way to detect an error if it's used
on an unsorted array.  So, the very specific name I think is helpful here.

> 4) I am a bit confused about the exact meaning of the parameters
>    to diagonal() and trace(). Shouldn't that simply be to integers,
>    indicating the two axes along which the diagonal is constructed,
>    and defaulting to -2 and -1?

I think you're right about this one.  If you were to give me a better
implementation of diagonal that works as you describe I'd be happy to use
it.  (Although I do think that the proper choice of arguments for the nd
case is a tuple of two OR MORE integers specifying the axes along which to
take the diagonal).

> 5) There's dot() and matrixmultiply(). Dot() does something for which
>    I have never found a direct need, and which anyway should not be
>    called dot() because it doesn't work like what linear algebra
>    users expect dot() to mean. How about having just dot() with a
>    useful generalization of the dot product, i.e. summing along
>    the last axis of the first and the first axis of the second argument?
>    (I think we have discussed this before, but I don't remember
details...)

In case you haven't noticed as we've worked on this for the past year, for
some reason I really dislike any generalizations I've seen of the
innerproduct.  This is the basic reason why the is no "inner" method on
ufuncs.  I'm personally quite happy with how things are currently defined
now, and for all of my matrixmultiply-like tasks, I find dot is the way I
think about the world.

On the other hand I understand your complaints.  I'll think about this one
(yet again), any other comments on this issue would be appreciated.

-Jim

PS - I somehow doubt that these are truly your last complaints, not that
I'd want it any other way ;-)


=================
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 Oct 23 19:08:47 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 23 Oct 1996 14:08:47 -0400
Subject: [PYTHON MATRIX-SIG] Change eigenvectors to eigensystems?
Message-ID: <9610231814.AA03304@goldilocks.LCS.MIT.EDU>


> From: Alistair Mees <alistair@maths.uwa.edu.au>
> To: hugunin@MIT.EDU
> Subject: numpy -- suggest changing "eigenvectors" to "eigensystem"
> Date: Tuesday, October 22, 1996 9:28 PM
> 
> 
> Jim:
> 
> A minor naming point -- since "eigenvectors" returns the eigenvalues as
> well, would it perhaps be less confusing to rename it to "eigensystem"?
> 
> Alistair

This sounds reasonable to me, but I thought I should ask for objections
from other users of LinearAlgebra.py before I go around changing naming
conventions again.

-Jim

PS - This sort of suggestion generally belongs on the SIG for public
comment.  Do keep sending those bug reports to me directly though ;-)



=================
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 Oct 23 19:26:20 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 23 Oct 1996 14:26:20 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Problems building alpha5 (Linux)
In-Reply-To: <9610231812.AA03290@goldilocks.LCS.MIT.EDU> from "Jim Hugunin" at Oct 23, 96 02:07:19 pm
Message-ID: <199610231826.OAA23391@maigret>

> > From: Oliver Gathmann <gathmann@scar.utoronto.ca>
> > 
> > I have trouble with your last Friday release (alpha5): On my Linux box,
> > (Linux 2.0, gcc 2.7.0) I keep getting "unresolved symbol" errors when
> > trying to import math,cmath,time,regex and other standard Python modules
> -
> > which I didn't get before. Linking against the math library helps for
> math
> > and cmath, but not for the other modules. Do you have an idea what's
> wrong
> > there?
> 
> Anybody else recognize this problem (particularly all of you out there
> who've buit alpha5 under linux?)  I can't really imagine what's going wrong
> here.

No, I had no problems.  Was it a static build or a dynamic build?  

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Wed Oct 23 19:28:17 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 23 Oct 1996 14:28:17 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <9610231811.AA03260@goldilocks.LCS.MIT.EDU> from "Jim Hugunin" at Oct 23, 96 01:57:06 pm
Message-ID: <199610231828.OAA23403@maigret>

> I do see the value in making the seperation a little bit mnore clear in the
> tutorial between core functions and convenience functions.  If you look at
> my own docs you'll see that I went out of my way to make this point.

Will gladly oblige.
 
> > 3) binarysearch() should be called just search(), or find().
> >    The name of a function should not indicate the algorithm
> >    that is uses, however obvious the choice of the algorithm
> >    is.
> 
> Frederick's point that this function name helps to make it clear to people
> that this function requires a sorted array is my original reasoning.  I've
> always been a little bit concerned that this function can be easily misused
> by naive users and there's no efficient way to detect an error if it's used
> on an unsorted array.  So, the very specific name I think is helpful here.

I appreciate the reasoning, but the name seems confusing.  How about 

	searchsorted()

to be even more explicit.

--david 

=================
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  Wed Oct 23 20:19:12 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Wed, 23 Oct 1996 12:19:12 -0700
Subject: [PYTHON MATRIX-SIG] Problems building alpha5 (Linux)
In-Reply-To: <9610231812.AA03290@goldilocks.LCS.MIT.EDU>
References: <9610231812.AA03290@goldilocks.LCS.MIT.EDU>
Message-ID: <199610231921.PAA20563@python.org>

Jim Hugunin writes:
 > > From: Oliver Gathmann <gathmann@scar.utoronto.ca>
 > > 
 > > I have trouble with your last Friday release (alpha5): On my Linux box,
 > > (Linux 2.0, gcc 2.7.0) I keep getting "unresolved symbol" errors when
 > > trying to import math,cmath,time,regex and other standard Python modules
 > -
 > > which I didn't get before. Linking against the math library helps for
 > math
 > > and cmath, but not for the other modules. Do you have an idea what's
 > wrong
 > > there?
 > 
 > Anybody else recognize this problem (particularly all of you out there
 > who've buit alpha5 under linux?)  I can't really imagine what's going wrong
 > here.

I built alpha5 on linux two nights ago without difficulty.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From drh@cse.unl.edu  Wed Oct 23 20:43:41 1996
From: drh@cse.unl.edu (Doug Heisterkamp)
Date: Wed, 23 Oct 1996 14:43:41 -0500 (CDT)
Subject: [PYTHON MATRIX-SIG] IMSL bindings
In-Reply-To: <199610181817.OAA07129@maigret> from "David Ascher" at Oct 18, 96 02:17:43 pm
Message-ID: <199610231943.OAA17336@cse.unl.edu>

> 
> It would make some people here very happy if there were Python
> bindings to the IMSL Fortran libraries (and C, but they're less
> complete).
> 
> Have people come up with tools which make binding to Fortran
> libraries relatively automatic?  IMSL is fairly big.
> 
> --david
> 

Hi,

The low level access to the LAPACK library is generate automatically.
Unfortunately, it is not a general tool.  It was written to process
the CLapack version of the Lapack library.  It should work with most
fortran libraries after the code has been processed with f2c as long
as some of the conventions in CLapack are used.

The converter has a number of limitations.  The main one is due to using
the C code function heading, such as, it can not tell the difference 
between a double and an array of doubles.  Assumptions are made in these 
cases and an exception dictionary is maintained for when the assumptions
are wrong.  

If I were to write a second version of this tool, I would use kjParser.py
and have it read the fortran source code.  In addition, outputting the FIDL
description may be desirable (I have not seen or used FIDL, but it sounds
interesting).  The original version started out as a grep of the function
headings and grew into the mess it is from there.

If you wish to try to use the converter on the IMSL libraries, you are
welcomed to use it.  Though I think you could write you own parser from
scratch faster then understanding and modifying the converter if it does
not work.  I'm planning on building a low level access module to ODRPACK.  
When I do this, I may modify the converter enough so that it can be used
on a wider set of fortran libraries.

Doug Heisterkamp
drh@cse.unl.edu

=================
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 Oct 23 21:01:19 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 23 Oct 1996 16:01:19 -0400
Subject: [PYTHON MATRIX-SIG] [Fwd: ANNOUNCE: perlDL v1.00 - the 'perl Data Language']
Message-ID: <326E798F.41C6@maigret.cog.brown.edu>

Path: cocoa.brown.edu!cam-news-feed1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!nntp-hub2.barrnet.net!news.sprintlink.net!news-peer.sprintlink.net!howland.erols.net!feed1.news.erols.com!uunet!in3.uu.net!crusty.teleport.com!nntp0.teleport.com!usenet
From: kgb@jach.hawaii.edu (Karl Glazebrook)
Newsgroups: comp.lang.perl.announce,comp.lang.perl.misc
Subject: ANNOUNCE: perlDL v1.00 - the 'perl Data Language'
Followup-To: comp.lang.perl.misc
Date: 23 Oct 1996 16:26:29 GMT
Organization: UK/Canada/Netherlands Joint Astronomy Centre, Hilo, Hawaii
Approved: merlyn@stonehenge.com (comp.lang.perl.announce)
Message-ID: <54lgvl$bqc@nadine.teleport.com>
NNTP-Posting-Host: gadget.cscaper.com
X-Disclaimer: The "Approved" header verifies header information for article transmission and does not imply approval of content.
Xref: cocoa.brown.edu comp.lang.perl.announce:469 comp.lang.perl.misc:49674



    `perlDL' ("perl Data Language") gives standard perl the ability
    to COMPACTLY store and SPEEDILY manipulate the large N-
    dimensional data arrays which are the bread and butter of
    scientific computing.

    The idea is to turn perl in to a, free, array-oriented,
    numerical language in the same sense as commerical packages like
    IDL and MatLab. One can write simple perl expressions to
    manipulate entire numerical arrays all at once.

    For example with `perlDL' the perl variable `$a' can hold a
    1024x1024 floating point image, it only takes 4Mb of memory to
    store it and expressions like `$a=sqrt($a)+2' would manipulate
    the whole image in a few seconds.

    A simple interactive shell ("`perldl'") is provided for command
    line use together with a module ("`PDL'") for use in perl
    scripts.

    v1.00 is the first official alpha release. It provides the
    fundumental numerical processing facilities and a limited set of
    standard functions. Graphics are supported via the perl PGPLOT
    module and image display via the external programs
    saoimage/ximtool. The goal is to allow perlDL to interact with a
    variety of external graphics systems. I/O is currently supported
    via the FITS standard, though given the simple design it ought
    to be possible to create perl code to read many common formats.

    There are of course many things missing from this first release
    but it is hoped that perlDL will grow through efforts of
    interested users. It has a modular design to encourage this.

  Where to obtain perlDL:

  Home Site:

    WWW: http://www.aao.gov.au/local/www/kgb/perldl/

    ftp: ftp://ftp.aao.gov.au/pub/perldl/

  Comprehensive Perl Archive Network (CPAN):

    ftp: In directory modules/by-module/PDL/

    WWW: You can automatically select your LOCAL CPAN site by going
    to: http://www.perl.com/CPAN/modules/by-module/PDL/

    The PGPLOT module is available from (among others):

    http://www.ast.cam.ac.uk/~kgb/pgperl.html (Home Page/General
    information)

    http://www.perl.com/CPAN/modules/by-module/PGPLOT/

    ftp://ftp.ast.cam.ac.uk/pub/kgb/pgperl/

    ftp://ftp.aao.gov.au/pub/pgperl/

    SAOimage is available from:

    http://tdc-www.harvard.edu/software/saoimage.html

  Documentation

    The current perlDL documentation is available from
    http://www.aao.gov.au/local/www/kgb/perldl/PDL.html

  Mailing List

    Finally, a mailing list has been set up to talk about perlDL and
    for developers to coordinate their work.

    The address of the list is perldl@jach.hawaii.edu. To subscribe,
    send a message to perldl-request@jach.hawaii.edu containing a
    string in the following format:

    subscribe me@my.email.address

    I hope you find perlDL useful and enjoyable,

    Karl Glazebrook. email: kgb@aaoepp.aao.gov.au





=================
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  Wed Oct 23 21:33:42 1996
From: jim@ks.uiuc.edu (Jim Phillips)
Date: Wed, 23 Oct 96 15:33:42 -0500
Subject: [PYTHON MATRIX-SIG] package, ni, and Numeric
Message-ID: <199610232033.AA120842832@london.ks.uiuc.edu>

Hi,

After Numeric's brief interlude with packages and ni, I have to agree that ni  
is not ready for prime time.  At the very least, packages should be a  
mandatory extension to the import methods, not an extra import that changes  
system functionality for everything.

Anyway, I now notice that Numeric is fundamentally incompatible with ni  
because it usually resides in a subdirectory of a valid path with the same  
name as the module.  Thus, when ni is imported, it attempts to import Numeric  
as a package and bombs on "from Numeric import *".  This is the kind of cross  
module incompatibility that is just plain bad.  See the dump below for a  
disturbing example.

An OK fix would probably be to revise ni to always attempt to import  
something as a module before importing it as a package, or at the very least  
to make sure the package directory isn't also part of the path.  The best  
solution would be to make the package status of a directory explicit by  
requiring a special extension, such as the usual .py (the interpreter can tell  
the difference between a directory and a file, right?).

As a workaround, one could change the Numeric directory name to numeric.

-Jim Phillips
 jim@ks.uiuc.edu

jim@paris(54) python
Python 1.4b3 (Tue Oct 22 1996)  [GCC NeXT DevKit-based CPP 3.1]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> import Matrix, ni
>>> ^D

jim@paris(55) python
Python 1.4b3 (Tue Oct 22 1996)  [GCC NeXT DevKit-based CPP 3.1]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> import ni, Matrix
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/shared/lib/python1.4/ni.py", line 302, in import_module
    m = self.get0(mname)
  File "/usr/local/shared/lib/python1.4/ni.py", line 344, in get0
    m = self.get(name)
  File "/usr/local/shared/lib/python1.4/ni.py", line 362, in get
    sys.modules[name] = m = self.loader.load_module(name, stuff)
  File "/usr/local/shared/lib/python1.4/ni.py", line 204, in load_module
    return ModuleLoader.load_module(self, name, stuff)
  File "/usr/local/shared/lib/python1.4/ihooks.py", line 259, in load_module
    return self.hooks.load_source(name, filename, file)
  File "/usr/local/shared/lib/python1.4/ihooks.py", line 170, in load_source
    return imp.load_source(name, filename, file)
  File "/usr/local/shared/lib/python1.4/Numeric/Matrix.py", line 2, in ?
    from Numeric import dot
  File "/usr/local/shared/lib/python1.4/ni.py", line 306, in import_module
    return self.finish(m, m, tail, fromlist)
  File "/usr/local/shared/lib/python1.4/ni.py", line 334, in finish
    self.get1(fname)
  File "/usr/local/shared/lib/python1.4/ni.py", line 340, in get1
    raise ImportError, "No module named %s" % name
ImportError: No module named Numeric.dot
>>> ^D

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From drh@cse.unl.edu  Wed Oct 23 21:41:19 1996
From: drh@cse.unl.edu (Doug Heisterkamp)
Date: Wed, 23 Oct 1996 15:41:19 -0500 (CDT)
Subject: [PYTHON MATRIX-SIG] Bug
Message-ID: <199610232041.PAA00375@cse.unl.edu>

I get a core dump on the following:

>>> from Numeric import *
>>> a = array(3)
>>> a[:,NewAxis]
Segmentation fault (core dumped)

Does that happen to anyone else?

Doug Heisterkamp

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From python-list@cwi.nl  Wed Oct 23 21:48:50 1996
From: python-list@cwi.nl (Guido van Rossum)
Date: Wed, 23 Oct 1996 16:48:50 -0400
Subject: [PYTHON MATRIX-SIG] Re: package, ni, and Numeric
In-Reply-To: Your message of "Wed, 23 Oct 1996 15:33:42 CDT."
 <199610232033.AA120842832@london.ks.uiuc.edu>
References: <199610232033.AA120842832@london.ks.uiuc.edu>
Message-ID: <199610232048.QAA29138@monty>

[Cross-posted to Python-list because of its relevance...]

> After Numeric's brief interlude with packages and ni, I have to
> agree that ni is not ready for prime time.

Agreed.  I'm not sure what to do about it -- it doesn't seem to be as
useful as I once thought.  It is also very complicated, and migrating
it to C (which would be necessary to make it a standard feature) would
be a lot of work.  Perhaps we should just drop it?

> As a workaround, one could change the Numeric directory name to numeric.

No, that won't work on Mac/Windows.  Please use something completely
different, e.g. numpy or num.

--Guido van Rossum (home page: http://www.python.org/~guido/)

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Wed Oct 23 21:52:37 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 23 Oct 1996 16:52:37 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] package, ni, and Numeric
In-Reply-To: <199610232033.AA120842832@london.ks.uiuc.edu> from "Jim Phillips" at Oct 23, 96 03:33:42 pm
Message-ID: <199610232052.QAA23884@maigret>

> Anyway, I now notice that Numeric is fundamentally incompatible with ni  
> because it usually resides in a subdirectory of a valid path with the same  
> name as the module.  
> 
> [...]
> 
> As a workaround, one could change the Numeric directory name to numeric.

That is the solution which Guido favors, I believe, based on comments 
to a question I had re: the PIL.

Note that it can't be 'numeric/Numeric.py' because that will break on
case-insensitive architectures.

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Wed Oct 23 22:39:52 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Wed, 23 Oct 1996 16:39:52 -0500
Subject: [PYTHON MATRIX-SIG] More thoughts on comparsion operators.
Message-ID: <199610232135.RAA20955@python.org>


I spent some more time thinking about comparisons and had a dangerous
thought about comparisons:

"No valid comparison function will ever return (-sys.max-1), otherwise
known as INT_MIN. This is because comparison is a symmetric operation
and cmp(a,b) = -cmp(b,a)."

I thought I might be able to use this to make ordered comparisons a
little safer. That is, to raise exceptions for ordered comparisons that
make no sense instead of returning an arbitrary value. In particular,
I was thinking of >, <, etc. on matrices. However this also applies to
other cases such as comparing strings to ints.

So, armed with this thought I dove into the Python core and started
slicing and dicing. After a certain amount of trial and error, I
implemented the following:

(For clarity let's call INT_MIN, NOT_EQUAL).

In ceval.c: comp_outcome:

NOT_EQUAL means that the operands are not equal, but do not have an
ordering. An exception is raised if the result of cmp is NOT_EQUAL, and
the operation is >,<,>=,or <=. Equal returns false, and not-equal
returns true.

In object.c: compobject:

I nuked all the cases where the comparison was being made on what
appeared to be arbitrary grounds (address, class name, etc.) and
returned NOT_EQUAL. The exception is that objects with the same adress
are still always equal (That doesn't seem arbitrary, just ordering
items based on address does).

In bltinmodule.c: builtin_cmp:

I had this catch NOT_EQUAL and return None, so python users don't ever
see -2147483648 floating around. (compobject catches None and returns
NOT_EQUAL, so this should work).

In arrayobject.c: array_compare:

Since I didn't have the code to check if arrays are equal (Jim?), I
just claimed that arrays are always NOT_EQUAL.

Suprisingly, the interpreter survived this surgery, and I haven't
gotten it to break yet (I've done make test, Num_Py/test/test_all, and
other random scripts.) If anyone is interested in testing this out and
seeing how it works for them, I've included the patches at the end.

Here's some samples of the new behaviour:

>>> print 5 < 6
1
>>> print 5 == 5.
1
>>> print 5 < 'a'
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: Illegal types for ordered comparison
>>> print 5 == 'a'
0
>>> 5 < 6
1
>>> 5 == 5.
1
>>> 5 == 'a'
0
>>> 5 < 'b'
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: Illegal types for ordered comparison
>>> class Spam:
...     pass
... 
>>> 5 == Spam
0
>>> s = Spam()
>>> 5 == s
0
>>> s < Spam
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: __cmp__ nor __rcmp__ defined for these operands
>>> s < 5
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: __cmp__ nor __rcmp__ defined for these operands
>>> Spam < s
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: __cmp__ nor __rcmp__ defined for these operands
class Eggs:
...    def __cmp__(self,other):
...             if type(other) != type(self):
...                     return cmp(5, other)
... 
>>> e = Eggs()
>>> e < 7
1
>>> e < 4
0


Did you actually read this far? I'm impressed!!!! Well here's the
patches. Let me know if you think they're interesting / useful.

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


*** Python/bltinmodule.c	Wed Oct 23 16:12:10 1996
--- Python/bltinmodule.c.orig	Wed Oct 23 16:26:05 1996
***************
*** 24,30 ****
  
  /* Built-in functions */
  
- #include <limits.h>
  #include "allobjects.h"
  
  #include "node.h"
--- 24,29 ----
***************
*** 230,244 ****
  	object *args;
  {
  	object *a, *b;
! 	int cmp_result;
  	if (!newgetargs(args, "OO:cmp", &a, &b))
  		return NULL;
! 	cmp_result = cmpobject(a, b);
! 	if(cmp_result == INT_MIN) {
! 	    INCREF(None);
! 	    return None;
! 	}
! 	return newintobject((long)cmp_result);
  }
  
  static object *
--- 229,238 ----
  	object *args;
  {
  	object *a, *b;
! 
  	if (!newgetargs(args, "OO:cmp", &a, &b))
  		return NULL;
! 	return newintobject((long)cmpobject(a, b));
  }
  
  static object *
*** Python/ceval.c	Wed Oct 23 15:32:13 1996
--- Python/ceval.c.orig	Wed Oct 23 13:20:18 1996
***************
*** 31,38 ****
     XXX document it!
     */
  
- #include <limits.h>
- 
  #include "allobjects.h"
  
  #include "compile.h"
--- 31,36 ----
***************
*** 2807,2820 ****
  		break;
  	default:
  		cmp = cmpobject(v, w);
- 		if (op != EQ && op != NE && cmp == INT_MIN) {
- 		    if (!err_occurred())
- 			err_setstr(TypeError, "Illegal types for ordered comparison");
- 		    return NULL;
- 		}
- 		else {
- 		    err_clear(); /* Might have been set. */
- 		}
  		switch (op) {
  		case LT: res = cmp <  0; break;
  		case LE: res = cmp <= 0; break;
--- 2805,2810 ----
*** Objects/object.c	Wed Oct 23 13:30:50 1996
--- Objects/object.c.orig	Wed Oct 23 13:24:45 1996
***************
*** 24,30 ****
  
  /* Generic object operations; and implementation of None (NoObject) */
  
- #include <limits.h>
  #include "allobjects.h"
  
  #if defined( Py_TRACE_REFS ) || defined( Py_REF_DEBUG )
--- 24,29 ----
***************
*** 275,285 ****
  			return -cmpobject(w, v);
  		res = do_cmp(v, w);
  		if (res == NULL) {
! 		    return INT_MIN;
  		}
  		if (!is_intobject(res)) {
  			DECREF(res);
! 			return INT_MIN;
  		}
  		c = getintvalue(res);
  		DECREF(res);
--- 274,285 ----
  			return -cmpobject(w, v);
  		res = do_cmp(v, w);
  		if (res == NULL) {
! 			err_clear();
! 			return (v < w) ? -1 : 1;
  		}
  		if (!is_intobject(res)) {
  			DECREF(res);
! 			return (v < w) ? -1 : 1;
  		}
  		c = getintvalue(res);
  		DECREF(res);
***************
*** 289,295 ****
  		if (tp->tp_as_number != NULL &&
  				w->ob_type->tp_as_number != NULL) {
  			if (coerce(&v, &w) != 0) {
! 			    return INT_MIN;
  			}
  			else {
  				int cmp = (*v->ob_type->tp_compare)(v, w);
--- 289,297 ----
  		if (tp->tp_as_number != NULL &&
  				w->ob_type->tp_as_number != NULL) {
  			if (coerce(&v, &w) != 0) {
! 				err_clear();
! 				/* XXX Should report the error,
! 				   XXX but the interface isn't there... */
  			}
  			else {
  				int cmp = (*v->ob_type->tp_compare)(v, w);
***************
*** 298,307 ****
  				return cmp;
  			}
  		}
! 		return INT_MIN;
  	}
  	if (tp->tp_compare == NULL)
! 		return INT_MIN;
  	return (*tp->tp_compare)(v, w);
  }
  
--- 300,309 ----
  				return cmp;
  			}
  		}
! 		return strcmp(tp->tp_name, w->ob_type->tp_name);
  	}
  	if (tp->tp_compare == NULL)
! 		return (v < w) ? -1 : 1;
  	return (*tp->tp_compare)(v, w);
  }
  



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

-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+





=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From barrett@compass.gsfc.nasa.gov  Wed Oct 23 22:36:31 1996
From: barrett@compass.gsfc.nasa.gov (Paul Barrett)
Date: Wed, 23 Oct 1996 17:36:31 -0400
Subject: [PYTHON MATRIX-SIG] [Fwd: ANNOUNCE: perlDL v1.00 - the 'perl Data Language']
In-Reply-To: <326E798F.41C6@maigret.cog.brown.edu>
References: <326E798F.41C6@maigret.cog.brown.edu>
Message-ID: <199610232136.RAA25067@compass.gsfc.nasa.gov>


I was wondering how you, David Ascher, became aware of PerlDL?

I was made aware of it at the Astronomical Data Analysis and Software
Systems Conference (ADASS VI) in Charlottesville, VA in late
Sept. '96. An annual conference sponsored by the American Astronomical
Society.  I spoke with one of the implementors about PerlDL and
Python, encouraging them to abandon PerlDL in favor of Python.  I
guess they ignored my advice.

In fact, a friend and I sponsored a Birds-of-a-Feather (BoF) session
at this conference about interactive data languages.  I advocated
Python as the language of choice, basically as a free version of IDL
and described its merits and potential.  The PerlDL people were there,
so they should have some idea of Pythons merits for numerical
analysis.

I have a rough draft of a table comparing all the languages and data
analysis enviromments that I'm currently aware of.  It's located at
the following URL:

http://lheawww.gsfc.nasa.gov/users/barrett/IDAE/table.1.html

It is still in the early stages of construction, since gathering so
much information about two dozen languages takes alot of time, more
than I have at the moment.  Any comments or suggestions about the
table are welcome.  It is intended to be an objective comparison, but
hopefully one will notice that Python is one of the frontrunners in
this category.

Paul

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Paul Barrett  -  Astrophysicist  -  Universities Space Research Association |
|                 Compton Observatory Science Support Center                  |
| NASA/Goddard SFC     phone: 301-286-1108           "Cracking toast, Gromit" |
| Code 660.1,          FAX:   301-286-1681            says Wallace.           |
| Greenbelt,MD 20771   barrett@compass.gsfc.nasa.gov  (in The Wrong Trousers) |
|             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 drh@cse.unl.edu  Wed Oct 23 22:46:00 1996
From: drh@cse.unl.edu (Doug Heisterkamp)
Date: Wed, 23 Oct 1996 16:46:00 -0500 (CDT)
Subject: [PYTHON MATRIX-SIG] Change eigenvectors to eigensystems?
Message-ID: <199610232146.QAA18388@cse.unl.edu>

> > A minor naming point -- since "eigenvectors" returns the eigenvalues as
> > well, would it perhaps be less confusing to rename it to "eigensystem"?
> > 
> > Alistair
> 
> This sounds reasonable to me, but I thought I should ask for objections
> from other users of LinearAlgebra.py before I go around changing naming
> conventions again.
> 

Is "eigensystem" a conventional term when referring to both eigenvalues
and eigenvectors?  If not, I would rather not coin a new word.  Especially
one that looks like it could have meaning in a specialized context.  If so, 
I would not have a problem with using eigensystem. 

Note, Maple's eigenvects routine return's both eigenvalues and eigenvectors.

Doug Heisterkamp
drh@cse.unl.edu


=================
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  Thu Oct 24 00:06:08 1996
From: jim@ks.uiuc.edu (Jim Phillips)
Date: Wed, 23 Oct 96 18:06:08 -0500
Subject: [PYTHON MATRIX-SIG] Change eigenvectors to eigensystems?
In-Reply-To: <199610232146.QAA18388@cse.unl.edu>
References: <199610232146.QAA18388@cse.unl.edu>
Message-ID: <199610232306.AA126391969@london.ks.uiuc.edu>

You wrote:
> > > A minor naming point -- since "eigenvectors" returns the eigenvalues as
> > > well, would it perhaps be less confusing to rename it to "eigensystem"?
>
> Is "eigensystem" a conventional term when referring to both eigenvalues
> and eigenvectors?  If not, I would rather not coin a new word.  Especially
> one that looks like it could have meaning in a specialized context.  If so, 
> I would not have a problem with using eigensystem.
>
> Note, Maple's eigenvects routine return's both eigenvalues and eigenvectors.

Mathematica has all three: Eigenvalues, Eigenvectors, and Eigensystem (which  
returns {values, vectors}).  This seems to make things clearer.

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From alistair@maths.uwa.edu.au  Thu Oct 24 01:17:58 1996
From: alistair@maths.uwa.edu.au (Alistair Mees)
Date: Thu, 24 Oct 1996 08:17:58 +0800
Subject: [PYTHON MATRIX-SIG] Change eigenvectors to eigensystems?
In-Reply-To: <199610232146.QAA18388@cse.unl.edu>
References: <199610232146.QAA18388@cse.unl.edu>
Message-ID: <199610240017.IAA16164@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>


Doug Heisterkamp writes:
 > > > A minor naming point -- since "eigenvectors" returns the eigenvalues as
 > > > well, would it perhaps be less confusing to rename it to "eigensystem"?
 > > > 
 > > > Alistair
 > > 
 > > This sounds reasonable to me, but I thought I should ask for objections
 > > from other users of LinearAlgebra.py before I go around changing naming
 > > conventions again.
 > > 
 > 
 > Is "eigensystem" a conventional term when referring to both eigenvalues
 > and eigenvectors?  If not, I would rather not coin a new word.  Especially
 > one that looks like it could have meaning in a specialized context.  If so, 
 > I would not have a problem with using eigensystem. 
 > 
 > Note, Maple's eigenvects routine return's both eigenvalues and eigenvectors.
 > 
 > Doug Heisterkamp
 > drh@cse.unl.edu

"Eigensystem" is commonly used to mean the eigenvalues and eigenvectors of
a square matrix, or the eigenvalues and eigenfunctions of a linear
operator.  The second version is an infinite dimensional generalization of the
first.

I notice that Mathematica uses Eigensystem in the way I proposed.  I had a
quick look round on the web and didn't see any other usage.  I'll try to
find a mathematical dictionary to make sure.

Alistair Mees
alistair@maths.uwa.edu.au


=================
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 Oct 24 10:49:36 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Oct 96 10:49:36 +0100
Subject: [PYTHON MATRIX-SIG] Change eigenvectors to eigensystems?
In-Reply-To: <9610231814.AA03304@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610240955.KAA13723@ibs.ibs.fr>

> > A minor naming point -- since "eigenvectors" returns the eigenvalues as
> > well, would it perhaps be less confusing to rename it to "eigensystem"?
> > 
> > Alistair
> 
> This sounds reasonable to me, but I thought I should ask for objections
> from other users of LinearAlgebra.py before I go around changing naming
> conventions again.

I agree.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Thu Oct 24 10:46:00 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Oct 96 10:46:00 +0100
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <9610231811.AA03260@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610240951.KAA13698@ibs.ibs.fr>

> I find that almost everybody I've explained it to understands the where
> function.  For some reason the increased generality of choose is confusing
> to many people.  So I plan on leaving the where function in.  It serves the
> same purpose as sum == add.reduce and similar convenient abbreviations.

Then at least make where = choose. Right now they do almost the same
thing with slightly different parameter lists.

> > 2) compress() is just a special case of repeat() and should be
> >    eliminated.
> 
> Similarly for compress, the main addition is that it makes sure the
> arguments are either zero or one before doing the repeat operation and this
> is just a lot easier for some people to understand.

But again, at least the parameter lists should be constructed in the same
way.

> I think you're right about this one.  If you were to give me a better
> implementation of diagonal that works as you describe I'd be happy to use
> it.  (Although I do think that the proper choice of arguments for the nd
> case is a tuple of two OR MORE integers specifying the axes along which to
> take the diagonal).

That also makes sense for some applications, and is certainly more
general. However, I don't see a way to implement that efficiently
right away...

> In case you haven't noticed as we've worked on this for the past year, for
> some reason I really dislike any generalizations I've seen of the
> innerproduct.  This is the basic reason why the is no "inner" method on

If you dislike them you don't have to use them ;-)

> ufuncs.  I'm personally quite happy with how things are currently defined
> now, and for all of my matrixmultiply-like tasks, I find dot is the way I
> think about the world.

I'd love to see a single example where dot() as it is makes sense.
I *always* have to reshuffle axes before calling dot().

> PS - I somehow doubt that these are truly your last complaints, not that
> I'd want it any other way ;-)

I suppose you are right ;-)

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Thu Oct 24 10:48:27 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Oct 96 10:48:27 +0100
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <199610231828.OAA23403@maigret> (da@maigret.cog.brown.edu)
Message-ID: <199610240954.KAA13715@ibs.ibs.fr>

> I appreciate the reasoning, but the name seems confusing.  How about 
> 
> 	searchsorted()
> 
> to be even more explicit.

I agree, although I'd prefer search_sorted() (always nitpicking...)
The name binarysearch() may indicate the restriction to sorted arrays
to anyone familiar with searching algorithms, but we can't expect all
users to be familiar with them. I am sure that if I cry out aloud
"what's a binary search" in our terminal room, I won't get a single
correct answer.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Thu Oct 24 12:48:51 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Oct 96 12:48:51 +0100
Subject: [PYTHON MATRIX-SIG] More thoughts on comparsion operators.
In-Reply-To: <199610232135.RAA20955@python.org> (tim@lassi.ece.uiuc.edu)
Message-ID: <199610241154.MAA14345@ibs.ibs.fr>

> I thought I might be able to use this to make ordered comparisons a
> little safer. That is, to raise exceptions for ordered comparisons that
> make no sense instead of returning an arbitrary value. In particular,
> I was thinking of >, <, etc. on matrices. However this also applies to
> other cases such as comparing strings to ints.

I think we all agree that this is an important point and should be
taken care of. As for the suitability of your solution, well, I don't
particularly like messing around with things like INT_MIN.

Would it be much more work to use a more clearly non-comparison return
value for "not equal"? Perhaps None in Python code and a null pointer
in C code?

> Did you actually read this far? I'm impressed!!!! Well here's the
> patches. Let me know if you think they're interesting / useful.

Whatever a final solution will look like, your patches are interesting
just for personal use as a debugging aid. Thanks!

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From fredrik_lundh@ivab.se  Thu Oct 24 12:41:08 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Thu, 24 Oct 1996 13:41:08 +0200
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <199610240954.KAA13715@ibs.ibs.fr> (message from Konrad Hinsen on
 Thu, 24 Oct 96 10:48:27 +0100)
Message-ID: <9610241141.AA07075@arnold.image.ivab.se>


> I agree, although I'd prefer search_sorted() (always nitpicking...)
> The name binarysearch() may indicate the restriction to sorted arrays
> to anyone familiar with searching algorithms, but we can't expect all
> users to be familiar with them.

 What about some kind of hint mechanisms, like "search() vs.
search(SORTED)" or something more elegant.

 I suppose such stuff would be applicable to many other numerical
methods as well (but otoh, I'm just a programmer ;-)

> I am sure that if I cry out aloud "what's a binary search" in our
> terminal room, I won't get a single correct answer.

 I just tried that here, and people immediately started discussing
search complexity and implementation details.  That it required sorted
data was so obvious that noone even told me...

Cheers	/F

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Thu Oct 24 14:21:44 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Oct 96 14:21:44 +0100
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <9610241141.AA07075@arnold.image.ivab.se> (message from Fredrik
 Lundh on Thu, 24 Oct 1996 13:41:08 +0200)
Message-ID: <199610241327.OAA14831@ibs.ibs.fr>

> > I am sure that if I cry out aloud "what's a binary search" in our
> > terminal room, I won't get a single correct answer.
> 
>  I just tried that here, and people immediately started discussing
> search complexity and implementation details.  That it required sorted
> data was so obvious that noone even told me...

Must be computer scientists, right? Whenever I try to give a Python
demonstration, I usually get stuck at the point where someone asks
what the maximum size of an "undeclared" list is. And once I had to
explain dictionaries in terms of Fortran arrays containing indices to
other arrays. But then what do you expect from people who are willing
to spend a whole day writing a Fortran program to add up the length
of files from a tar archive listing...

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From guido@CNRI.Reston.Va.US  Thu Oct 24 13:56:17 1996
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Thu, 24 Oct 1996 08:56:17 -0400
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: Your message of "Thu, 24 Oct 1996 13:41:08 +0200."
 <9610241141.AA07075@arnold.image.ivab.se>
References: <9610241141.AA07075@arnold.image.ivab.se>
Message-ID: <199610241256.IAA02926@monty>

>  What about some kind of hint mechanisms, like "search() vs.
> search(SORTED)" or something more elegant.

Just a general out of context remark: I'm becoming less and less fond
of functions that take optional enum or flag arguments to modify their
behavior.  In practice, 100% of the calls give a constant for the flag
(unless you are writing a wrapper around the function, like an
extension method).

While search(SORTED) looks slightly better than search(1), of we're
going to type that much, I'd much prefer search_sorted().

Just an opinion...

--Guido van Rossum (home page: http://www.python.org/~guido/)

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Thu Oct 24 15:02:31 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Oct 96 15:02:31 +0100
Subject: [PYTHON MATRIX-SIG] Bug
In-Reply-To: <199610232041.PAA00375@cse.unl.edu> (drh@cse.unl.edu)
Message-ID: <199610241408.PAA15125@ibs.ibs.fr>

> I get a core dump on the following:
> 
> >>> from Numeric import *
> >>> a = array(3)
> >>> a[:,NewAxis]
> Segmentation fault (core dumped)
> 
> Does that happen to anyone else?

No:

Python 1.4b3 (October 13 1995) [C]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
from Numeric import *
>>> a = array(3)
a = array(3)
>>> a[:,NewAxis]
a[:,NewAxis]
EmptyArray
>>>

(Note that the error message is not quite correct - this is
not an empty array, but a rank-0 array.)

Nevertheless, array() should probably return a scalar in this
case. Otherwise there is a backdoor to create rank-0 arrays
that can create lots of confusion.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From fredrik_lundh@ivab.se  Thu Oct 24 14:26:06 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Thu, 24 Oct 1996 15:26:06 +0200
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <199610241256.IAA02926@monty> (message from Guido van Rossum on
 Thu, 24 Oct 1996 08:56:17 -0400)
Message-ID: <9610241326.AA26637@arnold.image.ivab.se>


> While search(SORTED) looks slightly better than search(1), of we're
> going to type that much, I'd much prefer search_sorted().

Agreed (especially in this case).

But generally, such solutions quickly breaks down.  From PIL:

	draw = ImageDraw(image)
	draw.polygon(xy)
	draw.polygon_convex(xy)
	draw.polygon_noncomplex(xy)
	draw.polygon_complex(xy)

One solution is of course to provide different classes to store the
coordinates in, but that surely messes things up for the poor users.

I don't know, but isn't similar situations very common for numerical
operations.  Or is it just our local math guys that make it sound that
way?

	/F (just a plain old programmer)

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Thu Oct 24 16:10:53 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Thu, 24 Oct 1996 10:10:53 -0500
Subject: [PYTHON MATRIX-SIG] More thoughts on comparsion operators.
In-Reply-To: <199610241154.MAA14345@ibs.ibs.fr> (message from Konrad Hinsen on
 Thu, 24 Oct 96 12:48:51 +0100)
Message-ID: <199610241506.LAA23512@python.org>


Konrad Hinsen writes:
>> I thought I might be able to use this to make ordered comparisons a
>> little safer. That is, to raise exceptions for ordered comparisons that
>> make no sense instead of returning an arbitrary value. In particular,
>> I was thinking of >, <, etc. on matrices. However this also applies to
>> other cases such as comparing strings to ints.
>
>I think we all agree that this is an important point and should be
>taken care of. As for the suitability of your solution, well, I don't
>particularly like messing around with things like INT_MIN.
>
>Would it be much more work to use a more clearly non-comparison return
>value for "not equal"? Perhaps None in Python code and a null pointer
>in C code?

None works for python code as is. The only way this implementation
detail creeps into Python itself, is that if you return INT_MIN from
__cmp__ your going to get an error. As I mentioned previously, this is
a bug anyway since no legitimate cmp function will return INT_MIN, so
an error here is the right thing. On the down side, it will be the
wrong error message (Hmmm - but I think I could fix that...).

As for c code, I think we're out of luck there. The comparison
function for c-objects returns an int, not a python object. INT_MIN is
the best I could come with. If you have any ideas though, let me know.


>Whatever a final solution will look like, your patches are interesting
>just for personal use as a debugging aid. Thanks!
_

Your welcome. Glad to be of service. Guido pointed out that I hadn't
fixed list.sort(). Here's a patch to fix that:

The way errors are handled could still be cleaned up, but not today... 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++




*** Objects/listobject.c        Wed Oct 23 18:49:54 1996
--- Objects/listobject.c.orig   Wed Oct 23 18:39:31 1996
***************
*** 24,34 ****
  
  /* List object implementation */
  
- #include <limits.h>
- #ifdef roundup
- #undef roundup
- #endif
- 
  #include "allobjects.h"
  #include "modsupport.h"
  #include "ceval.h"
--- 24,29 ----
***************
*** 560,573 ****
        if (err_occurred())
                return 0;
  
!       if (comparefunc == NULL) {
!               int cmp_result = cmpobject(* (object **) v, * (object **) w);
!               if (cmp_result == INT_MIN) {
!                   err_setstr(TypeError, "Illegal types for ordered comparison i
n sort");
!                   return 0;
!               }
!               return cmp_result;
!       }
  
        /* Call the user-supplied comparison function */
        t = mkvalue("(OO)", * (object **) v, * (object **) w);
--- 555,562 ----
        if (err_occurred())
                return 0;
  
!       if (comparefunc == NULL)
!               return cmpobject(* (object **) v, * (object **) w);
  
        /* Call the user-supplied comparison function */
        t = mkvalue("(OO)", * (object **) v, * (object **) w);





++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jbaddor@phy.ulaval.ca  Thu Oct 24 16:54:47 1996
From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR)
Date: Thu, 24 Oct 1996 11:54:47 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] problem building numeric: ld.so: Undefined symbol: _acos
In-Reply-To: <199610241506.LAA23512@python.org>
Message-ID: <Pine.SUN.3.95.961024114556.17065B-100000@mills>


Hi !

Has anybody experienced the same problem ?
Can you help me ?
for python 1.4 beta 3, I used

configure --prefix=HOME --exec-prefix=$HOME/SunOS --with-thread
--with-readline=$HOME/lib --with-gcc

for numeric:
NumPy-1.0a5.tar.gz
NumPyLib-1.0a5.tar.gz

and I have built dynamically, as documented.

here is the result of the test command:

trinite:~/Python1.4beta3[8]>./python -c 'import testall' 
test_grammar
1. Parser
1.1 Tokens
1.1.1 Backslashes
1.1.2 Numeric literals
1.1.2.1 Plain integers
1.1.2.2 Long integers
1.1.2.3 Floating point
1.1.3 String literals
1.2 Grammar
single_input
file_input
expr_input
eval_input
funcdef
simple_stmt
expr_stmt
print_stmt
1 2 3
1 2 3
1 1 1
del_stmt
pass_stmt
flow_stmt
break_stmt
continue_stmt
return_stmt
raise_stmt
import_stmt
global_stmt
exec_stmt
if_stmt
while_stmt
for_stmt
try_stmt
suite
test
comparison
binary mask ops
shift ops
additive ops
multiplicative ops
unary ops
selectors
atoms
classdef
test_opcodes
2. Opcodes
XXX Not yet fully implemented
2.1 try inside for loop
2.2 raise class exceptions
test_operations
3. Operations
XXX Not yet implemented
test_builtin
4. Built-in functions
test_b1
__import__
abs
apply
callable
chr
cmp
coerce
compile
delattr
dir
divmod
eval
execfile
filter
float
getattr
hasattr
hash
hex
id
int
len
long
map
ld.so: Undefined symbol: _acos

	Jean-Bernard



=================
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  Thu Oct 24 17:59:13 1996
From: jim@ks.uiuc.edu (Jim Phillips)
Date: Thu, 24 Oct 96 11:59:13 -0500
Subject: [PYTHON MATRIX-SIG] Bug
In-Reply-To: <199610241408.PAA15125@ibs.ibs.fr>
References: <199610241408.PAA15125@ibs.ibs.fr>
Message-ID: <199610241659.AA155226355@london.ks.uiuc.edu>

Very strange bug we've got here.  For the exact same code and compiler I get  
different results depending on the architecture!

On an HP:

Python 1.4b3 (Oct 22 1996)  [GCC 2.7.2]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> a = array(3)
>>> a[:,NewAxis]
EmptyArray

On an SGI:

Python 1.4b3 (Oct 22 1996)  [GCC 2.7.2]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> a = array(3)
>>> a[:,NewAxis]
Segmentation fault (core dumped)

-Jim Phillips
 jim@ks.uiuc.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  Thu Oct 24 18:04:30 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 24 Oct 1996 13:04:30 -0400
Subject: [PYTHON MATRIX-SIG] Bug
Message-ID: <9610241701.AA20648@goldilocks.LCS.MIT.EDU>


> Nevertheless, array() should probably return a scalar in this
> case. Otherwise there is a backdoor to create rank-0 arrays
> that can create lots of confusion.

Not true at all.  It is important to be able to create rank-0 arrays in
order to do:

array_of_floats * array(3.14159, Float32)

-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  Thu Oct 24 19:58:28 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Oct 96 19:58:28 +0100
Subject: [PYTHON MATRIX-SIG] Bug
In-Reply-To: <9610241701.AA20648@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610241904.UAA16955@ibs.ibs.fr>

> Not true at all.  It is important to be able to create rank-0 arrays in
> order to do:
> 
> array_of_floats * array(3.14159, Float32)

True. So how about allowing rank-0 arrays only for the types which
don't have scalar counterparts in Python, and disallowing any
array-specific operations (especially indexing) on them, to make
them act just like scalar types?

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Thu Oct 24 19:11:34 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 24 Oct 1996 14:11:34 -0400
Subject: [PYTHON MATRIX-SIG] Bug
Message-ID: <9610241808.AA21827@goldilocks.LCS.MIT.EDU>


> > Not true at all.  It is important to be able to create rank-0 arrays in
> > order to do:
> > 
> > array_of_floats * array(3.14159, Float32)
> 
> True. So how about allowing rank-0 arrays only for the types which
> don't have scalar counterparts in Python, 

I also want to be able to write a * array(3.14, a.typecode()) sometimes, so
I need to be able to create them with any type.

> and disallowing any
> array-specific operations (especially indexing) on them, to make
> them act just like scalar types?

This sounds like a good idea in general.  The one problem here is that I do
want to provide some way to get the python value out of a scalar.  This is
currently done by scalar[0].  This could also be done by scalar.tolist() I
suppose.  I'd hate to add a special method just for this one highly unusual
operation.

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jbaddor@phy.ulaval.ca  Thu Oct 24 19:23:38 1996
From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR)
Date: Thu, 24 Oct 1996 14:23:38 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] problem building numeric: ld.so: Undefined symbol: _acos
In-Reply-To: <199610241836.TAA16847@ibs.ibs.fr>
Message-ID: <Pine.SUN.3.95.961024141941.17065G-100000@mills>

> > ld.so: Undefined symbol: _acos

that was the math module, I cannot built it dynamically but statically it
builts (SunOS)

Have I to send a bug report to somebody ?

Jean-Bernard


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From fonseca@gaivota.demon.co.uk  Thu Oct 24 19:53:18 1996
From: fonseca@gaivota.demon.co.uk (Carlos Fonseca)
Date: Thu, 24 Oct 1996 19:53:18 +0100 (BST)
Subject: [PYTHON MATRIX-SIG] Bug
In-Reply-To: <199610232041.PAA00375@cse.unl.edu>
Message-ID: <Pine.LNX.3.95.961024193013.4096A-100000@gaivota.demon.co.uk>

On Wed, 23 Oct 1996, Doug Heisterkamp wrote:

> I get a core dump on the following:
> 
> >>> from Numeric import *
> >>> a = array(3)
> >>> a[:,NewAxis]
> Segmentation fault (core dumped)
> 
> Does that happen to anyone else?
> 
> Doug Heisterkamp
> 

Yes, it does here (Debian Linux, kernel 2.0.23, libc-5.2.18, gcc 2.7.2,
NumPy modules dynamically linked). What's your setup?

The backtrace produced by gdb is:

#0  0x4012c489 in __ypbindlist ()
#1  0x40137344 in __ypbindlist ()
#2  0x4012c5d2 in __ypbindlist ()
#3  0x40131d2f in __ypbindlist ()
#4  0x800f84c in apply_subscript ()
#5  0x800c8c8 in eval_code2 ()
#6  0x800be52 in PyEval_EvalCode ()
#7  0x801af0b in run_node ()
#8  0x801a8a2 in PyRun_InteractiveOne ()
#9  0x801a747 in PyRun_InteractiveLoop ()
#10 0x801a6a7 in PyRun_AnyFile ()
#11 0x8006163 in main ()
#12 0x8005d04 in ___crt_dummy__ ()
#13 0x7273752f in __ypbindlist ()
Cannot access memory at address 0x32680261.

Hope the above is of any use...

Carlos



=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Thu Oct 24 21:24:31 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Thu, 24 Oct 1996 15:24:31 -0500
Subject: [PYTHON MATRIX-SIG] More thoughts on comparsion operators.
In-Reply-To: <199610241506.LAA23512@python.org> (tim@lassi.ece.uiuc.edu)
Message-ID: <199610242019.QAA24312@python.org>


I wrote:

>The way errors are handled could still be cleaned up, but not today... 

I lied. I tried, but I couldn't stop myself from cleaning it up. Let
me describe the effects of the latest patch. Hopefully this will
alleviate some of Konrad's concerns. I'd really appreciate it some
people could try this out and give me comments (and find all my bugs
for me ;)

As I've looked into this more, I've decided that this idea is more
useful than I first thought. It fixes lots of silent errors that I
didn't even know existed. For instance, a user defined __cmp__
function can return any object it wants, but if its not an integer,
the compare function just ignores it and does something
arbitrary. Also, exceptions in __cmp__ are currently ignored (and
there was such a fuss about exceptions in __del__ methods too...).

How does this apply to NumPy? Assuming it (or something like it) gets
adopted someday, it gives us two new options for comparing
arrays:

1) (easy) Raise an exception - if any arrays are compared an exception
would be raised. Note that if arrays were the same object, they still
would evaluate as equal instead of raising an exception.

2) (better) Return 0 for arrays that are equal, and NOT_EQUAL for
arrays that are not equal. This would give == and != useful meaning,
but (essentially**) disable the other comparisons.

(**) All comparisons would work if the objects were equal, only if they
were NOT_EQUAL would exceptions get raised. This is seems weird at
first, but is logical if you think about it.

----------------------------------------------------------------

Python __cmp__ functions:
------------------------

Legal return values: integers from -sys.maxint to sys.maxint inclusive
and None. (returning -sys.maxint-1 == INT_MIN or any non-int raises an
exception)

Integers have their normal meanings, None means that the compared
objects are not equal but have no ordering (NOT_EQUAL).

Exceptions raised in __cmp__ methods now work.

If there is no __cmp__ (or __rcmp__) function for either object, the
objects are NOT_EQUAL (unless they are the same object).


C extension class comparsion functions:
-------------------------------------

returning INT_MIN means that the compared objects are NOT_EQUAL.

If errors are set, they are no longer ignored.

If objects cannot be coerced into comparable types, they are NOT_EQUAL.


Assorted:
--------

Objects are always equal to themselves (cmp is not called in this
case). This is unchanged from before.

<,>,<=,>= raise exceptions if their operands are NOT_EQUAL.

list.sort() raises an exception if any of its operands are
NOT_EQUAL. It also correctly propogates errors raised by __cmp__, etc.

cmp(a,b) returns None if the objects are NOT_EQUAL. Exceptions are
propogated correctly.

----------------------------------------------------------------

At least that is what is supposed to happen. If you find otherwise
please let me know, and I'll fix it.

I think this fixes most of the problems with comparisons in a pretty
satisfactory way. I know using INT_MIN gives Konrad the creeps, but
it's only in the C API; it should be completely invisible from the
python end of things.


(This patch is against the original python 1.4b3 sources.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


*** Objects//object.c.orig	Wed Oct 23 13:24:45 1996
--- Objects//object.c	Thu Oct 24 12:07:20 1996
***************
*** 24,29 ****
--- 24,30 ----
  
  /* Generic object operations; and implementation of None (NoObject) */
  
+ #include <limits.h>
  #include "allobjects.h"
  
  #if defined( Py_TRACE_REFS ) || defined( Py_REF_DEBUG )
***************
*** 258,310 ****
  
  int
  cmpobject(v, w)
! 	object *v, *w;
  {
! 	typeobject *tp;
! 	if (v == w)
! 		return 0;
! 	if (v == NULL)
! 		return -1;
! 	if (w == NULL)
! 		return 1;
! 	if (is_instanceobject(v) || is_instanceobject(w)) {
! 		object *res;
! 		int c;
! 		if (!is_instanceobject(v))
! 			return -cmpobject(w, v);
! 		res = do_cmp(v, w);
! 		if (res == NULL) {
! 			err_clear();
! 			return (v < w) ? -1 : 1;
! 		}
! 		if (!is_intobject(res)) {
! 			DECREF(res);
! 			return (v < w) ? -1 : 1;
! 		}
! 		c = getintvalue(res);
! 		DECREF(res);
! 		return (c < 0) ? -1 : (c > 0) ? 1 : 0;	
  	}
! 	if ((tp = v->ob_type) != w->ob_type) {
! 		if (tp->tp_as_number != NULL &&
! 				w->ob_type->tp_as_number != NULL) {
! 			if (coerce(&v, &w) != 0) {
! 				err_clear();
! 				/* XXX Should report the error,
! 				   XXX but the interface isn't there... */
! 			}
! 			else {
! 				int cmp = (*v->ob_type->tp_compare)(v, w);
! 				DECREF(v);
! 				DECREF(w);
! 				return cmp;
! 			}
! 		}
! 		return strcmp(tp->tp_name, w->ob_type->tp_name);
  	}
! 	if (tp->tp_compare == NULL)
! 		return (v < w) ? -1 : 1;
! 	return (*tp->tp_compare)(v, w);
  }
  
  long
--- 259,326 ----
  
  int
  cmpobject(v, w)
!     object *v, *w;
  {
!     typeobject *tp;
!     if (v == w)
! 	return 0;
!     if (v == NULL)
! 	return -1;
!     if (w == NULL)
! 	return 1;
!     if (is_instanceobject(v) || is_instanceobject(w)) {
! 	object *res;
! 	int c;
! 	if (!is_instanceobject(v))
! 	    return -cmpobject(w, v);
! 	res = do_cmp(v, w);
! 	if (err_occurred()) { /* Err in __cmp__ */
! 	    object *exc, *val, *tb;
! 	    err_fetch(&exc, &val, &tb);
! 	    if ( (exc != TypeError) || /* if __cmp__ not defined, ignore error */
! 				/* XXX This next is fragile / kludgy, but what to do? */
! 		 strcmp(GETSTRINGVALUE((stringobject *)(val)),  
! 			"__cmp__ nor __rcmp__ defined for these operands") ) {
! 		err_restore(exc, val, tb);
! 	    }
! 	    return INT_MIN;
  	}
!         if (res == NULL)	/* Null result with no error! */
! 	    err_setstr(SystemError, "NULL result without error in call_object");
! 
! 	if (res == None) {	/* NOT_EQUAL */
! 	    return INT_MIN;
  	}
! 	if (!is_intobject(res)) { /* Illegal object returned */
! 	    err_setstr(TypeError, "Illegal return value from __cmp__ or __rcmp__");
! 	    DECREF(res);
! 	    return INT_MIN;
! 	}
! 	c = getintvalue(res);
! 	DECREF(res);
! 	if (c == INT_MIN) { /* Not a legal value for __cmp__ */
! 	    err_setstr(TypeError, "Illegal return value from __cmp__ or __rcmp__");
! 	    return INT_MIN;
! 	}
! 	return c; /* was: return (c < 0) ? -1 : (c > 0) ? 1 : 0;   */
!     }
!     if ((tp = v->ob_type) != w->ob_type) {
! 	if (tp->tp_as_number != NULL && w->ob_type->tp_as_number != NULL) {
! 	    if (coerce(&v, &w) != 0) {
! 		return INT_MIN;
! 	    }
! 	    else {
! 		int cmp = (*v->ob_type->tp_compare)(v, w);
! 		DECREF(v);
! 		DECREF(w);
! 		return cmp;
! 	    }
! 	}
! 	return INT_MIN;
!     }
!     if (tp->tp_compare == NULL)
! 	return INT_MIN;
!     return (*tp->tp_compare)(v, w);
  }
  
  long
*** Objects//listobject.c.orig	Wed Oct 23 18:39:31 1996
--- Objects//listobject.c	Thu Oct 24 14:15:26 1996
***************
*** 24,29 ****
--- 24,34 ----
  
  /* List object implementation */
  
+ #include <limits.h>
+ #ifdef roundup
+ #undef roundup
+ #endif
+ 
  #include "allobjects.h"
  #include "modsupport.h"
  #include "ceval.h"
***************
*** 555,562 ****
  	if (err_occurred())
  		return 0;
  
! 	if (comparefunc == NULL)
! 		return cmpobject(* (object **) v, * (object **) w);
  
  	/* Call the user-supplied comparison function */
  	t = mkvalue("(OO)", * (object **) v, * (object **) w);
--- 560,573 ----
  	if (err_occurred())
  		return 0;
  
! 	if (comparefunc == NULL) {
! 	        int cmp_result = cmpobject(* (object **) v, * (object **) w);
! 		if (cmp_result == INT_MIN && !err_occurred()) {
! 		    err_setstr(TypeError, "Illegal types for ordered comparison in sort");
! 		    return 0;
! 		}
! 		return cmp_result;
! 	}
  
  	/* Call the user-supplied comparison function */
  	t = mkvalue("(OO)", * (object **) v, * (object **) w);
*** Python//ceval.c.orig	Wed Oct 23 13:20:18 1996
--- Python//ceval.c	Thu Oct 24 10:51:51 1996
***************
*** 31,36 ****
--- 31,38 ----
     XXX document it!
     */
  
+ #include <limits.h>
+ 
  #include "allobjects.h"
  
  #include "compile.h"
***************
*** 2805,2810 ****
--- 2807,2818 ----
  		break;
  	default:
  		cmp = cmpobject(v, w);
+ 	        if (err_occurred()) 
+ 		    return NULL;
+ 		if (op != EQ && op != NE && cmp == INT_MIN) {
+ 		    err_setstr(TypeError, "Illegal types for ordered comparison");
+ 		    return NULL;
+ 		}
  		switch (op) {
  		case LT: res = cmp <  0; break;
  		case LE: res = cmp <= 0; break;
*** Python//bltinmodule.c.orig	Wed Oct 23 16:26:05 1996
--- Python//bltinmodule.c	Thu Oct 24 14:42:57 1996
***************
*** 24,29 ****
--- 24,30 ----
  
  /* Built-in functions */
  
+ #include <limits.h>
  #include "allobjects.h"
  
  #include "node.h"
***************
*** 229,238 ****
  	object *args;
  {
  	object *a, *b;
! 
  	if (!newgetargs(args, "OO:cmp", &a, &b))
  		return NULL;
! 	return newintobject((long)cmpobject(a, b));
  }
  
  static object *
--- 230,246 ----
  	object *args;
  {
  	object *a, *b;
! 	int cmp_result;
  	if (!newgetargs(args, "OO:cmp", &a, &b))
  		return NULL;
! 	cmp_result = cmpobject(a, b);
! 	if( err_occurred() )
! 	    return NULL;
! 	if(cmp_result == INT_MIN) {
! 	    INCREF(None);
! 	    return None;
! 	}
! 	return newintobject((long)cmp_result);
  }
  
  static object *







++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

=================
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  Thu Oct 24 21:35:23 1996
From: jim@ks.uiuc.edu (Jim Phillips)
Date: Thu, 24 Oct 96 15:35:23 -0500
Subject: [PYTHON MATRIX-SIG] zero-dimension array silliness
In-Reply-To: <9610241808.AA21827@goldilocks.LCS.MIT.EDU>
References: <9610241808.AA21827@goldilocks.LCS.MIT.EDU>
Message-ID: <199610242035.AA166699325@london.ks.uiuc.edu>

You wrote:
> > > Not true at all.  It is important to be able to create rank-0 arrays in
> > > order to do:
> > >
> > > array_of_floats * array(3.14159, Float32)
>
> I also want to be able to write a * array(3.14, a.typecode()) sometimes, so
> I need to be able to create them with any type.

OK, now this seems to me a very silly discussion.  The reason that the  
problem of zero dimension arrays (scalars) even comes up is that it was  
decided, for efficiency reasons, that automatically converting arrays is bad.   
This argument DOES NOT APPLY to converting scalars!!!

Therefore, I propose the following "common sense" (Republican?) solution:

1) array types must match - type conversions must be explicit
2) Python scalars are automatically converted to the correct type

This way, no one should ever need to explicitly make a zero-dimension array,  
especially since Python scalars are always the largest typecode available (I  
think).  Arrays are arrays, Python scalars are scalars, problem solved!  Also,  
you don't need strange idioms (a * array(3.14, a.typecode())) for scalar  
multiplication (3.14 * a).

-Jim Phillips
 jim@ks.uiuc.edu

=================
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  Fri Oct 25 01:19:29 1996
From: jim@ks.uiuc.edu (Jim Phillips)
Date: Thu, 24 Oct 96 19:19:29 -0500
Subject: [PYTHON MATRIX-SIG] arrays from text?
Message-ID: <199610250019.AA171292774@london.ks.uiuc.edu>

Hi,

Is there a way to (quickly) generate an array of numbers from an array of  
their string representations?  More specifically, if I have an array a of Char  
in which each row contains a printed representation of a Float, is there a  
faster way to get an array of Floats than the following?

array(map(lambda b: string.atof(b.tostring()), a))

Wouldn't it be nice if there were?  ;-)

Even better would be the ability to use the equivalent of FORTRAN format  
statements and implicit loops to read in several arrays of different types  
simultaneously from either a Char array or a file.  Anyone know how hard this  
would be to do?

Of course, the reason for doing this is that with array operations as fast as  
they are, the bottleneck in many programs will be the time needed to read in  
text files, which won't be any faster.

-Jim Phillips
 jim@ks.uiuc.edu

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From alistair@maths.uwa.edu.au  Fri Oct 25 03:08:43 1996
From: alistair@maths.uwa.edu.au (Alistair Mees)
Date: Fri, 25 Oct 1996 10:08:43 +0800
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
Message-ID: <199610250208.KAA07541@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>


ARRAY COMPARISONS

There has been quite a bit of discussion of array comparisons recently.  I
seem to have missed the early stages so perhaps this has all been dealt
with, but just in case...


Inequalities are often generalised to work for vectors and matrices.  For
example, x>=0 where x is a vector means x[i]>=0 for every i.
Unfortunately M>=0 where M is a matrix sometimes means the analogous thing
to x>=0 and sometimes means M is positive semi-definite.  Either of these
would presumably be implementable by defining suitable __cmp__ functions.

However, (and this is where I may be missing something obvious, or
something that is there already and I haven't understood), has anyone
considered adopting the Matlab convention: the result of A>=0 for any
array would be a boolean array of the same shape as A, and this could be
reduced to give the behaviour corresponding to x>=0 above if that is what
is wanted.



DETERMINANTS

There are much faster ways of calculating a determinant than taking the
product of its eigenvalues, for example by doing a single LR decomposition
or a single QR decomposition and then taking the products of the diagonal
elements of the triangular matrices.  (Eigenvalue extraction routines
perform many QR decompositions.)  Somewhere in LAPACK there are probably
at least half a dozen ways already programmed.  If you use a QR
decomposition you do have to check that the Q matrix is constructed in
such a way as to have determinant +1.  I apologise for merely pointing
this out and not volunteering to fix it.  Still, the number of times one
wants a determinant is actually quite small so I don't think the
inefficiency matters very much.



Alistair Mees


P.S.  

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Fri Oct 25 04:29:28 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Thu, 24 Oct 1996 22:29:28 -0500
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610250208.KAA07541@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
 (message from Alistair Mees on Fri, 25 Oct 1996 10:08:43 +0800)
Message-ID: <199610250324.XAA25560@python.org>


>ARRAY COMPARISONS
>
>There has been quite a bit of discussion of array comparisons recently.  I
>seem to have missed the early stages so perhaps this has all been dealt
>with, but just in case...
>
>
>Inequalities are often generalised to work for vectors and matrices.  For
>example, x>=0 where x is a vector means x[i]>=0 for every i.
>Unfortunately M>=0 where M is a matrix sometimes means the analogous thing
>to x>=0 and sometimes means M is positive semi-definite.  Either of these
>would presumably be implementable by defining suitable __cmp__ functions.

The problem is that __cmp__ can only validly return an integer. Notice
that for your first example that am array might be neither >=0 nor <0
([1,-1] comes to mind), so there's really no valid value to return.

>However, (and this is where I may be missing something obvious, or
>something that is there already and I haven't understood), has anyone
>considered adopting the Matlab convention: the result of A>=0 for any
>array would be a boolean array of the same shape as A, and this could be
>reduced to give the behaviour corresponding to x>=0 above if that is what
>is wanted.

Once again, only integers can be returned from __cmp__ (this is built
pretty solidly into the python core), so this isn't an option.

I'm working on a way to fix up __cmp__, so that a) exceptions
are handled correctly, and b) one can indicate inequality without
having to indicate ordering (i.e., [1,2,5,3] != [4,5,3,7] is
meaningful, but [1,2,5,3] < [4,5,3,7] probably isn't).

I've started to put together a description of the problem and how I'm
trying to fix it at http://dogbert.ece.uiuc.edu/~tim/cmp.html . It is
however, only about 1/3 written and probably chalk full of typos, so
be warned.

-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Fri Oct 25 10:21:56 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 10:21:56 +0100
Subject: [PYTHON MATRIX-SIG] Bug
In-Reply-To: <9610241808.AA21827@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610250927.KAA18719@ibs.ibs.fr>

> > and disallowing any
> > array-specific operations (especially indexing) on them, to make
> > them act just like scalar types?
> 
> This sounds like a good idea in general.  The one problem here is that I do
> want to provide some way to get the python value out of a scalar.  This is
> currently done by scalar[0].  This could also be done by scalar.tolist() I
> suppose.  I'd hate to add a special method just for this one highly unusual
> operation.

But scalar[0] is inconsistent - you can't index without having an axis.
The proper way to pick something from a rank-0 array (assuming we
want them to exist and behave like arrays) would be scalar[NewAxis][0]
or scalar.flat[0].

However, I see no reason for such trickery. If we decide to make rank-0
arrays act just like scalars, then the obvious way to extract a
"real" scalar would be int(scalar), float(scalar) etc.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Fri Oct 25 10:24:10 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 10:24:10 +0100
Subject: [PYTHON MATRIX-SIG] Bug
In-Reply-To: <9610241808.AA21827@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610250929.KAA18738@ibs.ibs.fr>

> > True. So how about allowing rank-0 arrays only for the types which
> > don't have scalar counterparts in Python, 
> 
> I also want to be able to write a * array(3.14, a.typecode()) sometimes, so
> I need to be able to create them with any type.

That expression would be allowd according to my proposal, but return
standard scalars if the typecode allows that.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Fri Oct 25 10:32:25 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 10:32:25 +0100
Subject: [PYTHON MATRIX-SIG] zero-dimension array silliness
In-Reply-To: <199610242035.AA166699325@london.ks.uiuc.edu> (message from Jim
 Phillips on Thu, 24 Oct 96 15:35:23 -0500)
Message-ID: <199610250938.KAA18883@ibs.ibs.fr>

> Therefore, I propose the following "common sense" (Republican?) solution:
> 
> 1) array types must match - type conversions must be explicit
> 2) Python scalars are automatically converted to the correct type

"Correct" being what? There has been a long discussion about the
coercion problem a few months ago, and in the end we agreed that
to avoid unpleasant surprises we would never allow "downgrading"
of precision silently. That means that when combining a Python
float (i.e. a double) with a short float array, the array will be
converted to double. And if that's not what you want, you need a
short float scalar, which doesn't exist - hence the need for
rank-0 arrays.

This seems an acceptable solution to me, since most people, and
especially beginners, would not use short floats anyway. And as long
as you keep your arrays limited to the types that Python has always
had, everything would work like before without tricks and nasty
surprises.

> you don't need strange idioms (a * array(3.14, a.typecode())) for scalar  
> multiplication (3.14 * a).

Such idioms are needed only in general library routines that should
work for all precisions.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Fri Oct 25 10:45:04 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 10:45:04 +0100
Subject: [PYTHON MATRIX-SIG] arrays from text?
In-Reply-To: <199610250019.AA171292774@london.ks.uiuc.edu> (message from Jim
 Phillips on Thu, 24 Oct 96 19:19:29 -0500)
Message-ID: <199610250950.KAA19003@ibs.ibs.fr>

> Is there a way to (quickly) generate an array of numbers from an array of  
> their string representations?  More specifically, if I have an array a of Char  
> in which each row contains a printed representation of a Float, is there a  
> faster way to get an array of Floats than the following?
> 
> array(map(lambda b: string.atof(b.tostring()), a))

Nothing I know of, and even the map() solution get more complicated
for arrays of higher rank. I do have a simple module that reads
rank-1 and rank-2 arrays from files (and reads them), but in terms
of efficiency it's even worse. I have decided more than once to do
a C module, but of course I never found the time.

> Even better would be the ability to use the equivalent of FORTRAN format  
> statements and implicit loops to read in several arrays of different types  
> simultaneously from either a Char array or a file.  Anyone know how hard this  
> would be to do?

Not too hard, but still a lot of work. Especially since I want such
a module to be able to read all reasonable representations for numbers,
including Fortran double precision (with a D instead of an E) and
Mathematica format (e.g. 2.5*10^3).

> Of course, the reason for doing this is that with array operations as fast as  
> they are, the bottleneck in many programs will be the time needed to read in  
> text files, which won't be any faster.

And that is exactly my observation in practice. I/O is frustratingly
slow!

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Fri Oct 25 12:01:44 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 12:01:44 +0100
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610250208.KAA07541@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
 (message from Alistair Mees on Fri, 25 Oct 1996 10:08:43 +0800)
Message-ID: <199610251107.MAA19602@ibs.ibs.fr>

> Inequalities are often generalised to work for vectors and matrices.  For
> example, x>=0 where x is a vector means x[i]>=0 for every i.

With such a definition, you could have an x for which both x > 0 and
x <=0 0 are false. But the __cmp__ function has to decide cleanly
between equal, greater, and less - there is nothing in between.

> However, (and this is where I may be missing something obvious, or
> something that is there already and I haven't understood), has anyone
> considered adopting the Matlab convention: the result of A>=0 for any
> array would be a boolean array of the same shape as A, and this could be
> reduced to give the behaviour corresponding to x>=0 above if that is what
> is wanted.

This is what the functions equal(), greater() etc. do. For the comparison
operators this doesn't work, since they have to return a single integer
(otherwise things like 'and' and 'or' wouldn't work the way they do now).

> There are much faster ways of calculating a determinant than taking the
> product of its eigenvalues, for example by doing a single LR decomposition

True, and if you submit a working replacement we will all be very happy.
I might do it if I find the time, but time is one of the things I am
a bit short of right now; the French government imposes a limit of
24h a day ;-)

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From alistair@maths.uwa.edu.au  Fri Oct 25 11:13:36 1996
From: alistair@maths.uwa.edu.au (Alistair Mees)
Date: Fri, 25 Oct 1996 18:13:36 +0800
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
Message-ID: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>



tim@lassi.ece.uiuc.edu writes:
 > 
 > >ARRAY COMPARISONS
 > >
 > >There has been quite a bit of discussion of array comparisons recently.  I
 > >seem to have missed the early stages so perhaps this has all been dealt
 > >with, but just in case...
 > >
 > >
 > >Inequalities are often generalised to work for vectors and matrices.  For
 > >example, x>=0 where x is a vector means x[i]>=0 for every i.
 > >Unfortunately M>=0 where M is a matrix sometimes means the analogous thing
 > >to x>=0 and sometimes means M is positive semi-definite.  Either of these
 > >would presumably be implementable by defining suitable __cmp__ functions.
 > 
 > The problem is that __cmp__ can only validly return an integer. Notice
 > that for your first example that am array might be neither >=0 nor <0
 > ([1,-1] comes to mind), so there's really no valid value to return.
That is not a problem.  The answer to "is [1,-1]>=0" is "no" so you return
0, as you do for the comparisons [1,-1]<=0, [1,-1]>0 and [1,-1]<0.  These
are standard elementary results!  Likewise, if we are working with
symmetric matrices then A>=B and A<=B can both return 0 (since they are
equivalent to A-B>=0 and A-B<=0, neither of which might be true if we
decide to define the inequalities to be statements about positive
semidefiniteness.

It seems to me that one of the reasons APL never made it was that it
insisted on talking its own language which was internally self-consistent
but had little to do with any language talked by others.  Conversely,
Matlab, with its horrid "bad Fortran" syntax, is very popular in part
because it never strays really far from standard notation.  If we are to
sell NumPy to users, shouldn't we try to make the operators mean what
typical users will expect them to mean, or will learn that they mean in
mathematics courses, rather than defining them to be something completely
different?

The natural place for M>=0 to mean M is positive semidefinite would be in
Matrix, would it not?  This is in any case a less important point.  The
natural place for x>=0 to be defined for rank 1 arrays x (assuming we are
stuck with single integer returns) is in Numeric.  It would be consistent
to use the same definition with any rank of array, assuming __cmp__ is too
rigidly defined to allow an array result.


Alistair



=================
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 Oct 25 13:55:38 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 13:55:38 +0100
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
 (message from Alistair Mees on Fri, 25 Oct 1996 18:13:36 +0800)
Message-ID: <199610251301.OAA20153@ibs.ibs.fr>

> That is not a problem.  The answer to "is [1,-1]>=0" is "no" so you return
> 0, as you do for the comparisons [1,-1]<=0, [1,-1]>0 and [1,-1]<0.  These

But that's not how Python does comparisons. An expression like "a<b"
is turned into "cmp(a,b)==-1", and only the function cmp() is
implemented for each data type. Mathematically that means assuming an
ordering relation with the usual properties for all types.

Of course the best solution would be to give up this strategy and
implement all the comparison operators independently. With some
effort that could even be done in a backwards compatible way (i.e.
using the old strategy for types defining cmp()). But that is far
from a trivial change.

> It seems to me that one of the reasons APL never made it was that it
> insisted on talking its own language which was internally self-consistent
> but had little to do with any language talked by others.  Conversely,
> Matlab, with its horrid "bad Fortran" syntax, is very popular in part

I suppose APL's main problem was the use of a special character set.
Even modern GUIs don't solve all the difficulties associated with
it. Look at comp.lang.apl to see what people are doing to publish
APL code on Usenet - it's a mess!

> because it never strays really far from standard notation.  If we are to
> sell NumPy to users, shouldn't we try to make the operators mean what
> typical users will expect them to mean, or will learn that they mean in
> mathematics courses, rather than defining them to be something completely
> different?

I agree, but there's no way to do that with Python 1.4. And perhaps
not even with Python 1.5 or whatever comes next.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From fredrik_lundh@ivab.se  Fri Oct 25 13:50:46 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Fri, 25 Oct 1996 14:50:46 +0200
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251301.OAA20153@ibs.ibs.fr> (message from Konrad Hinsen on
 Fri, 25 Oct 96 13:55:38 +0100)
Message-ID: <9610251250.AA25848@arnold.image.ivab.se>


Konrad writes:
> Of course the best solution would be to give up this strategy and
> implement all the comparison operators independently. With some
> effort that could even be done in a backwards compatible way (i.e.
> using the old strategy for types defining cmp()).

Agreed.  I have several applications where such a change would be
really useful (like using Python classes to build expression trees for
later execution within subsystems; operations on images, for example).

> But that is far from a trivial change.

Not sure about that, really (thought it might add some overhead for
classes that only implements __cmp__).  Is definitely worth
investigating for 1.5.

Regards	/F

=================
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  Fri Oct 25 13:50:46 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Fri, 25 Oct 1996 14:50:46 +0200
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251301.OAA20153@ibs.ibs.fr> (message from Konrad Hinsen on
 Fri, 25 Oct 96 13:55:38 +0100)
Message-ID: <9610251250.AA25848@arnold.image.ivab.se>


Konrad writes:
> Of course the best solution would be to give up this strategy and
> implement all the comparison operators independently. With some
> effort that could even be done in a backwards compatible way (i.e.
> using the old strategy for types defining cmp()).

Agreed.  I have several applications where such a change would be
really useful (like using Python classes to build expression trees for
later execution within subsystems; operations on images, for example).

> But that is far from a trivial change.

Not sure about that, really (thought it might add some overhead for
classes that only implements __cmp__).  Is definitely worth
investigating for 1.5.

Regards	/F

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Fri Oct 25 14:27:46 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Fri, 25 Oct 1996 08:27:46 -0500
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
 (message from Alistair Mees on Fri, 25 Oct 1996 18:13:36 +0800)
Message-ID: <199610251323.JAA27023@python.org>


> = Alistair Mees
> > = Tim Hochberg

<...>

> > The problem is that __cmp__ can only validly return an integer. Notice
> > that for your first example that am array might be neither >=0 nor <0
> > ([1,-1] comes to mind), so there's really no valid value to return.

>That is not a problem.  The answer to "is [1,-1]>=0" is "no" so you return
>0, as you do for the comparisons [1,-1]<=0, [1,-1]>0 and [1,-1]<0.  These
>are standard elementary results!  Likewise, if we are working with
>symmetric matrices then A>=B and A<=B can both return 0 (since they are
>equivalent to A-B>=0 and A-B<=0, neither of which might be true if we
>decide to define the inequalities to be statements about positive
>semidefiniteness.

I don't entirely disagree that this is a reasonable solution in
principle, although I tend to think the correct answer to [-1,1]>=0 is
"undefined" and so you should get an exception. 

However, the comparison operators (<=, >, etc.) are just veneer on top
of __cmp__ (or tp_compare for C classes). If I do cmp(a,b) I get back
an integer: if its positive, >, >=, and != return true, if 0, ==, >=,
<= return true and if negative, <, <=, or != return true.

For cmp([1,-1],0) I want >, >=, <, and <= to raise an exception (or be
false for your semantics), I want == to be false, and != to be
true. What integer do you return for that? None ;) (at least in the
future - hopefully)

With the patch I'm working on, returning None in Python or INT_MIN
(sorry) in C will tell the veneer that the objects compared are not
equal but don't have an ordering. (This is in general, not just for
the Numerics extension.) This could be used to either raise an
exception if you try to order them or to return false for all the
ordering operators (<,<=,>,>=). However, I much prefer the former, if
you want to make questionable comparisons you should have to do it
explicitly!!


-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From mclay@nist.gov  Fri Oct 25 09:48:38 1996
From: mclay@nist.gov (Michael McLay)
Date: Fri, 25 Oct 1996 04:48:38 -0400
Subject: [PYTHON MATRIX-SIG] arrays from text?
In-Reply-To: <199610250950.KAA19003@ibs.ibs.fr>
References: <199610250019.AA171292774@london.ks.uiuc.edu>
 <199610250950.KAA19003@ibs.ibs.fr>
Message-ID: <199610250848.EAA05050@fermi.eeel.nist.gov>

Konrad Hinsen writes:
 > > Is there a way to (quickly) generate an array of numbers from an array of  
 > > their string representations?  More specifically, if I have an array a of Char  
 > > in which each row contains a printed representation of a Float, is there a  
 > > faster way to get an array of Floats than the following?
 > > 
 > > array(map(lambda b: string.atof(b.tostring()), a))
 > 
 > Nothing I know of, and even the map() solution get more complicated
 > for arrays of higher rank. I do have a simple module that reads
 > rank-1 and rank-2 arrays from files (and reads them), but in terms
 > of efficiency it's even worse. I have decided more than once to do
 > a C module, but of course I never found the time.
 > 
 > > Even better would be the ability to use the equivalent of FORTRAN format  
 > > statements and implicit loops to read in several arrays of different types  
 > > simultaneously from either a Char array or a file.  Anyone know how hard this  
 > > would be to do?
 > 
 > Not too hard, but still a lot of work. Especially since I want such
 > a module to be able to read all reasonable representations for numbers,
 > including Fortran double precision (with a D instead of an E) and
 > Mathematica format (e.g. 2.5*10^3).

How about ftp://ftp.python.org/pub/python/contrib/Misc/sscanfmodule.c.  
It probably needs to be modified to read in arrays.  I think it just
returns tuples that correspond to the parse string.  


 > > Of course, the reason for doing this is that with array operations as fast as  
 > > they are, the bottleneck in many programs will be the time needed to read in  
 > > text files, which won't be any faster.
 > 
 > And that is exactly my observation in practice. I/O is frustratingly
 > slow!
 > 
 > Konrad.
 > -- 
 > -------------------------------------------------------------------------------
 > Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
 > Laboratoire de Dynamique Moleculaire   | Tel.: +33-76.88.99.28
 > Institut de Biologie Structurale       | Fax:  +33-76.88.54.94
 > 41, av. des Martyrs                    | Deutsch/Esperanto/English/
 > 38027 Grenoble Cedex 1, France         | Nederlands/Francais
 > -------------------------------------------------------------------------------
 > 
 > =================
 > MATRIX-SIG  - SIG on Matrix Math for Python
 > 
 > send messages to: matrix-sig@python.org
 > administrivia to: matrix-sig-request@python.org
 > =================

=================
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 Oct 25 16:09:59 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 16:09:59 +0100
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <9610251250.AA25848@arnold.image.ivab.se> (message from Fredrik
 Lundh on Fri, 25 Oct 1996 14:50:46 +0200)
Message-ID: <199610251515.QAA21237@ibs.ibs.fr>

> > But that is far from a trivial change.
> 
> Not sure about that, really (thought it might add some overhead for
> classes that only implements __cmp__).  Is definitely worth
> investigating for 1.5.

Of course. I expect the main problem to be types implemented in C.
They'd need new methods too, but in such a way that previously written
code would still work. But in my opinion it is worth even a major
effort.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From chris.chase@jhuapl.edu  Fri Oct 25 16:07:06 1996
From: chris.chase@jhuapl.edu (Chris Chase SRM)
Date: Fri, 25 Oct 1996 11:07:06 -0400
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251323.JAA27023@python.org>
References: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
 <199610251323.JAA27023@python.org>
Message-ID: <199610251510.LAA27375@python.org>

>>>>> "tim" == tim  <tim@lassi.ece.uiuc.edu> writes:

>> = Alistair Mees
>> > = Tim Hochberg

tim> <...>

>> > The problem is that __cmp__ can only validly return an integer. Notice
>> > that for your first example that am array might be neither >=0 nor <0
>> > ([1,-1] comes to mind), so there's really no valid value to return.

>> That is not a problem.  The answer to "is [1,-1]>=0" is "no" so you return
>> 0, as you do for the comparisons [1,-1]<=0, [1,-1]>0 and [1,-1]<0.  These
>> are standard elementary results!  Likewise, if we are working with
>> symmetric matrices then A>=B and A<=B can both return 0 (since they are
>> equivalent to A-B>=0 and A-B<=0, neither of which might be true if we
>> decide to define the inequalities to be statements about positive
>> semidefiniteness.

tim> I don't entirely disagree that this is a reasonable solution in
tim> principle, although I tend to think the correct answer to [-1,1]>=0 is
tim> "undefined" and so you should get an exception. 

tim> However, the comparison operators (<=, >, etc.) are just veneer on top
tim> of __cmp__ (or tp_compare for C classes). If I do cmp(a,b) I get back
tim> an integer: if its positive, >, >=, and != return true, if 0, ==, >=,
tim> <= return true and if negative, <, <=, or != return true.

tim> For cmp([1,-1],0) I want >, >=, <, and <= to raise an exception (or be
tim> false for your semantics), I want == to be false, and != to be
tim> true. What integer do you return for that? None ;) (at least in the
tim> future - hopefully)

tim> With the patch I'm working on, returning None in Python or INT_MIN
tim> (sorry) in C will tell the veneer that the objects compared are not
tim> equal but don't have an ordering. (This is in general, not just for
tim> the Numerics extension.) This could be used to either raise an
tim> exception if you try to order them or to return false for all the
tim> ordering operators (<,<=,>,>=). However, I much prefer the former, if
tim> you want to make questionable comparisons you should have to do it
tim> explicitly!!

I agree with Tim's approach.  Raise an exception when two objects are
not comparable.

The implicit assumption in Python seems to be that cmp() implements a
_complete_ partial order relation [a relation that is reflexive,
transitive, and anti-symmetric, and comparable: a <= b or b <= a].

Supporting a partial order relation [dropping comparable property]
requires an exception be produced by cmp().

For arrays (finite dimensional vector spaces) the natural partial
order was mentioned by Alstair Mess ( a >= b iff a-b > 0
componentwise).  This partial order is an often used requirement in
many constrained optimization of convex functions.  Other partial
orders might be defined (e.g. Alstair mentioned positive semidefinite
for matrices).

Certain operations like sorting assume a complete order relation (or a
"chain" which is a completely ordered subset of a partial ordered
set).  Would it be a problem if an exception was generated inside
these kind of operations?

Chris

=================
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  Fri Oct 25 17:14:39 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Fri, 25 Oct 1996 09:14:39 -0700
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610251107.MAA19602@ibs.ibs.fr>
References: <199610250208.KAA07541@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
 <199610251107.MAA19602@ibs.ibs.fr>
Message-ID: <199610251616.MAA27563@python.org>

Konrad Hinsen writes:
 > > Inequalities are often generalised to work for vectors and matrices.  For
 > > example, x>=0 where x is a vector means x[i]>=0 for every i.
 > 
 > With such a definition, you could have an x for which both x > 0 and
 > x <=0 0 are false. But the __cmp__ function has to decide cleanly
 > between equal, greater, and less - there is nothing in between.

And Tim Hochberg writes:
 > The problem is that __cmp__ can only validly return an integer. Notice
 > that for your first example that am array might be neither >=0 nor <0
 > ([1,-1] comes to mind), so there's really no valid value to return.

The original poster's request has a utility which I think is being
missed.  The goal of expecting x >= 0 (or any other operator) to mean
x[i] >= 0 for every i, is not to get back a truth value, it is to get
back a boolean mask.  Data parallel languages of many stripes and
colors have historically allowed constructs like

<array declaration a, b, c>

where( a > 0) b = c

if (a > 0) b = c        (means the same thing)

a = b > c		(creates a "vector mask")

x = a * <complex function>	(selects complex function only for
				elements where b > c)

I do not yet know if I can think of a reason why I would want to do
exactly this in Python, but that is what the request means to me.
Seen in this light, it is of absolutely no consequence whether x =
[1,-1], or any other curious arrangement of elements, since the goal
is not to get back a single boolean for use in a scalar conditional,
but a vector mask for use in array expressions.

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

=================
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  Fri Oct 25 17:19:46 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Fri, 25 Oct 1996 09:19:46 -0700
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
References: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
Message-ID: <199610251621.MAA27586@python.org>

Alistair Mees writes:
 > tim@lassi.ece.uiuc.edu writes:
 >  > >ARRAY COMPARISONS
 >  > >
 >  > >There has been quite a bit of discussion of array comparisons
 >  > >recently.  I seem to have missed the early stages so perhaps
 >  > >this has all been dealt with, but just in case...
 >  > >
 >  > >
 >  > >Inequalities are often generalised to work for vectors and
 >  > >matrices.  For example, x>=0 where x is a vector means x[i]>=0
 >  > >for every i.  Unfortunately M>=0 where M is a matrix sometimes
 >  > >means the analogous thing to x>=0 and sometimes means M is
 >  > >positive semi-definite.  Either of these would presumably be
 >  > >implementable by defining suitable __cmp__ functions.
 >  > 
 >  > The problem is that __cmp__ can only validly return an
 >  > integer. Notice that for your first example that am array might
 >  > be neither >=0 nor <0 ([1,-1] comes to mind), so there's really
 >  > no valid value to return.
 > That is not a problem.  The answer to "is [1,-1]>=0" is "no" so you

I would expect in an array language that the answer to 
	"is [1,-1]>=0" 
would be
	"[1, -1]"

 > It seems to me that one of the reasons APL never made it was that it
 > insisted on talking its own language which was internally self-consistent
 > but had little to do with any language talked by others.  Conversely,
 > Matlab, with its horrid "bad Fortran" syntax, is very popular in part
 > because it never strays really far from standard notation.  If we are to
 > sell NumPy to users, shouldn't we try to make the operators mean what
 > typical users will expect them to mean, or will learn that they mean in
 > mathematics courses, rather than defining them to be something completely
 > different?

Well, if I'm the "typical Joe" in this example, your interpretation
certainly seems unfamiliar.  The "vector mask" analogy is more common
in my experience.  For reference: I've never used Matlab.

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

=================
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 Oct 25 17:25:35 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 25 Oct 1996 12:25:35 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610251616.MAA27563@python.org> from "Geoffrey Furnish" at Oct 25, 96 09:14:39 am
Message-ID: <199610251625.MAA29941@maigret>

> The original poster's request has a utility which I think is being
> missed.  The goal of expecting x >= 0 (or any other operator) to mean
> x[i] >= 0 for every i, is not to get back a truth value, it is to get
> back a boolean mask.  Data parallel languages of many stripes and
> colors have historically allowed constructs like
> 
> <array declaration a, b, c>
> where( a > 0) b = c
> if (a > 0) b = c        (means the same thing)
> a = b > c		(creates a "vector mask")
> x = a * <complex function>	(selects complex function only for
> 				elements where b > c)
> 
> I do not yet know if I can think of a reason why I would want to do
> exactly this in Python, but that is what the request means to me.
> Seen in this light, it is of absolutely no consequence whether x =
> [1,-1], or any other curious arrangement of elements, since the goal
> is not to get back a single boolean for use in a scalar conditional,
> but a vector mask for use in array expressions.

Isn't that what the ufuncs provide?

>>> b
 0.          0.84147098  0.90929743  0.14112001 -0.7568025 
-0.95892427 -0.2794155   0.6569866   0.98935825  0.41211849
-0.54402111 -0.99999021 -0.53657292  0.42016704  0.99060736
 0.65028784 -0.28790332 -0.96139749 -0.75098725  0.14987721
 0.91294525  0.83665564 -0.00885131 -0.8462204  -0.90557836
>>> greater_equal(b, 0)
1 1 1 1 0
0 0 1 1 1
0 0 0 1 1
1 0 0 0 1
1 1 0 0 0

>>> choose(greater_equal(b, 0), (b, -b))
 0.         -0.84147098 -0.90929743 -0.14112001 -0.7568025 
-0.95892427 -0.2794155  -0.6569866  -0.98935825 -0.41211849
-0.54402111 -0.99999021 -0.53657292 -0.42016704 -0.99060736
-0.65028784 -0.28790332 -0.96139749 -0.75098725 -0.14987721
-0.91294525 -0.83665564 -0.00885131 -0.8462204  -0.90557836



=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From tim@lassi.ece.uiuc.edu  Fri Oct 25 18:29:55 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Fri, 25 Oct 1996 12:29:55 -0500
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610251616.MAA27563@python.org> (message from Geoffrey Furnish
 on Fri, 25 Oct 1996 09:14:39 -0700)
Message-ID: <199610251725.NAA27857@python.org>


Geoffrey Furnish = G>
Konrad Hinsen    = K>
Fredrik Lundh    = F>

G>The original poster's request has a utility which I think is being
G>missed.  The goal of expecting x >= 0 (or any other operator) to mean
G>x[i] >= 0 for every i, is not to get back a truth value, it is to get
G>back a boolean mask.

The point is not that I (we) think this is a bad idea (I do, but am
willing to be convinced), just that its not possible without a
nontrivial revamping of the python core.

K> But that is far from a trivial change.

F>Not sure about that, really (thought it might add some overhead for
F>classes that only implements __cmp__).  Is definitely worth
F>investigating for 1.5.

I agree that this probably wouldn't be that hard. However, I'm not
convinced yet that generalizing the comparison ops would be a "good
thing". My current thinking is that using ufuncs would be better -
keep the comparison ops as returning boolean values.

In any event, I think the important question is what functionality we
give cmp NOW for array objects.

1) We can go ahead and make ==/!= work now as returning 1/0 for arrays
where all elements are equal and 0/1 where they're not. 

2) We can deliberately cripple cmp so that it does nothing
useful. This leaves the door open doing something fancy involving
returning arrays later if __equal__, __lessthan__, etc. show up at a
later date..

If we do 1), we're locked into using the comparison operators to
return boolean values. I personally think this is the right way to go.
If we decide later we need the array mask functioniality we can stick
it in a subclass of array (surely by then arrays will be an extension
class...).

If we do 2), we really should have a boolean function that operates on
arrays and tells us if they're the same, i.e:

if not identical(A1, A2):
	do_some_stuff(A1, A2)


-- 
	-tim

+--------------------------------------------------------------------+
| Tim Hochberg               Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu              University of Illinois         |
| http://dogbert.ece.uiuc.edu/~tim         (217) 333-6014            |
+--------------------------------------------------------------------+

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Fri Oct 25 19:28:04 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 25 Oct 1996 14:28:04 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610251758.NAA02334@maigret> from "Geoffrey Furnish" at Oct 25, 96 10:57:53 am
Message-ID: <199610251828.OAA02409@maigret>

> This looks good to me, in terms of functionality.  I would like the
> syntactic sugar of having these functions map to the operators,
> though.  (Well, stated better, of having the operators map to this
> functionality). 

I agree from the perspective of someone who has played a bit with S+.
However, I think it's not compatible with the current semantics of 
Python comparison operators, which have implicit the notion of a strict
order relation.  It would be nice, though...  Maybe a revamp of how
comparison operators works which was backwards compatible and would
allow this feature is possible.  Out of my league, though.

--david

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From da@maigret.cog.brown.edu  Fri Oct 25 19:28:04 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Fri, 25 Oct 1996 14:28:04 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610251758.NAA02334@maigret> from "Geoffrey Furnish" at Oct 25, 96 10:57:53 am
Message-ID: <199610251828.OAA02409@maigret>

> This looks good to me, in terms of functionality.  I would like the
> syntactic sugar of having these functions map to the operators,
> though.  (Well, stated better, of having the operators map to this
> functionality). 

I agree from the perspective of someone who has played a bit with S+.
However, I think it's not compatible with the current semantics of 
Python comparison operators, which have implicit the notion of a strict
order relation.  It would be nice, though...  Maybe a revamp of how
comparison operators works which was backwards compatible and would
allow this feature is possible.  Out of my league, though.

--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 Oct 25 22:26:38 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 25 Oct 1996 17:26:38 -0400
Subject: [PYTHON MATRIX-SIG] Bug
Message-ID: <9610252138.AB15818@goldilocks.LCS.MIT.EDU>


> But scalar[0] is inconsistent - you can't index without having an axis.
> The proper way to pick something from a rank-0 array (assuming we
> want them to exist and behave like arrays) would be scalar[NewAxis][0]
> or scalar.flat[0].
> 
> However, I see no reason for such trickery. If we decide to make rank-0
> arrays act just like scalars, then the obvious way to extract a
> "real" scalar would be int(scalar), float(scalar) etc.

You're definately right on this one (and happily it will make that strange
scalar slicing bug go away too :-).  I'll completely eliminate indexing on
scalar arrays, and add proper implementations for them to convert to int
and float (and complex).

-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 Oct 25 22:29:25 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Fri, 25 Oct 1996 17:29:25 -0400
Subject: [PYTHON MATRIX-SIG] package, ni, and Numeric
Message-ID: <9610252138.AB15818@goldilocks.LCS.MIT.EDU>


> From: Jim Phillips <jim@ks.uiuc.edu>
> After Numeric's brief interlude with packages and ni, I have to agree
that ni  
> is not ready for prime time.  At the very least, packages should be a  
> mandatory extension to the import methods, not an extra import that
changes  
> system functionality for everything.
> 
> Anyway, I now notice that Numeric is fundamentally incompatible with ni  
> because it usually resides in a subdirectory of a valid path with the
same  
> name as the module.  Thus, when ni is imported, it attempts to import
Numeric  

In the next release, the Numeric directory will be renamed to NumPy if
nobody has any objections.  I don't imagine that this could possibly cause
anybody any problems, and it will allow compatibility with "ni" using
modules.

-Jim

=================
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  Sat Oct 26 02:14:42 1996
From: Zachary_Roadhouse@brown.edu (Zachary_Roadhouse@brown.edu)
Date: Fri, 25 Oct 1996 21:14:42 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Bump the version to handle 1.4
Message-ID: <XFMail.961025211656.Zachary_Roadhouse@brown.edu>


Would it be possible to bump to b6 or something to handle the
change from PyEllipses to Ellipsis?

     - Zack

E-MAIL: Zachary_Roadhouse@brown.edu  WEB: http://www.lems.brown.edu/~zack
Box 220, Brown University, 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 hugunin@mit.edu  Sat Oct 26 06:45:36 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Sat, 26 Oct 1996 01:45:36 -0400
Subject: [PYTHON MATRIX-SIG] Bump the version to handle 1.4
Message-ID: <9610260556.AA19300@goldilocks.LCS.MIT.EDU>


> Would it be possible to bump to b6 or something to handle the
> change from PyEllipses to Ellipsis?

That's exactly my plan for a6 (note, still alpha, not beta yet ;-)  I guess
this means Guido managed to release 1.4final today?  You can expect
NumPy1.0a6 to be out before the end of next week (and it will work properly
with 1.4final).

-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  Sun Oct 27 10:22:17 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sun, 27 Oct 96 10:22:17 GMT
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610251725.NAA27857@python.org> (tim@lassi.ece.uiuc.edu)
Message-ID: <199610271027.LAA25077@ibs.ibs.fr>

> 1) We can go ahead and make ==/!= work now as returning 1/0 for arrays
> where all elements are equal and 0/1 where they're not. 
> 
> 2) We can deliberately cripple cmp so that it does nothing
> useful. This leaves the door open doing something fancy involving
> returning arrays later if __equal__, __lessthan__, etc. show up at a
> later date..
> 
> If we do 1), we're locked into using the comparison operators to
> return boolean values. I personally think this is the right way to go.

I agree. If we were designing Python from scratch, I'd certainly
favour giving comparisons an array result. Within Python as it is,
this would not only be difficult to implement, but inconsistent with
other existing data types (such as lists), which we can't change for
compatibility reasons.

If __cmp__ ever gets replaced by individual __less__, __greater__ etc.,
we can still give all those a useful meaning (as long as the result
is a boolean). For now, equality test is already useful (for integer
arrays more than for floats), and eliminates nasty surprises caused by
the address comparison strategy we currently have.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jim@ks.uiuc.edu  Sun Oct 27 22:48:53 1996
From: jim@ks.uiuc.edu (Jim Phillips)
Date: Sun, 27 Oct 96 16:48:53 -0600
Subject: [PYTHON MATRIX-SIG] simple patch so ni doesn't break Numeric
Message-ID: <199610272248.AA280626534@london.ks.uiuc.edu>

Hi,

Well, patching ni.py to not break Numeric was easy enough:

187c187
<           if self.hooks.path_isdir(dirname):
---
>           if self.hooks.path_isdir(dirname) and dirname not in sys.path:

-Jim Phillips
 jim@ks.uiuc.edu

=================
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 Oct 28 11:02:28 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 28 Oct 96 11:02:28 GMT
Subject: [PYTHON MATRIX-SIG] Diagonals and traces
Message-ID: <199610281107.MAA27627@ibs.ibs.fr>

I have made an attempt at producing a more useful version and
diagonal() (and added the trivial trace()), which I herewith
submit to the scrutiny of the high court ;-)

Features: It takes two axis numbers (defaulting to 0 and 1) plus an
offset (defaulting to zero) for picking the parallels. Its return
value has a rank of one less then the input, and its first axis
corresponds to the diagonal, i.e. it equals
array([a[0,0], a[1,1], ...]), assuming the default axis values.

This version is incompatible with the current one in two respects:

1) In case you want diagonal-parallels, you have to specify the
   axis arguments.

2) For arrays of rank > 2, you have to be aware of the different
   axis defaults (-2 and -1 in Numeric, 0 and 1 in my version)
   and the different return value (diagonal along axis -1 in
   Numeric, along 0 in my version). This choice is more consistent
   with the other structural operations, which default to axis=0.

And here's the code:

------------------------------------------------------------
def diagonal(a, axis1=0, axis2=1, offset=0):
    a = array(a)
    if axis2 < axis1: axis1, axis2 = axis2, axis1
    if axis2 > 1:
	new_axes = range(len(a.shape))
	del new_axes[axis2]; del new_axes[axis1]
	new_axes[0:0] = [axis1, axis2]
	a = transpose(a, new_axes)
    s = a.shape
    n1 = s[0]
    n2 = s[1]
    n = n1*n2
    s = (n,) + s[2:]
    a = reshape(a, s)
    if offset < 0: offset = n2-offset-1
    return take(a, arange(offset, n, n2+1), 0)

def trace(a, axis1=0, axis2=1, offset=0):
    return add.reduce(diagonal(a, axis1, axis2, offset))
------------------------------------------------------------

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Mon Oct 28 13:56:18 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 28 Oct 96 13:56:18 GMT
Subject: [PYTHON MATRIX-SIG] Nested list representation of an array
Message-ID: <199610281401.PAA28533@ibs.ibs.fr>

Does anyone know an efficient way to obtain a nested list
representation of an array? list() will handle only the first
axis. The best I can come up with is a recursive definition:

def nested_list(a):
  if len(a.shape) < 2:
    return list(a)
  else:
    return map(nested_list, a)

I don't want to know how long this takes for a large rank-10 array...

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From gathmann@banks.scar.utoronto.ca  Mon Oct 28 13:07:04 1996
From: gathmann@banks.scar.utoronto.ca (Oliver Gathmann)
Date: Mon, 28 Oct 1996 08:07:04 -0500
Subject: [Fwd: Re: [PYTHON MATRIX-SIG] Problems building alpha5 (Linux)]
Message-ID: <3274AFF8.7A2D@banks.scar.utoronto.ca>

David Ascher wrote:
> 
> > > From: Oliver Gathmann <gathmann@scar.utoronto.ca>
> > >
> > > I have trouble with your last Friday release (alpha5): On my Linux box,
> > > (Linux 2.0, gcc 2.7.0) I keep getting "unresolved symbol" errors when
> > > trying to import math,cmath,time,regex and other standard Python modules
> > -
> > > which I didn't get before. Linking against the math library helps for
> > math
> > > and cmath, but not for the other modules. Do you have an idea what's
> > wrong
> > > there?
> >
> > Anybody else recognize this problem (particularly all of you out there
> > who've buit alpha5 under linux?)  I can't really imagine what's going wrong
> > here.
> 
> No, I had no problems.  Was it a static build or a dynamic build?
> 
> --david
A dynamic build. All problems disappeared when I built the package on my
home Linux box - same configuration, same Setup file, but gcc2.7.2
instead of gcc2.7.0. I guess it's not worth spending the time to figure
out what went wrong...
Oliver

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From chris.chase@jhuapl.edu  Mon Oct 28 17:13:11 1996
From: chris.chase@jhuapl.edu (Chris Chase SRM)
Date: Mon, 28 Oct 1996 12:13:11 -0500
Subject: [PYTHON MATRIX-SIG] Find/where function
Message-ID: <199610281715.MAA12714@python.org>


I would like to see the following convenience function added for
returning the indices of nonzero array elements.  I would prefer to
call this "where" instead of "find" but "where" is already taken.

def find(a):
    return compress(a.flat,arange(product(a.shape)))

Example,

b = reshape(arange(24),(2,3,4))
find(b%2)

Chris

=================
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 Oct 28 17:55:04 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 28 Oct 1996 12:55:04 -0500
Subject: [PYTHON MATRIX-SIG] Nested list representation of an array
Message-ID: <9610281801.AA24627@goldilocks.LCS.MIT.EDU>

> Does anyone know an efficient way to obtain a nested list
> representation of an array? list() will handle only the first
> axis. The best I can come up with is a recursive definition:

Not sure this is in the docs yet, but a.tolist() will do what you want
quite efficiently.

-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 Oct 28 18:05:37 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 28 Oct 1996 13:05:37 -0500
Subject: [PYTHON MATRIX-SIG] Find/where function
Message-ID: <9610281805.AA24678@goldilocks.LCS.MIT.EDU>


> I would like to see the following convenience function added for
> returning the indices of nonzero array elements.  I would prefer to
> call this "where" instead of "find" but "where" is already taken.
> 
> def find(a):
>     return compress(a.flat,arange(product(a.shape)))
> 
> Example,
> 
> b = reshape(arange(24),(2,3,4))
> find(b%2)

This is almost equivalent to the current behavior of nonzero (the only
difference is that your version works on non-flattened arrays).  I'm a
little bit confused as to how this can possibly make sense for
multi-dimensional arrays, but if it does, I think it should involve an
extension of the existing nonzero function, rather than adding a new
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 da@maigret.cog.brown.edu  Mon Oct 28 18:15:41 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Mon, 28 Oct 1996 13:15:41 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] Nested list representation of an array
In-Reply-To: <9610281801.AA24627@goldilocks.LCS.MIT.EDU> from "Jim Hugunin" at Oct 28, 96 12:55:04 pm
Message-ID: <199610281815.NAA05240@maigret>

> > Does anyone know an efficient way to obtain a nested list
> > representation of an array? list() will handle only the first
> > axis. The best I can come up with is a recursive definition:
> 
> Not sure this is in the docs yet, but a.tolist() will do what you want
> quite efficiently.

Yup:

`a.tolist()'
------------

Calling an array's `tolist()' method returns a hierarchical python list
version of the same array:
     >>> a
     0 1 2
     3 4 5
     6 7 8
     >>> a.tolist()
     [[0, 1, 2], [3, 4, 5], [6, 7, 8]]



=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From chris.chase@jhuapl.edu  Tue Oct 29 02:33:44 1996
From: chris.chase@jhuapl.edu (Chris Chase SRM)
Date: Mon, 28 Oct 1996 21:33:44 -0500
Subject: [PYTHON MATRIX-SIG] scalars and arrays
Message-ID: <199610290236.VAA17271@python.org>


I am having a difficult time conceptually with the equivalence of
scalars and rank-0 arrays.  So far, my problem is with functions that
take some kind of index vector.  I would like the user [of course I am
the only user of my functions currently :-)] to be able to specify a
scalar or a rank 1 vector and have them treated the same.  So I end up
using if statements to always check for a scalar.  For example, with
take():

v - a scalar or sequence object
a - array

ind = array(v)
if len(ind.shape) == 0:
    x = take(a,[v])
else:
    x = take(a,ind)

Similarly, there are times when I don't want a scalar index to reduce
the rank of an array which requires: a[v:v,other_indexes]

Is there a better way to test for a scalar versus a sequence?

I have thought about writing a convience function similar to asarray()
with the only difference being it returns scalars as rank-1 arrays.

I think I understand the consistency part of Konrad's eplanations
(going back through the list archive) for the scalars/rank-0 issue.  I
guess my difficulty is that in all my programming the past 7 years in
Matlab and IDL scalars can be indexed and treated as arrays
(e.g. scalars can be subscripted as arrays of arbitrary rank with
indexes equal to 0). I suppose the solution for me would be to stop
holding onto my past conceptions - and always require that my
functions that can take sequence arguments only allow sequences for
those arguments.

Maybe someone can help me with a good explanation of the
scalars/rank-0 concept and a paradigm for programming with them in the
Numeric context.  If it is difficult for me then it will also confuse
all the people for whom I provide software analysis tools at our lab.

Chris

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From chris.chase@jhuapl.edu  Tue Oct 29 02:40:55 1996
From: chris.chase@jhuapl.edu (Chris Chase SRM)
Date: Mon, 28 Oct 1996 21:40:55 -0500
Subject: [PYTHON MATRIX-SIG] take()
Message-ID: <199610290243.VAA17294@python.org>


I am trying to rethink my handling of scalars/rank-0 arrays to match
what people like Konrad have eplained.

Is there a reason why take() can not use a scalar/rank-0 array as an
index vector and just reduce the rank like is done with [] indexing?

a = arange(10)
take(a, 1) <=> a[1]

Chris

=================
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 Oct 29 09:15:27 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 29 Oct 96 09:15:27 GMT
Subject: [PYTHON MATRIX-SIG] take()
In-Reply-To: <199610290243.VAA17294@python.org> (message from Chris Chase SRM
 on Mon, 28 Oct 1996 21:40:55 -0500)
Message-ID: <199610290918.KAA02676@ibs.ibs.fr>

> Is there a reason why take() can not use a scalar/rank-0 array as an
> index vector and just reduce the rank like is done with [] indexing?
> 
> a = arange(10)
> take(a, 1) <=> a[1]

No problem in principle. In fact I would expect it to work.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Tue Oct 29 09:13:52 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 29 Oct 96 09:13:52 GMT
Subject: [PYTHON MATRIX-SIG] Find/where function
In-Reply-To: <9610281805.AA24678@goldilocks.LCS.MIT.EDU> (hugunin@mit.edu)
Message-ID: <199610290916.KAA02665@ibs.ibs.fr>

> This is almost equivalent to the current behavior of nonzero (the only
> difference is that your version works on non-flattened arrays).  I'm a
> little bit confused as to how this can possibly make sense for
> multi-dimensional arrays, but if it does, I think it should involve an
> extension of the existing nonzero function, rather than adding a new
> function.

But it doesn't really make sense, since the code he showed works on
a.flat. I'd prefer to leave the flattening explicit and use nonzero()
as it is now.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Tue Oct 29 09:26:09 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 29 Oct 96 09:26:09 GMT
Subject: [PYTHON MATRIX-SIG] scalars and arrays
In-Reply-To: <199610290236.VAA17271@python.org> (message from Chris Chase SRM
 on Mon, 28 Oct 1996 21:33:44 -0500)
Message-ID: <199610290928.KAA02721@ibs.ibs.fr>

> I am having a difficult time conceptually with the equivalence of
> scalars and rank-0 arrays.  So far, my problem is with functions that

Basically, rank-0 arrays and scalars are identical. We just need
rank-0 arrays to provide scalars for data types that don't exist
as Python scalars.

> take some kind of index vector.  I would like the user [of course I am
> the only user of my functions currently :-)] to be able to specify a
> scalar or a rank 1 vector and have them treated the same.  So I end up

You don't say *why* you want them treated identically. In general,
I would expect code to work on the widest possible range of ranks,
but not necessarily treat them as if they were the same.

But if that's what you want, I suggest the following procedure to
convert anything to a rank-1 array:

      a = array(a).flat

> Similarly, there are times when I don't want a scalar index to reduce
> the rank of an array which requires: a[v:v,other_indexes]

Not too bad I would say...

> (going back through the list archive) for the scalars/rank-0 issue.  I
> guess my difficulty is that in all my programming the past 7 years in
> Matlab and IDL scalars can be indexed and treated as arrays
> (e.g. scalars can be subscripted as arrays of arbitrary rank with
> indexes equal to 0). I suppose the solution for me would be to stop

That is a convenient convention for languages that don't have powerful
structural operations, for which the rank of an array is essential.
Essentially they ignore or create on demand axes of length 1, i.e. there
is no difference between an array of shape (1,2,1) and an array of shape
(2,). Using such a convention with complex structural operations makes
debugging a nightmare, and possibly other things as well...

> holding onto my past conceptions - and always require that my
> functions that can take sequence arguments only allow sequences for
> those arguments.

I have never felt a need to impose any such restrictions. Could you
give an example of a function that must take a sequence as a parameter?

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From jhauser@ifm.uni-kiel.de  Tue Oct 29 11:38:11 1996
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Tue, 29 Oct 1996 12:38:11 +0100
Subject: [PYTHON MATRIX-SIG] How time-consuming is array()?
Message-ID: <9610291138.AA02231@flores.ifm.uni-kiel.de>

Now I have some functions in my analysis-pack and encounter, that most
time is spent in reading the data, although I use the netcdf-package
of Bill Noon.

With this package I can read binary NetCDF-files, but the fields are
returned as nested lists.

X=array((f_head.var('xp')),Float32)

Is the translation from a list to an array very timeconsuming or is
the reading in the NetCDF-package the costly operation?

__Janko

=================
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 Oct 29 13:13:31 1996
From: jhauser@ifm.uni-kiel.de (janko hauser)
Date: Tue, 29 Oct 1996 14:13:31 +0100
Subject: [PYTHON MATRIX-SIG] RE: How time-consuming is array()?
Message-ID: <9610291313.AA02304@flores.ifm.uni-kiel.de>

So, here are the tests

#! /home/caesar/u1/hauser/bin/python

from Numeric import *
import time
import nc


f_head=nc.open('th2.cdf')

t1 = time.time()

X=f_head.var('xp')
t2 = time.time()

X=array(X, Float32)
t3 = time.time()

print "elapsed walltime:", t2-t1, "vs.", t3-t2, "seconds"


I run it several times:

elapsed walltime: 0.000975966453552 vs. 0.0907679796219 seconds
elapsed walltime: 0.000975966453552 vs. 0.0952479839325 seconds
elapsed walltime: 0.0 vs. 0.109311938286 seconds
elapsed walltime: 0.0 vs. 0.092719912529 seconds
elapsed walltime: 0.0 vs. 0.0839359760284 seconds
elapsed walltime: 0.0 vs. 0.0917440652847 seconds
elapsed walltime: 0.0 vs. 0.0864640474319 seconds

Now the same script with 
	X=list(f_head.var('xp'))

elapsed walltime: 0.0409919023514 vs. 0.0361120700836 seconds
elapsed walltime: 0.0429439544678 vs. 0.0370880365372 seconds
elapsed walltime: 0.0380640029907 vs. 0.0331839323044 seconds
elapsed walltime: 0.0507519245148 vs. 0.0429440736771 seconds
elapsed walltime: 0.0419679880142 vs. 0.0390399694443 seconds

So it's not a problem in the NetCDF-package, only it
returns a sequence, isn't it? But array is time-consuming.

Are there any better way's to handle this.

(I think the best is to change the NetCDF-package to return an array
object.) 

Some more comments?

__Janko


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From kschalm@geog.ubc.ca  Tue Oct 29 13:55:05 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Tue, 29 Oct 1996 05:55:05 -0800 (PST)
Subject: [PYTHON MATRIX-SIG] How time-consuming is array()?
Message-ID: <199610291355.FAA02715@peacock.geog.ubc.ca>

janko hauser writes: 
> Now I have some functions in my analysis-pack and encounter, that most
> time is spent in reading the data, although I use the netcdf-package
> of Bill Noon.
> 
> With this package I can read binary NetCDF-files, but the fields are
> returned as nested lists.
> 
> X=array((f_head.var('xp')),Float32)
> 
> Is the translation from a list to an array very timeconsuming or is
> the reading in the NetCDF-package the costly operation?
> 
> __Janko
> 

maybe these profile results are useful:

>>> import profile
>>> import nc
>>> f=nc.open('sub1.n14.95228.1706.ch4.nc', nc.NOWRITE)
>>> v=f.var('ch4')
>>> profile.run('list = v[:]')
         2 function calls in 19.180 CPU seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1   16.520   16.520   19.180   19.180 profile:0(list = v[:])
        0    0.000             0.000          profile:0(profiler)
        1    2.660    2.660    2.660    2.660 python:0(2051.C.1)

>>> profile.run('b=array(list)')
         2 function calls in 6.870 CPU seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    3.670    3.670    6.870    6.870 profile:0(b=array(list))
        0    0.000             0.000          profile:0(profiler)
        1    3.200    3.200    3.200    3.200 python:0(2051.C.5)

>>> profile.run('a = v.get()')
         2 function calls in 1.890 CPU seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    1.560    1.560    1.890    1.890 profile:0(a = v.get())
        0    0.000             0.000          profile:0(profiler)
        1    0.330    0.330    0.330    0.330 python:0(2051.C.3)


so in this example, using the list -> array method takes 2.660 + 3.200
= 5.860 seconds, whereas the mysterious "v.get()" takes 0.330 seconds,
under 6% of the time for the other method (although i wouldn't be
surprised if the profiler overhead or variable system load affected
the results a little).

the "v.get()" comes from a modification i made to bill noon's module.
you can grab it temporarily at http://www.geog.ubc.ca/~kschalm/
if you think it might be useful. it is not very well tested but
you are welcome to use it/play around with it. there are four files
available there:

    ncmodule-demo.py       29-Oct-96 05:02     1K  
    ncmodule.c             29-Oct-96 05:01    48K  
    netcdf-demo.py         29-Oct-96 05:23     1K  
    netcdf.py              29-Oct-96 05:11     1K  

ncmodule-demo.py - illustrates the additional functions i have added
	to the original module.
ncmodule.c - is the modified module, basically it adds a get and put
	method for getting/writing arrays, but there's some frills too.
netcdf-demo.py - is a "demo prototype" of the netcdf.py module
netcdf.py - adds some convenience functions on top of ncmodule

-Kyle

=================
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 Oct 29 14:11:38 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Tue, 29 Oct 1996 15:11:38 +0100
Subject: [PYTHON MATRIX-SIG] RE: How time-consuming is array()?
In-Reply-To: <9610291313.AA02304@flores.ifm.uni-kiel.de> (message from janko
 hauser on Tue, 29 Oct 1996 14:13:31 +0100)
Message-ID: <9610291411.AA10780@arnold.image.ivab.se>


> Now the same script with 
>
> 	X=list(f_head.var('xp'))
>
> So it's not a problem in the NetCDF-package, only it
> returns a sequence, isn't it? But array is time-consuming.

Hmm.  I'm a bit puzzled, really.  The second test could mean that
NetCDF returns a custom sequence object, which delays reading until
you really ask for data...

What does

	print type(f_head.var('xp'))

print?

	/F

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From chris.chase@jhuapl.edu  Tue Oct 29 14:31:01 1996
From: chris.chase@jhuapl.edu (Chris Chase SRM)
Date: Tue, 29 Oct 1996 09:31:01 -0500
Subject: [PYTHON MATRIX-SIG] scalars and arrays
In-Reply-To: <199610290928.KAA02721@ibs.ibs.fr>
References: <199610290236.VAA17271@python.org>
 <199610290928.KAA02721@ibs.ibs.fr>
Message-ID: <199610291434.JAA19154@python.org>



KH> But if that's what you want, I suggest the following procedure to
KH> convert anything to a rank-1 array:

KH>       a = array(a).flat

Thanks.

>> holding onto my past conceptions - and always require that my
>> functions that can take sequence arguments only allow sequences for
>> those arguments.

KH> I have never felt a need to impose any such restrictions. Could you
KH> give an example of a function that must take a sequence as a parameter?

I have satellite energetic ion measurements that can have a large
number of dimensions, two of which are species and energy channel.
Many of the procedures I write in IDL permit the user to select any
set of energy channels and/or species on which to operate.  This is
usually done via a scalar index or an array of indexes.  Your
array(a).flat trick (could even use it via map() as an idiom for
converting a tuple of scalars or sequences) will solve the problem and
allow me the function to be coded independent of the users input of a
sequence or scalar.

Thanks,
Chris

=================
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 Oct 29 15:15:36 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 29 Oct 96 15:15:36 GMT
Subject: [PYTHON MATRIX-SIG] RE: How time-consuming is array()?
In-Reply-To: <9610291313.AA02304@flores.ifm.uni-kiel.de> (message from janko
 hauser on Tue, 29 Oct 1996 14:13:31 +0100)
Message-ID: <199610291616.RAA05351@ibs.ibs.fr>

> (I think the best is to change the NetCDF-package to return an array
> object.) 

Obviously, and I think someone is working on that (I remember seeing
a posting on comp.lang.python).

> Some more comments?
> 
> __Janko
  ^^

Yes, your name is a class-private variable in Python 1.4 ;-)

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hinsen@ibs.ibs.fr  Tue Oct 29 15:18:36 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 29 Oct 96 15:18:36 GMT
Subject: [PYTHON MATRIX-SIG] scalars and arrays
In-Reply-To: <199610291558.QAA05259@ibs.ibs.fr> (message from Chris Chase SRM
 on Tue, 29 Oct 1996 09:31:01 -0500)
Message-ID: <199610291619.RAA05371@ibs.ibs.fr>

> Many of the procedures I write in IDL permit the user to select any
> set of energy channels and/or species on which to operate.  This is
> usually done via a scalar index or an array of indexes.  Your
> array(a).flat trick (could even use it via map() as an idiom for
> converting a tuple of scalars or sequences) will solve the problem and
> allow me the function to be coded independent of the users input of a
> sequence or scalar.

If it's for input processing then the conversion approach makes sense.
It's also a standard technique in APL (where of course input plus
conversion to a rank-1 array is done with just two characters).

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Tue Oct 29 20:03:07 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 29 Oct 1996 15:03:07 -0500
Subject: [PYTHON MATRIX-SIG] How time-consuming is array()?
Message-ID: <9610292003.AA16700@goldilocks.LCS.MIT.EDU>

> Now I have some functions in my analysis-pack and encounter, that most
> time is spent in reading the data, although I use the netcdf-package
> of Bill Noon.
> 
> With this package I can read binary NetCDF-files, but the fields are
> returned as nested lists.
> 
> X=array((f_head.var('xp')),Float32)
> 
> Is the translation from a list to an array very timeconsuming or is
> the reading in the NetCDF-package the costly operation?

I've read some of the later posts, but I'd just like to add a few comments.

array(nested_list) has not been optimized for speed (nor is it likely to
be).  It has been written in a very general fashion to support fairly
arbitrary nested sequence objects (the only objects on which it works very
efficiently are other arrays).  If somebody really has a need and wants to
contribute a highly optimized "fromlist" function I'd be willing to add it
(though I don't think this is necessary).

Kyle Schalm's modified NetCDF module is obviously the right solution here. 
I'd advise anybody who's using NetCDF and NumPy to get his version and use
it.

My two cents worth - Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Tue Oct 29 22:03:43 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Tue, 29 Oct 1996 17:03:43 -0500
Subject: [PYTHON MATRIX-SIG] Re: The perlDL matrix module
Message-ID: <9610292203.AA18692@goldilocks.LCS.MIT.EDU>


> Well, it appears to me that perl has gotten on the bandwagon with regards
> to efficient manipulation of matrix objects:
> 
> http://www.aao.gov.au/local/www/kgb/perldl/PDL.html
....
> Do any of you perl/python cross-trainers have any insight as to relative
> value of each?  

NumPy is currently in its 1.0alpha5 release.  The alpha releases are being
restricted to members of the matrix-sig.  The first beta release will be
available publicly sometime in November and I'll announce it here then. 
Nonetheless, I just couldn't resist this one.  Here's a quick run-down of
some differences (thrown together while reading the perldl announcement). 
Note: this is from an extremely biased viewpoint.

I've always said that I thought Perl 5 was the one other language besides
Python in which something like the Numeric Extensions could be done well. 
I think that PDL is a reasonable first pass at doing just that.  Both PDL
and NumPy provide a way to efficiently work with multi-dimensional arrays
of homogeneous numbers.  The most significant difference in my mind between
the two systems is that NumPy uses Python and PDL uses Perl.

There are a lot of other differences between the two extensions, but
without spending a lot of time playing with PDL I'd be hard pressed to
provide a fair comparision.  Here's a quick summary of the obvious relative
advantages I noticed for each.

PDL's advantages:
	better syntactic sugar
		$a < 42 vs. less(a, 42)
		a += 1; a x b instead of dot(a,b)
	support for FITS and IIS

NumPy's advantages:
	supports complex numbers
	much more extensive math library
	more sophisticated structural operations: repeat, choose
	better syntax for multidimensional indexing (and more efficient)
	extensive set of modules:
		LAPACK, FFTPACK, RANLIB, GIST, PGPLOT, OpenGL, NetCDF, ...
	NumPy uses internal storage format compatible with both C and FORTRAN (I
don't know the internal storage format for PDL)
	
My two cents worth,
Jim Hugunin - author of NumPy

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From kschalm@geog.ubc.ca  Wed Oct 30 18:47:07 1996
From: kschalm@geog.ubc.ca (Kyle Schalm)
Date: Wed, 30 Oct 1996 10:47:07 -0800 (PST)
Subject: [PYTHON MATRIX-SIG] notes on netcdf module
Message-ID: <199610301847.KAA05779@peacock.geog.ubc.ca>

Janko Hauser writes:
>My original code read a record (one timestep) of  4-dimensional
>field var(time,z,y,x). Because of the nested lists I could use
>
>data=array(f_hist.var(var_name)[time])
>
>, the other dimensions are unknow here.
>
>If I understand var.get() right I must now specify the length of the
>remaining dimensions, right? Or is there a default-value? (I know it's
>not difficult to get the dimensions ...)

what you want is done like this:

f_hist.var(var_name).set_cur(time,0,0,0)
data=f_hist.var(var_name).get(1, nc.all, nc.all, nc.all)

a bit of a clumsy syntax but good enough for now. 
of course if you will be reading many timesteps one at a time, it
is better to read the whole array and take slices.

in general, you can 
specify a current position in the array from which gets and puts
take place and use nc.all and nc.toEnd:

var.set_cur(1,2,3,4)
var.get(1, nc.toEnd, nc.toEnd, nc.all)

if var normally has a shape of (5,5,5,5) then this returns an array
with shape (1,3,2,5) which is a subarray beginning at (1,2,3,0).

this reminds me, there is not full support for record data yet. i will look
into that (hopefully) soon. also, longs may or may not work on any given
machine; anyway, all this code is use-at-your-own-risk ;)

-Kyle


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From phil@geog.ubc.ca  Wed Oct 30 21:25:38 1996
From: phil@geog.ubc.ca (Phil Austin)
Date: Wed, 30 Oct 1996 13:25:38 -0800 (PST)
Subject: [PYTHON MATRIX-SIG] Re: Pointer to pgplot module?
In-Reply-To: <9610302111.AA03103@goldilocks.LCS.MIT.EDU>
References: <9610302111.AA03103@goldilocks.LCS.MIT.EDU>
Message-ID: <199610302125.NAA05960@coot.geog.ubc.ca>

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

    Jim> indexing (and more efficient) extensive set of modules:
    Jim> LAPACK, FFTPACK, RANLIB, GIST, PGPLOT, OpenGL, NetCDF,
    >>  Jim, do you have a url for pgplot.py?  The search engines
    >> aren't coming up with anything.

    Jim> Since this is the second request I've gotten, I thought I'd
    Jim> make this correction publically.  There is an interface to
    Jim> PLPlot (done by Tom Schwaller) sitting on my old ftp site
    Jim> which probably needs some minimal updating for the most
    Jim> recent version of NumPy.  There is no interface to PGPLOT
    Jim> that I'm aware of (I don't even know what PGPLOT is).

Pgplot is a package developed at Caltech for the astrophysics
community.  A nice tool for doing publication quality graphics, if
someone wants to try a port (one attractive feature is that an
(unsupported) port to WindowsNT has been done).  My impression is that
the user community is larger and more active than for plplot, but I
could be wrong.  The perl5 front end and other links are at:

http://www.ast.cam.ac.uk:80/~kgb/pgperl.html

Phil

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From boyle@cobra.llnl.gov  Thu Oct 31 17:15:41 1996
From: boyle@cobra.llnl.gov (James Boyle)
Date: Thu, 31 Oct 96 09:15:41 PST
Subject: [PYTHON MATRIX-SIG] Data analysis package question
Message-ID: <9610311715.AA25373@cobra.llnl.gov>


I have been exploring the possibilities of data analysis using
Yorick and Python.
It would seem that one could construct a 
rather powerful, flexible package from the following tools:

Python 1.4 or later?
NumPY - Numerical Python extension 1.? - CRUNCH
NetCDF - extension/with dependence on NumPy - I/O
GIST - extension /with dependence on NumPY - GRAPHICS
Tkinter - GUI (if one is so inclined)

The only reason that I am hesitating to really get underway, is
that at this point NumPy is a moving target. As seen above, NumPy
is a critical path for all this to succeed. 
My point is ( and I do have one) that there needs to be some coordination
among the components of the system outlined above. I don't mean that everyone
proceeds in lockstep, I think that all that is required is that each author of 
the components states clearly what the compatibility requirements are for each 
release and that previously released versions are kept available so that at
any given time there is a complete, compatible set that can be built. Maybe
some higher level documentation on how all the components can be harmoniously 
put together could be written.
>From my monitoring of this group I don't think that I am at all unique. Maybe
a sub-group could be formed for clearing up the details for integration of
the above system when the NumPy beta or final is released.

Jim


=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From hugunin@mit.edu  Thu Oct 31 17:58:18 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Thu, 31 Oct 1996 12:58:18 -0500
Subject: [PYTHON MATRIX-SIG] Data analysis package question
Message-ID: <9610311758.AA16110@goldilocks.LCS.MIT.EDU>

> I have been exploring the possibilities of data analysis using
> Yorick and Python.

Just curious, where does Yorick fit in here?  For the GIST graphics?

> It would seem that one could construct a 
> rather powerful, flexible package from the following tools:
> 
> Python 1.4 or later?
> NumPY - Numerical Python extension 1.? - CRUNCH
> NetCDF - extension/with dependence on NumPy - I/O
> GIST - extension /with dependence on NumPY - GRAPHICS
> Tkinter - GUI (if one is so inclined)
> 
> The only reason that I am hesitating to really get underway, is
> that at this point NumPy is a moving target. As seen above, NumPy
> is a critical path for all this to succeed. 

NumPy1.0a5 is not much of a moving target anymore.  Furthermore, the C API
to NumPy hasn't changed (except for compatible extensions) since version
0.34.  This API is the crucial component to making these extensions work.

NumPy1.0a6 is due out this Friday (won't be any later than Monday).  It's
incompatible changes will be:

binarysearch renamed to search_sorted
diagonal function behavior changed slightly 
dot function behavior changed for 2d and greater arrays

I would expect that the list of incompatible changes between a6 and beta1
will be about this long (if not shorter).  I intend to work reasonably hard
to avoid any incompatible changes after beta1.

So, after a year of telling people this is an experimental project where
everything is subject to change and you should use at your own risk, I
think I can finally say that I'm happy with this system and I don't plan on
any significant incompatible changes (well at least not until version 2.0
;-)  The major remaining task is to track down all the remaining bugs in
the system and start building those essential extension modules for
GIST/NetCDF/etc.

-Jim

PS - I see some significant possibilities for coordinated work on
developing modules for things like NetCDF, GIST, etc.  I'd strongly
encourage people who are working on supporting an extension module for a
reasonably popular package to announce their plans on this list, and work
to coordinate things with others who are interested in supporting the same
package.  Once beta1 is out, I'll add a page for extension modules both
completed and in progress to my Numeric Python 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 furnish@laura.llnl.gov  Thu Oct 31 19:20:36 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Thu, 31 Oct 1996 11:20:36 -0800
Subject: [PYTHON MATRIX-SIG] Data analysis package question
In-Reply-To: <9610311758.AA16110@goldilocks.LCS.MIT.EDU>
References: <9610311758.AA16110@goldilocks.LCS.MIT.EDU>
Message-ID: <199610311925.OAA28124@python.org>

Jim Hugunin writes:
 > > I have been exploring the possibilities of data analysis using
 > > Yorick and Python.
[...]
 > PS - I see some significant possibilities for coordinated work on
 > developing modules for things like NetCDF, GIST, etc.  I'd strongly
 > encourage people who are working on supporting an extension module for a
 > reasonably popular package to announce their plans on this list, and work
 > to coordinate things with others who are interested in supporting the same
 > package.  Once beta1 is out, I'll add a page for extension modules both
 > completed and in progress to my Numeric Python web pages.

It is worth pointing out that PLplot fits into the above picture as
well.  I understand that my forbears have been in the habit of
announcing PLplot python module support in this forum.  I have
recently absorbed the latest plmodule.c by Thomas Schwaller into the
official PLplot repository, and took that opportunity to implement
some of the 2-d api which was not done yet, notably contouring and
color fill shading.  Interested parties can pick up the latest from:

/anonymous@dino.ph.utexas.edu:plplot/snapshots/plplot-961023.tar.gz

This version works with Python 1.4b3 and NumPy 1.0a5.  When there is a
NumPy that works with 1.4, I will cut a new snapshot soon thereafter.

The PLplot module supports output to a Tk graphics widget (among a
multitude of other output drivers), which can be trivially integrated
into Python/Tk, and we have that in operation here at LLNL now.  There
is also the beginnings of a Python/Tk "megawidget" for the plframe
graphics widget, which provides a variety of conveniences for
scientific plotting, including saving to a any of a variety of
supported graphics formats (including postscript and ppm), as well as
manipulation of the plot orientation, printing the currently visible
view.  etc.  There is also a binding available for zoom support, and
"zoom frame list walking", with panning.

PLplot also supports dynamic color pallete manipulation, but I haven't
yet written the Python/Tk megawidget support for that, but it will be
coming soon.

In any event, I am eager to see an improved Python/NumPy/PLplot
environment for interactive data manipulation and visualization, and
will continue to assist people who submit contributions in this area.
Now that I am personally using Python, my level of responsiveness to
the Python community will be much higher than before, perhaps even
eclipsing what has been done previously for Tcl/Tk.

My own personal opinion on what is most needed in the Python universe
in order to support such effots by myself and others, are:

1) Thorough documentation for the NumPy C interface.
2) A C++ wrapper for NumPy data storage (I have a start on this, which
   I should be able to release soemtime).
3) A real plan for doing serious "megawidgets" in Python/Tk.

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

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From pas@lems.brown.edu  Thu Oct 31 20:33:21 1996
From: pas@lems.brown.edu (Perry A. Stoll)
Date: Thu, 31 Oct 1996 15:33:21 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] Data analysis package question
In-Reply-To: <199610311925.OAA28124@python.org>
Message-ID: <Pine.SUN.3.91.961031151427.20286A-100000@lems61>



On Thu, 31 Oct 1996, Geoffrey Furnish wrote:

> Jim Hugunin writes:
>  > > I have been exploring the possibilities of data analysis using
>  > > Yorick and Python.
> 
> It is worth pointing out that PLplot fits into the above picture as
> well.  I understand that my forbears have been in the habit of

I'm going to relate my opinion/experience concerning plplot as it relates
to NumPy. 

PLplot is a bear to compile. I've had a fair amount of experience working 
with large software projects, and getting PLplot to the point where I 
could use it, in or out of python, took a significant amount of work. Way 
too much, in my opinion. And it even uses gnu configure.

PLplot needs to be better integrated into Python. Namely, it should _not_
simply exit when it can not allocate a desired color. This behaviour has
forced me to stop using it. I'd be doing some analysis in a Python
interpreter, decide I'd like to visualize the result and import plplot.
I try to open a plot and it quits with a message along the lines of 
"couldn't allocate color FOOBAR. Quitting..." losing all the data I'd 
spent time working to get. 

There was very little documentation or support information. Such as which 
version of plplot (4.99alpha.k.1.4.5.6  or 4.99.gamma.j.3.4.2.1) the 
given plplot module worked with.

Ok, you say, we'll gladly accept patches to fix it. I did submit some
small patches to the author of the PLplot module, but I don't have the 
time or inclination to make any more. 

My general impression was that PLplot was overkill for my simple
visualization needs - plots, contour maps and surfaces. I guess I'm just
saying to those considering using PLplot from within Python - it's not an 
easy road to travel.


> My own personal opinion on what is most needed in the Python universe
> in order to support such effots by myself and others, are:
> 
> 1) Thorough documentation for the NumPy C interface.
> 2) A C++ wrapper for NumPy data storage (I have a start on this, which
>    I should be able to release soemtime).
> 3) A real plan for doing serious "megawidgets" in Python/Tk.

Sounds good, especially 3. I think light weight Py/Tk widgets would be 
the way to go.

-Perry
 <pas@lems.brown.edu>

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From johann@physics.berkeley.edu  Thu Oct 31 20:47:57 1996
From: johann@physics.berkeley.edu (Johann Hibschman)
Date: Thu, 31 Oct 1996 12:47:57 -0800 (PST)
Subject: [PYTHON MATRIX-SIG] Data analysis package question
Message-ID: <Pine.SUN.3.91.961031124702.24582C-100000@physics20.Berkeley.EDU>

On Thu, 31 Oct 1996, James Boyle wrote:

> I have been exploring the possibilities of data analysis using
> Yorick and Python.
[...]
> The only reason that I am hesitating to really get underway, is
> that at this point NumPy is a moving target. As seen above, NumPy
> is a critical path for all this to succeed. 

I'm about in the same position.  I've managed to get NumPy and GIST
working together rather nicely, so I'm fairly optimistic that the whole
package could be made to work.

Meanwhile, I'm keeping myself busy fending off periodic assaults from
friends saying that I should just use either IDL or C and be done with it. 
My CS friends think perl is the answer to all problems.  IDL's great, but
it looks like Fortran with a hangover, while perl looks like a gorilla
held down shift and mashed his hand on the keyboard a few times, and C
would take a zillion lines of code to do anything interesting.  I'm just
not understood.  Sigh.  :)

(I am somewhat disturbed by reports that perl is several times faster 
than python, though.)

> >From my monitoring of this group I don't think that I am at all unique. Maybe
> a sub-group could be formed for clearing up the details for integration of
> the above system when the NumPy beta or final is released.

You're certainly not unique.  (We are all individuals.)  (I'm not!)  
However, I at least am content to fiddle around until I know enough about 
the system to comment intelligently, trusting that if I have a real 
question, someone will be able to answer it.

- Johann

Johann Hibschman
johann@physics.berkeley.edu   




=================
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 Oct 31 21:21:26 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Thu, 31 Oct 1996 13:21:26 -0800
Subject: [PYTHON MATRIX-SIG] Data analysis package question
In-Reply-To: <Pine.SUN.3.91.961031151427.20286A-100000@lems61>
References: <199610311925.OAA28124@python.org>
 <Pine.SUN.3.91.961031151427.20286A-100000@lems61>
Message-ID: <199610312328.SAA28646@python.org>

Perry A. Stoll writes:
 > PLplot is a bear to compile. I've had a fair amount of experience working 
 > with large software projects, and getting PLplot to the point where I 
 > could use it, in or out of python, took a significant amount of work. Way 
 > too much, in my opinion. And it even uses gnu configure.

Gnu configure is not magic.  But that does not excuse the fact that
there have been bugs in PLplot's configure.  I have corrected a couple
dozen such bugs in the last two snapshots.  Have you tried a recent
version? 961023 is the first one where the configure worked even close
to my satisfaction, and even so I have made many corrections more
since that snapshot.  I do not know when the next snapshot will be,
but it won't be long.  Bottom line, this criticism is getting
significant attention these days.

 > PLplot needs to be better integrated into Python. Namely, it should _not_

I heard, (before I became a Python user), that Guido refused to
include the PLplot module in the python modules set.  That seems
unfortunate to me, since it is clearly easier to build the modules
which are provided in the python tree than it is to build modules
provided seperately, but I didn't and can't influence that decision.
The best I can do now is provide the best instructions possible for
performing the integration.  The 961023 snapshot has a lengthy
description of how to do this, and I have personally done it in short
order on 4 platforms in the last week.  I think it is getting better.
If you have further suggestions, please send them in.

 > simply exit when it can not allocate a desired color. This behaviour has

This problem has been a source of irritation to many, and has had
nothing to do with python.  As it happens, I have recently made
changes in the XColor allocation in an attempt to ameliorate this.  I
have peole testing the new x driver, and once it seems like the
problem is really fixed, I will cut a new snapshot.

 > forced me to stop using it. I'd be doing some analysis in a Python
 > interpreter, decide I'd like to visualize the result and import plplot.
 > I try to open a plot and it quits with a message along the lines of 
 > "couldn't allocate color FOOBAR. Quitting..." losing all the data I'd 
 > spent time working to get. 

I understand and agree that this is unacceptable.  Hopefully it will
soon be a distant memory.

 > There was very little documentation or support information. Such as which 
 > version of plplot (4.99alpha.k.1.4.5.6  or 4.99.gamma.j.3.4.2.1) the 
 > given plplot module worked with.

PLplot does nto have independent funding.  It does have a maililng
list.  I have never seen a user of the plmodule post a complaint to
the PLplot mailing list...

 > Ok, you say, we'll gladly accept patches to fix it. I did submit some
 > small patches to the author of the PLplot module, but I don't have the 
 > time or inclination to make any more. 

The python module did not used to be maintained by the PLplot
maintainer.  Now it is.  If you submit patches to me, they will
eventually work their way into the PLplot repository.  The rate at
which this happens depends critically on the quality of the submitted
patch.

 > My general impression was that PLplot was overkill for my simple
 > visualization needs - plots, contour maps and surfaces. I guess I'm
 > just saying to those considering using PLplot from within Python -
 > it's not an easy road to travel.

I will not dispute your historical perspective.  I would like to
project a more encouraging tone to future takers.  PLplot's python
module is (now) being actively used by me on a daily basis.  That
makes all the difference in the world in terms of what the python
community can expect in the way of ongoing support.

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

=================
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  Fri Oct 18 09:43:03 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Fri, 18 Oct 1996 10:43:03 +0200
Subject: [PYTHON MATRIX-SIG] Re: [PYTHON IMAGE-SIG] convolution
In-Reply-To: <9610171549.ZM19988@chagall.iwr.uni-heidelberg.de>
 (Dirk.Engelmann@iwr.uni-heidelberg.de)
Message-ID: <9610180843.AA03028@arnold.image.ivab.se>


(intentionally cross-posted to matrix-sig)

> I would like to know, if there is an efficient method for python
> available to calculate a convolution (of a 2D image and a a
> windowing mask).

  The PIL itself supports only 3x3 and 5x5 convolution filters, mainly
intended for "image enhancement" purposes.  In 0.1, there's only a few
hardwired filters available, you cannot provide you own kernels (this
will change in 0.2).

  For fancier stuff, convert the image into a matrix and use numerical
python to process it (the most recent version of NumPy includes FFT
support).  A crude interface between PIL and NumPy (using tostring)
interface has been posted to this list earlier; PIL 0.2 will
(hopefully) include slicker interfaces.

  As for 2D convolutions, ask on the matrix-sig list.  It's full of
number crunching wizards (right? ;-)

Regards	/F

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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

From friedric@rose.rsoc.rockwell.com  Mon Oct 21 15:41:20 1996
From: friedric@rose.rsoc.rockwell.com (Robin Friedrich)
Date: Mon, 21 Oct 1996 09:41:20 -0500
Subject: [PYTHON MATRIX-SIG] Where to go (was Numerical Recipes)
Message-ID: <199610211441.JAA00648@darwin.rsoc.rockwell.com>

|> From: da@maigret.cog.brown.edu (David Ascher)
|> Subject: Re: [PYTHON MATRIX-SIG] Where to go (was Numerical Recipes)
|> To: jhauser@ifm.uni-kiel.de (janko hauser)
|> Date: Sun, 20 Oct 1996 15:30:32 -0400 (EDT)
|>  
|> Clearly this would make most sense if all Python docs were available in
|> a TIM-like format.  Maybe it's time to ask the DOC-SIG what's up.  The
|> Reference manual has been converted to FrameMaker, which might actually
|> allow conversion to SGML and from there TIM?  The other manuals were
|> last I checked available in info format (in fact it's with the library
|> reference in mind that I wrote the `ihelp' module, when some users were
|> complaining that Python had lousy help facilities compared to
|> matlab...).
|> 
|> --david
|> 

It should be made clear that the Language Reference and Tutorial
are the only docs converted to FrameMaker. The Lib Ref is still
up in the air as to format. The last view I heard was that it should
be written in a very easy system that's text-based and assembled
into it's entirety with some higher level tools. TIM looks to be the
odds on favorite here but there needs to be a whole lot more 
concurrence among module writers. The structured text standard
for doc strings needs to be considered and incorporated as well.
A TIM formatter for gendoc is an obvious approach.

=================
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 Oct 23 18:21:12 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Wed, 23 Oct 1996 13:21:12 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Alpha release of new tutorial for 1.0a5
In-Reply-To: <199610231704.NAA22149@maigret> from "Geoffrey Furnish" at Oct 23, 96 10:04:22 am
Message-ID: <199610231721.NAA22272@maigret>

In my announcement of the alpha tutorial for the numeric extension, I
wrote:

>  > And there are HTML, DVI, TeX, Info, Text and PS versions (TIM is
>  > pretty cool really!).

Which prompted Geoffrey Furnish to ask in email:
 
> BTW, what is TIM?  Can you give me a brief low-down on it?  Can it do
> math like tex/latex?

TIM is a tool developed by Bill Janssen as part of the ILU project at
Xerox PARC, but independent of ILU.  Some documentation can be found at:

ftp://ftp.parc.xerox.com/pub/ilu/2.0/20a8-manual-html/manual_17.html#SEC275

The key sentence is:

  TIM is essentially a superset of the GNU texinfo language, version
  2.  It adds several features to allow more precise discrimination of
  semantics when documenting software systems. You should be familiar
  with the basic texinfo system first.

I am still a novice at it, so I'm not sure about it possibilities.  I
suspect that one can insert TeX commands in it, and they'll come out
fine in the TeX mode.  I suspect also that they won't come out at all in
HTML mode.  

I chose it because it seemed reasonable.  I'm probably using very few
features of TIM which aren't part of Texinfo.  I also thought that
since we're looking for a common documentation format, this could be
somewhat of a test for TIM.

For most of the python modules, I think TIM would be good enough.
For the scientific extensions which are bound to arrive in droves =),
it'd be nice to have one which allowed math like LaTeX, but also
allowed it to be displayed in HTML form.  This makes me think that an
interface between a markup language like TIM's and a system like
Ka-Ping Yee's system would be nice.  It's a big project though, and one
I'm not volunteering for.

Thoughts anyone?

--david

[I'm sending this to matrix-sig, doc-sig and Bill Janssen and Ping
since they all seem relevant.  Maybe followups should just go to
doc-sig?].

PS: One of the reasons I like TIM is that it seems it shouldn't be too
    hard to do a reasonable TIM->SGML conversion someday, when the
    tools become available.

=================
MATRIX-SIG  - SIG on Matrix Math for Python

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