[PYTHON MATRIX-SIG] J-style arrays in Python

[Jim Fulton, U.S. Geological Survey]

On Tue, 26 Sep 1995 21:38:49 -0400 
Hinsen Konrad said:
> To bring back some life into this discussion group, I'll distribute a
> Python implementation of J-like arrays, to give those unfamiliar with
> J a chance to become familiar with its array and rank system.

Cool.  This will help me become more familiar with some of the generic
processing operators that have been discussed.  I for one have not had
much to say lately because I'm waiting for a chance to study some of the
suggestions for map-ish operators.

> And of
> course it is also usable, as long as the arrays don't become too big.

This is perfectly appropriate for a prototype.  A real implementation
will need to handle large arrays well.

> This is a first test version; many important functions are still
> missing, others (like output formatting) need substantial improvement,
> and many could probably be made faster with some thought.
> 
> To make (my) life simpler, I tried to stick to J's conventions as much
> as possible (but hopefully without violating Python traditions). I am
> not claiming that this is semantically the best way to implement arrays,
> but it is a start.

Please keep in mind that:

  - If there is a standard matrix class, it will be implemented in C,
    for performance reasons,

  - There is already a base implementation, currently being worked on
    by James Hugunin.

  - Much of the base implementation was dictated by the *stated* goal
    that the implementation should hold the data in an homogenous and
    contingous block of data suitable for passing directly to existing
    Fortran and C libraries.

> Some general remarks:
> 
> - Since my implementation uses nested lists to represent arrays,
>   the elements can be arbitrary objects.

Which violates one of the basic goals of this effort.  I realize that
you may not agree with the goal, but this was clearly stated in the
announcement for *this* SIG.
 
> - Like arrays in J, my arrays are immutable, i.e. there is no
>   provision for changing individual elements. The reason for
>   making arrays immutable in J was that J is half-way to being
>   a functional language (it is not a pure functional language,
>   but many substantial problems can easily be solved in a
>   functional way). I have never missed element assignment, but
>   probably there are some good applications...

Gee.  I would miss element assignment.
 
> - All functions are implemented as external functions, not as
>   methods. The main reason is that at first I could not think of
>   a way to implement methods with variable rank, although later
>   I figured out how to do this (in the same way as I implemented
>   reduction).

This brings up a good point.  I think that whatever we come up with
should adhere to the KISS (Keep It Simple Stupid) rule as much as
possible.  I'm in favor of a fairly lean matrix module with auxilary
modules to provide support for specific application areas.

> I'll send two Python files; the first is the Array module itself,
> and the second a kind of simple tutorial. Let me know if
> anything is unclear. And let me know what you think of the
> whole implementation!

I look forward to studying what you sent. (When I have a chance. :)

Jim

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

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