[PYTHON MATRIX-SIG] RubberIndex

[Konrad HINSEN]

   You will never be able to use the current array implementation
   everywhere that a list is used because array has different definitions
   for operators (e.g. *, +) and array can not support 'del' without

True, but that is no reason to introduce additional incompatibilities.

   "must"?  Why?  As far as I can tell the hierarchical indexing for
   arrays was a convenience for those used to working lists, because it
   duplicates behavior already provided by a[0,...] indexing.

Historically it was the other way round, but all that doesn't
matter. The question is what behaviour is the most useful.

   both selection and assignment.  This specific solution for flattened
   indexing is supported in all the array languages that I have had
   exposure to (e.g. Matlab, IDL, Tela, Yorick). To me this is more
   important than the hierarchical indexing scheme so that an array looks
   like a list (but does not act like a list for other purposes).

The array languages I am familiar with (APL and J) do not permit this.
I suppose that the languages you mention support flattened access
because Fortran programmers are used to it, not because it is
important in real applications. I still think that a structural
modification like flattening should be explicit, not implied.
And let's not forget that our goal is not to write a Matlab/IDL/whatever
clone, but to provide arrays for Python. We should stick as close
as possible to established Python habits, which is why I insist
so much on the analogy with nested lists.

   As an alternative, a 'flat' (or 'flattened') array attribute could be
   supported.

Why? What's wrong with ravel(a)? You can index its result if you want.

   An aside: I know that Konrad Hinsen prefers functions to methods and
   attributes so that the same code will work for both scalars and
   arrays.  But this is similar to the list analogy above.  scalars will
   never work in all array code because scalars are neither sequences nor
   dictionary types.  The first time one attempts to subscript a scalar
   an error will be produced.  Certainly we don't want subscription to be

True, but that makes sense. Scalars are considered rank-0 arrays,
and indexing rank-0 arrays makes no sense. So the behaviour is
consistent. And again, the fact that something can't be done
perfectly is no argument for not doing it as good as possible.

My point about functions vs. methods is that many algorithms
can reasonably applied to arrays of all ranks, including
rank 0. Of course such algorithms cannot include indexing.
But all the operations that are rank-independent should be
implemented in such a way that they accept both arrays and
scalars.

   a function rather than a method.  Rather than jump onto the everything
   is a function bandwagon we may need to rethink the relationship
   between scalars and arrays.  What is the entire scope of code where
   scalars and arrays need to be interchangeable?

Everything except indexing. Some care must be taken with functions
that require an axis specification (like add.reduce). Obviously
a rank-0 array does not have axes, but add.reduce(x) still makes
sense if x is a scalar. Ideally, a call to add.reduce with an
explicit axis specification should raise an exception if given
a scalar, but do the right thing with the default axis.

BTW, there are more arguments not to implement array operations as
methods, as I have outlined in my proposal.

-------------------------------------------------------------------------------
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. Centre-Ville     | 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
=================