[Matrix-SIG] Numpy in Viper

[Konrad Hinsen]

> FISh arrays are declared like:
> 
> 	{2,3 : 4, 7 : float_shape }
> 
> which means 2 x 3 array of 4 x 7 arrays of
> float shaped slots.  This is similar to a NumPy
> shaped array _except_ that it is also possible to
> have the type of an array element be another array.
> [This is vital]

I don't see the essential difference; it looks like a matter of
interpretation to me. In NumPy you would create an array of shape (2,
3, 4, 7), and you could then interpret it as an array of shape (2, 3)
with elements that are arrays of shape (4, 7). NumPy indexing allows
you not to specify the last indices, so if a is an array with the
shape shown above, then a[1, 0] is legal and returns an array of shape
(4, 7).

The interpretation becomes important only in some of the more
complicated structural operations. In the early stages of NumPy
design, I proposed to adopt the convention of J (an array language
designed by Kenneth Iverson, who is also the inventor of APL), in
which each operation has a (modifiable) rank that indicates how it
interprets its arguments' dimensions. For example, an operation of
rank 2 applied to the array a would treat is as a (2,3) array of (4,
7) arrays, whereas an operation of rank 1 would treat it as a (2, 3,
4) array of (7,) arrays. If I understand your description of FISh
correctly, it uses a similar approach but makes the interpretation
part of the arrays instead of the operations. Anyway, there was no
majority for such a general scheme, and NumPy uses axis indices for
structural operations. And I have to admit that I could not
present any practical example for which the more general J-style
approach would have been better. So I'd like to ask the same
question about FISh: where does the difference matter?

> Now, the reason I am posting is that compatibility
> and utility are, as usual, in conflict. My plan for Viper,
> for example, is that arrays be built-in, and standard
> No module: arrays become fundamental types. The reason is
> that the compiler can then do optimisations.

That is definitely a good idea.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------