[PYTHON MATRIX-SIG] J-style arrays in Python
Jim Fulton, U.S. Geological Survey
Wed, 27 Sep 1995 10:13:50 -0400
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).
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: firstname.lastname@example.org
administrivia to: email@example.com