[PYTHON MATRIX-SIG] Let's get going

[Jim Fulton, U.S. Geological Survey]

These are good discussions.  I'm going to have to find some time to
digest what's been said.  Here are a few quick comments that don't
require much thought. ;-)


On Tue, 12 Sep 1995 21:21:25 -0700 
Graham Hughes said:
> At 12:17 PM 9/12/95 +0300, you wrote:

(snip)

> Finally, we reach the question of efficiency. No matter how you implement
> it, matrix multiplication will be slow(er). Divison, besides which it won't
> always work, 

A number of people (not to pick on you) have made the agument that
"such and such shouldn't be done because it won't always work".  I
really don't think this is a valid argument.  Most, if not all, of the
operations and functions have some preconditions.  You can't do
elementwise arithmetic unless both operands have the same dimensions.
You can't do elementwise division if *any* elements of the divisor are
zero. Heck, scalar division fails if a divisor is zero, but Guido was
still kind enough to include "/" in teh language. (Whew. :-)

> Probably not; too much common code to make it worthwhile. Besides, since
> Python is typeless,

Python is not typeless, only it's variables are.

> we *cannot* distinguish between multiplication by a
> scalar or by a matrix.

Not necessarily by reading the code.

> There is no typeof() function to distinguish them. 

No, it's called type().  There's also hasattr, which can be used to
check basic object signatures.

> To
> avoid bizarrities concerning *scalar* multiplication, we must use
> elementwise multiplication. If this were C++, we could use two seperate
> operator *()s, but it's not.
>

It is easy enough to handle this with a check in the single *
operator.

In fact, I think that whathever we do, numeric operations involving
matrices should work with:

  o Matrices and matrices,
  o Matrices and scalars, and
  o Matrices and sequences of sequences (non-Matrix objects that
    support similar multi-dimensional access).  

Supporting this does not really depend on whether a element-wise
interpretation is used for *.

Note that applying the mapping operator to take matrix
slices will *not* return matrix objects, since matrix objects are
supposed to contain contiguous globs of memory, so that their data can
be passed to C and Fortran libraries directly.  These matrix slices
will reference matrix objects so that modification of slice elements
will be reflected in the matrices from which they are derived, but for
mathematical operations, they will probably use different code.

My suspicion is that there will be code that:

   o Operates on two matrices (and perhaps a matrix and a scalar),
     using knowledge of internal data structures to optimize
     performance,
 

     and separate code that

   o Operates on sequences of sequences.  These will be written in C,
     for speed, but will use PySequence_GetItem calls to access
     operand data.

> 
> >That is not a good reason. It's more confusing to use mathematical
> >definition for some, and non-mathematical definitions for other operators,
> >as in your '+ vs. *' example. 

Actually, the "mathematical" interpretation of + happens to be the
same as the elementwise interpretation.

Still, most of the people who call for a mathematical interpretation
of * seem only to want that operator to be non-elementwise.  This
seems to me to stengthen the case of those who want an elementwise
interpretation for all operations.

Jim

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

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