[PEP draft 2] Adding new math operators

[Konrad Hinsen]

hzhu at localhost.localdomain (Huaiyu Zhu) writes:

> >Sounds familiar as well - and my solution is the same. The statistical
> >operation is encapsulated in a function or method (as one would do
> >anyway!), which contains all the matrix operations.
> 
> I'm not sure I follow you here.  Let's say A is a matrix.  The expression
> (using matrixwise notation)
> 
>     B = A ~- mean(A)

What is mean(A) supposed to return? The average over all elements of
A? Or the average over all columns or rows? In NumPy, if you define a
function mean() acting on a sequence, then it will do an average along
the first index when passed a higher-rank array, and thus return an
array whose rank is 1 lower than that of the input array. Judging from
your following matlab example, I suppose you expect it to return a
scalar.

I mention this to point out that mean(A) needs to be properly defined
for matrices anyway, a generic mean() for all kinds of data won't
work. Or the user must accept to write something like
mean(Numeric.ravel(A.array)) for getting the average over all
elements, which clearly states that the average is taken over all
elements.

How to handle subtraction of a scalar from all elements of a matrix is
of course a separate question. I would probably use an approach
similar to the matlab code you cited, just for clarity. The double
conversion solution

         m = mean(Numeric.ravel(A.array))
         B = (A.array-m).matrix

would however be more efficient.

Another approach would be to define addition and subtraction of a
scalar and a matrix to be elementwise, since there is no competing
definition for this combination.

> functions of this sort.  What about 
> 
>     B = scaling ~* (A ~- mean(A))
> 
> where scaling is also a row vector?  Do we define scaleddeviation(A)?  If we

In the algorithms I know that use such scaling, it is one out of many
steps and I wouldn't mind writing it in two lines.

> These operations are also interchangeable as algorithms evolve.  Suppose A
> is a collection of time series it is common to change scaling into a

A collection of time series is not a matrix, but a classical
application of NumPy-style arrays.

> I also think there is a selective bias here: the early adopters of the NumPy
> interface are more likely to be satisfying with array-only operations,
> precisely because their applications are of such characteristics.  Those who

That is very well possible. And no one can claim to know all common
applications of array/matrix languages. Unfortunately (for you) it is
up to those who propose significant changes to show that these changes
are worth the effort. And I cannot say that I am convinced yet. Sure,
you give examples which are easier to handle with added operators. But
are those examples frequent? Do they occur often enough in
sufficiently many "typical" applications that a more clumsy notation
poses a real problem?

Anyway, I'll have to drop out of the discussion for two weeks. Among
other things, I'll participate in a conference where I'll talk about
Python to people who work mainly in the PDE business. Perhaps that
application domain will require yet another set of operators...
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------