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 <[EMAIL PROTECTED]> 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 > > > > _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
