Discussion: new operators for numerical computation
Konrad Hinsen
hinsen at cnrs-orleans.fr
Fri Jul 21 06:08:23 EDT 2000
hzhu at localhost.localdomain (Huaiyu Zhu) writes:
> As far as I'm aware, multiarray necessarily involves indices. So infix
> operators are not so useful, until a class with index labels are defined.
I tend to agree, at least when N-d arrays are used to represent rank-N
tensors. Moreover, there aren't many applications where rank-N tensors
are needed in *numerical* code. This should not be our main concern for
infix operators.
However, higher-rank arrays are often used with a different
interpretation: arrays of vectors or matrices. For example, I might
have a rotation matrix at each time step of some simulation, or a
polarizability tensor for each particle. For these cases it makes
sense to extend the meaning of the infix operators to higher-rank
arrays.
The cleanest concept (in my opinion) is the one implemented in J,
where an array has (conceptually) a "data rank" and a "value rank",
the sum of the two being the rank, i.e. the number of indices. For
example, an array of rank 3 could be interpreted as a list of matrices
(data rank 1, value rank 2), as a matrix of vectors (data rank 2,
value rank 1), or as a 3-d array of scalars (data rank 3, value rank
0). In J the data and value ranks are not properties of the arrays,
but of the operators, whose value rank can be modified. In the early
days of NumPy development, I proposed this model for NumPy as well,
but there was no majority for it. And I agree that there are not so
many practical cases where this mechanism is necessary. However,
it nicely illustrates how one would extend vector and matrix operations
to higher-dimensional data.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen at 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
-------------------------------------------------------------------------------
More information about the Python-list
mailing list