[PEP draft 2] Adding new math operators

[Konrad Hinsen]

Travis Oliphant <olipt at mayo.edu> writes:

> > 1) Add array/matrix objects to the core distribution.
> 
> Trying to do this.  If you have significant comments on how to do this
> please let me know.  Right now the plan is to put in this objects as
> Python classes with supporting C code (borrowed heavily from the current
> implementation).  I should write a PEP, but time...

This approach looks nice, assuming that there will be no significant
performance losses and/or excessive memory overhead (for small arrays)
due to the Python classes.

> > 2) Define methods for them and implement them for the scalar types
> >    as well (the implementation would in practice be shared, of course).
> 
> This makes definining methods for arrays much more prone to argument, but
> it could be done.  In the current skeleton, array classes have only a few
> "non-hidden" methods.

For practical reasons the number of such methods should of course be
kept small. The important point I want to make is that whatever attributes
and methods exist for arrays should also exist for scalars.

> > 3) Add the missing scalar types corresponding to single-precision
> >    float and complex.
> 
> I've brought this up before and wouldn't mind seeing it, but lately I've
> considered that we might be more successful if we just get rank-0 arrays
> from ceasing to be silently "upgraded" to Python scalars.  

One could use the rank-0 arrays for the single-precision types as scalars,
of course. For the existing types this would raise some compatibility
and memory overhead issues.

> One thing to consider, is that if and when we get the arrays into the
> Python core, the only reason for the "present Python scalars" is reducing
> the overhead of the array class for every integer since --- they are in
> all ways equivalent to rank-0 arrays (not currently the case, but it could
> be).  

But the overhead is important, and there is also the issue of
compatibility with existing code that does type testing in the style
of "if type(a) is type.FloatType)", or its equivalent in C code.

> It seems to me that a useful solution to the type/class dichotomy which
> has come out of my thinking about what to do with NumPy is to define no
> types at all and make everything classes. 

Even scalars? Nice in theory, but there will be an enormous overhead.

> > 4) Make scalars behave like rank-0 arrays in every respect (i.e.
> >    having a shape attribute etc.)
> 
> The other side of this is what I've been trying to do with NumPy and that
> is make rank-0 arrays behave in every respect like Python scalars. 

Even in type tests?

> I'm definitely in favor of this.  In fact, I think these ideas are much
> more important than the proposed new operators.  The problems caused by

I certainly agree on that!
-- 
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------