[PYTHON MATRIX-SIG] Time for recap?

Hinsen Konrad hinsenk@ere.umontreal.ca
Mon, 2 Oct 1995 12:27:22 -0400


   Ah.  I was writing from memory, and forgot this feature.  I don't like
   it.  How many times do you have to select a more or less arbitrary
   group of rows/columns from a matrix?  It makes the slice representation

Quite often, if you use matrices as tables of numbers.

   bulkier -- contiguous slices can be stored (in C) as 4 ints per
   dimension, while random selections will require a variable-length
   list of indices per dimension.  (It is also wasteful to have to
   generate the full range of numbers when what you mean is a contiguous
   slice.)

Maybe there should be two internal representations, one for
contigous blocks (i.e. submatrices) and one for arbitrary
slices.

   A tuple is just one example of a sequence in Python.  Lists are
   another example.  In many situations, any sequence is acceptable and
   the results are the same (e.g. for loops).  (And in situations where
   only lists or only tuples are accepted by the current version of the
   language, Steve Majewski has often made the point that there is no
   inherent reason why only one type should be accepted and that this
   should be fixed.  I agree in most cases.)

Actually, I have never really understood why Python needs both
tuples and lists. Anything you can with tuples you can do with
lists, so why have tuples?

   Instead of supporting a[[2,3,5]] to select elements 2, 3 and 5 from a,
   I would propose to use filter() or a multi-dimensional extension
   thereof if you want to access selected subarrays.  Or perhaps just a

You mean actually having to iterate over the whole array just to
pick some element? That sounds a bit wasteful.


One problem I am seeing in this discussion is that indexing is being
treated separately from other array operations, although it is really
only one structural function among many (reshaping, transposing,
etc.). We should rather discuss the complete set of structural
functions together; they should behave consistently and together allow
all array manipulations that might occur, no matter which can be done
by "indexing" and which by something with another name.

If you look at my Array implementation, you will see that there
indexing is just syntactic sugar for a structural function "take" that
selects an arbitrary set of items from its argument. It has the useful
property that the shape of the result is the combination of the shape
of the "index" argument and the shape of the items of the "data"
argument. That gives great flexibility in selecting subarrays, and
provides an easy-to-understand behaviour even in complicated cases.
In my implementation, indexing itself is limited, since you can't
specify rank, but I don't really care, since "take" lets me do
whatever I want.

   > It wouldn't be too hard to expand the definition of basic type to
   > include (PyObject *)'s if you'd like to have the possibility of a
   > matrix of "real" python objects.

   Yes, the latter is definitely something that should be possible even
   if my idea doesn't find the acceptance I hope it will get.

You can add support from me ;-)
General arrays would be a useful feature without causing much
effort. The main problem I see is how to specify whether e.g. a
constant array of integers is supposed to be an array of integers or a
general array whose initial values happen to be integers. But this
can be overcome with explicit conversion, if necessary.

-------------------------------------------------------------------------------
Konrad Hinsen                     | E-Mail: hinsenk@ere.umontreal.ca
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. A                | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)
-------------------------------------------------------------------------------

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

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