[Numpy-discussion] New Operators in Python

dmitrey openopt@ukr....
Mon Mar 26 01:42:14 CDT 2007


Hallo!

1)Isn't it possible to add .A & .M attributes to the array & matrix 
instances? I would find them very useful for some cases more convenient 
than asarray() or mat(). Let x.A just do nothing if x is array and x.M 
do nothing if x i matrix.

2)And if y=flat(x), what about y.R and y.C for to making y row-ndarray & 
column-ndarray (for to further convenient error-safe multiplication to 
2-dim arrays)? + maybe the same thing for ndarray & matrix instances?

3)What about new dotwise & matrix operators - after reading the 
discussion I would better wait for unicode instead of implementing 
2-symbol operators, for to make it once & forever.

WBR, D.

Bill Baxter wrote:
> On 3/26/07, Charles R Harris <charlesr.harris@gmail.com> wrote:
>   
>> What might work better is simply some sort of sign that causes a function to
>> be parsed as infix, x @dot y for instance, although Python already uses @
>> for other things. I don't know what symbols are left unused at this point,
>> maybe ! , $, and ~.
>>     
>
> I'm not really an expert on compilers, but from what I understand, the
> biggest problem with adding new operators is defining precedence.
> Without it, the interpreter won't know what to do with something like
> A @dot B @plus C.  Currently the interpreter only has to look at what
> the tokens are to build a parse tree out of something like A*B+C.  It
> doesn't matter what the types of A B and C are, that's always parsed
> as (A*B)+C.  If you add a @dot operator where do you define its
> precedence?  On the class that defines the operator?  What if two
> classes define the same operator with different precedences?  It gets
> to be a big ambiguous mess.
>
> So if you're going to add new operators they pretty much need to have
> globally predetermined precedence to allow the parser to remain sane.
> I think it's ML or Haskell that lets you define any operator you want
> out of the core operator tokens (eg "*+*") but IIRC the first char
> determines the precedence.  So *+* has the same precedence as "*".
> Requiring the new operator to include an existing operator char seems
> like a reasonable strategy since it gives a simple rule-based
> mechanism for determining precedence that is easy for both the parser
> and for users.
>
> --bb
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>   



More information about the Numpy-discussion mailing list