[PEP draft 2] Adding new math operators

Huaiyu Zhu hzhu at localhost.localdomain
Thu Aug 10 17:30:36 EDT 2000


On Thu, 10 Aug 2000 14:28:31 -0500, Travis Oliphant <olipt at mayo.edu> wrote:

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

There are several practical issues. Do you want everybody to say

a = scalar(2) + scalar(3)

or do you want

a = 2 + 3

to generate an instance of a scalar class?  The former is quite impractical
from application point of view, while the latter is quite formidable from
implementation point of view.  You can try the MatPy.Scalar module to get a
feeling for the former (or look at MatPy/tests/test_scalar.py to see how
ugly it is).


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

a = array
a[0] = 3

Is a[0] now an element of array or a rank-0 array itself?  Or maybe in the
sense of strings, "abc"[0]=="a"=="a"[0] so "a" is both a substring and a
character.  That means array(2)[0]==2==2[0]==2[0][0][0]==....


>  In fact, I think these ideas are much
>more important than the proposed new operators.  The problems caused by
>this lack of unification seem more important to me than the syntatic
>difficulties of matrix multiplication as a function call.

Type/class unification would be the grand ideal, but IMHO it's orders of
magnitude more difficult / extensive than the current proposal for new math
operators.  Things that could only be done in P3K should not be an excuse
for not doing things that could be done immediately.

If we ask for more than can be implemented now, we are likely to get nothing.

Huaiyu



More information about the Python-list mailing list