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

[Jim Fulton, U.S. Geological Survey]

On Wed, 27 Sep 1995 09:35:32 -0400 
Hinsen Konrad said:
> 
>    Please keep in mind that:
> 
>      - If there is a standard matrix class, it will be implemented in C,
>        for performance reasons,
> 
> I hope so!
> 
>      - 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.
> 
> Actually I can't think of any reason not to keep the data in a
> continous block...
> 
>    > 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.
> 
> I do not disagree with that goal at all; in fact I seriously
> considered adding type checking (or rather consistency checking) to my
> Python implementation. But it would have slowed down everything
> without producing much of an advantage (I assume no one will produce
> mixed arrays by accident), so I left it out.
> 
> Again, I do not claim in the least that any future array module
> should resemble my implementation in any respect. On the contrary,
> I expect that both could be used in parallel for different
> applications. I started writing this because I had a need for
> flexible (but small) arrays, and then polished it up a bit to
> make it usable as a demonstration for people in this SIG.

Sounds like we're on the same wave-length then.
 
>    Gee.  I would miss element assignment.
> 
> Really? I realize that element assignment is necessary to implement
> many of the standard linear algebra algorithms, but these would be
> implemented in C/Fortran/whatever anyway.  I have never missed element
> assignment in J; in fact, I only noticed its absence while working on
> my Python implementation!
> 
>    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.
> 
> So am I. But we must make sure that the auxiliary modules can
> be used together conveniently. For example, the function names
> should be distinct, to make it possible to import them all into
> a single namespace

I don't agree with this.  In general, I'm not a fan of 
"from spam import *".

> (important for calculator-style use).

Why?

Jim

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

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