[PYTHON MATRIX-SIG] Thoughts on latest messages

[Paul. Dubois]

Congratulations on your marriage and best wishes to you and your wife.
We all hope you can "juggle" the matrix work in with the tasks you will
receive from The Boss.

Some thoughts on the latest messages. I think it best if I simply phrase
them as what I need to do and let you mull over how this fits with
various schemes. In what follows I use the name Thing to stand for "one
of them thar matrix objects however it turns out you name it")

a. In a C extension module, I need to create a Thing. The creation
routines you have supplied in the present release are sufficient to my
needs. 

b. Given a block of memory representing an array stored in column-major
order, I need to turn it into a Thing. Things are natively row-major but
given the current implementation I can diddle with the strides in the
Thing and it works. This means Fortran interfacing is easy. Cool. Try
not to lose this, and maybe we could make a constructor that did the
kludge officially.

c. If you want to make a Whatzit in Python that encapsulates a Thing but
adds some special semantics (say, for example, arrays whose lower index
is not 0) you can almost do it perfectly with a wrapper class but the
one thing you can't spoof is when the object is an argument to something
that expects a Thing. viz, sqrt(m). If I understood you, the idea would
be that all routines expecting a Thing would, finding that they hadn't
gotten one, try to do getattr(m, '__array__') so that objects that
wished to pretend they are Things could do so. I think this will prove
very valuable and can testify that I already ran into a case where it
would have been a nice solution for me.

Opinions:

I like the coercion properties of the current package VERY much. If you
need to do something special like keep expressions from drifting up from
float to double, then some explicit handling of scalar constants is
clearly required in either case, so I'm not persuaded anything would be
gained by undoing your good work.

About the packaging of mathematical software. A glance at the humongous
documentation for Nag or IMSL will suggest that organizing the software
into "clusters" by subject would be a good idea. In the EiffelMath
library we have clusters for ODES, probability and statistics, linear
solvers, optimization, root finding, time series analysis, etc. This
helps people find what they need and also not have to bring in too much
code just to get at a given piece.

The Thing class is very likely to get imported via 'from Thing import *'
because of the need to make the sqrt etc. work right; therefore, this
namespace should be kept minimal, with more specialized software kept in
other modules. Since it is easy to make supermodules that import sets of
other modules, one can package the facilities to suit the style of work
one does.

If it is really true that you can make a PythonThing level object that
has performance only 5% off of Thing, then that would be useful since we
could inherit from it. Especially if (c) is done.
-- 
Paul F. Dubois, L-472				(510)-422-5426
Lawrence Livermore National Laboratory		FAX (510)-423-9969
Livermore, CA 94550				dubois1@llnl.gov
Consulting: PaulDubois@aol.com

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

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