[PYTHON MATRIX-SIG] Steadily approaching BETA release

[Konrad HINSEN]

   So, what's left before a general BETA release?

   Note: I'm going to comment on each of these in a seperate follow-up
   piece of e-mail in order to try and seperate these two different issues.

   1) Type coercion
   2) Naming conventions

3) Practical experience

I don't know how much real-life code others have produced with
the current release, but I find that even with the relatively
modest amount of application code I have written, I keep finding
weak spots in the current collection of functions, i.e. operations
that are impossible or difficult to code efficiently.

It may seem that this is not a major problem, since more functions can
always be added later. But that will quickly lead to the same type of
function chaos that other "historically evolved" systems suffer
from. Sometimes new functionality is best implemented by extending the
definition of an existing function, which should however be reflected
by a new name - and at that point compatibility considerations make
the best solution impossible once the core function set is frozen.

To give an example: I need to repeat certain items in an array
a specified number of times, e.g. given
   n = array([1,1,2,3])
   x = array([2.,1.,6.,3.5])
I want to obtain something like
   y = repeat(n,x)
yielding
   array([2.,1.,6.,6.,3.5,3.5,3.5])

I don't see any reasonably efficient way to implement the function
repeat() with the current array operations. Supposing that this
operation is generally useful (and my APL/J experience definitely
indicates that it is), it should be implemented in C in the array
module. But a little reflection shows that this is a simple
generalization of the already existing function compress(); indeed
compress() is identical to repeat() as long as the first argument
contains only 0s and 1s. So the most rational design would be to have
repeat() and eliminate compress().

This leaves the question of how to find out which operations are
necessary and which aren't. Apart from practical experience (which
takes a lot of time to accumulate, and much more users than we
currently have), it makes sense to look what other array languages
have. It has been my intention to check whether common APL/J
function can be implemented easily with what we have, but without
knowing the existing function set, this is very difficult!

   What I've decided is not important to resolve before the BETA release:

   1) static vs. dynamic linking (static linking is fine for now) 
   2) Contents of Numeric.py (I'm going to rule by fiat here) 
   3) The exact details of Konrad's print function (Unlikley that changes
   here will break anyone's code)

I agree.

-------------------------------------------------------------------------------
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
=================