[Numpy-discussion] New Operators in Python

[Travis Oliphant]

Every so often the idea of new operators comes up because of the need to 
do both "matrix-multiplication" and element-by-element multiplication.

I think this is one area where the current Python approach is not as 
nice because we have a limited set of operators to work with.

One thing I wonder is if we are being vocal enough with the Python 3000 
crowd to try and get additional operators into the language itself.

What if we could get a few new operators into the language to help us.   
If we don't ask for it, it certainly won't happen.
My experience is that the difficulty of using the '*' operator for both 
matrix multiplication and element-by-element multiplication depending on 
the class of the object is not especially robust.  It makes it harder to 
write generic code, and we still haven't gotten everything completely 
right.

It is somewhat workable as it stands, but I think it would be nicer if 
we could have some "meta" operator that allowed an alternative 
definition of major operators.   Something like @*  for example (just 
picking a character that is already used for decorators).

I wonder if we should propose such a thing for Python 3000.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Matthieu Brucher]

Hi,

I followed the discussion on the scipy ML, and I would advocate it as well.
I miss the dichotomy that is present in Matlab, and to have a similar degree
of freedom, it would be good to have it in the upcoming major release of
Python.

Matthieu

2007/3/24, Travis Oliphant <[EMAIL PROTECTED]>:


Every so often the idea of new operators comes up because of the need to
do both "matrix-multiplication" and element-by-element multiplication.

I think this is one area where the current Python approach is not as
nice because we have a limited set of operators to work with.

One thing I wonder is if we are being vocal enough with the Python 3000
crowd to try and get additional operators into the language itself.

What if we could get a few new operators into the language to help us.
If we don't ask for it, it certainly won't happen.
My experience is that the difficulty of using the '*' operator for both
matrix multiplication and element-by-element multiplication depending on
the class of the object is not especially robust.  It makes it harder to
write generic code, and we still haven't gotten everything completely
right.

It is somewhat workable as it stands, but I think it would be nicer if
we could have some "meta" operator that allowed an alternative
definition of major operators.   Something like @*  for example (just
picking a character that is already used for decorators).

I wonder if we should propose such a thing for Python 3000.

-Travis

___
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

Re: [Numpy-discussion] New Operators in Python

[Charles R Harris]

On 3/24/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:


Every so often the idea of new operators comes up because of the need to
do both "matrix-multiplication" and element-by-element multiplication.

I think this is one area where the current Python approach is not as
nice because we have a limited set of operators to work with.

One thing I wonder is if we are being vocal enough with the Python 3000
crowd to try and get additional operators into the language itself.

What if we could get a few new operators into the language to help us.
If we don't ask for it, it certainly won't happen.
My experience is that the difficulty of using the '*' operator for both
matrix multiplication and element-by-element multiplication depending on
the class of the object is not especially robust.  It makes it harder to
write generic code, and we still haven't gotten everything completely
right.

It is somewhat workable as it stands, but I think it would be nicer if
we could have some "meta" operator that allowed an alternative
definition of major operators.   Something like @*  for example (just
picking a character that is already used for decorators).



Yes indeed, this is an old complaint. Just having an infix operator would be
an improvement:

A dot B dot C

Not that I am suggesting dot in this regard ;) In particular, it wouldn't
parse without spaces. What about division? Matlab has both / and \ for left
and right matrix division and something like that could call solve instead
of inverse, leading to some efficiencies. We also have both dot and
tensordot, which raises the problem of interpretation when ndim > 2.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Sebastian Haase]

On 3/24/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
> On 3/24/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> > Every so often the idea of new operators comes up because of the need to
> > do both "matrix-multiplication" and element-by-element multiplication.
> >
> > I think this is one area where the current Python approach is not as
> > nice because we have a limited set of operators to work with.
> >
> > One thing I wonder is if we are being vocal enough with the Python 3000
> > crowd to try and get additional operators into the language itself.
> >
> > What if we could get a few new operators into the language to help us.
> > If we don't ask for it, it certainly won't happen.
> > My experience is that the difficulty of using the '*' operator for both
> > matrix multiplication and element-by-element multiplication depending on
> > the class of the object is not especially robust.  It makes it harder to
> > write generic code, and we still haven't gotten everything completely
> > right.
> >
> > It is somewhat workable as it stands, but I think it would be nicer if
> > we could have some "meta" operator that allowed an alternative
> > definition of major operators.   Something like @*  for example (just
> > picking a character that is already used for decorators).
>
> Yes indeed, this is an old complaint. Just having an infix operator would be
> an improvement:
>
> A dot B dot C
>
> Not that I am suggesting dot in this regard ;) In particular, it wouldn't
> parse without spaces. What about division? Matlab has both / and \ for left
> and right matrix division and something like that could call solve instead
> of inverse, leading to some efficiencies. We also have both dot and
> tensordot, which raises the problem of interpretation when ndim > 2.
>
> Chuck
>
I understand the convenience of more infix operators. And I sometimes
think one should just be able to define new ones at will 

On the other hand, I'm now playing the devil's advocate:
A "math specific" language like Matlab has obviously an overwhelming
need for a second set of matrix/array operators.  However, a language
-- as broadly used as -- Python might be just better off having a
simple, concise and limited set of infix operators.   I assume that
this is the official argument.

I got especially "worried" when being remember of the "\"
right-to-left  division operator. (As I said, it very useful to have
in Matlab, and I wish sometimes we could add things like this).
It is just important to keep the "con" - argument clearly in mind.
I hope this helps the discussion.

- Sebastian Haase
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Anne Archibald]

On 24/03/07, Charles R Harris <[EMAIL PROTECTED]> wrote:

> Yes indeed, this is an old complaint. Just having an infix operator would be
> an improvement:
>
> A dot B dot C
>
> Not that I am suggesting dot in this regard ;) In particular, it wouldn't
> parse without spaces. What about division? Matlab has both / and \ for left
> and right matrix division and something like that could call solve instead
> of inverse, leading to some efficiencies. We also have both dot and
> tensordot, which raises the problem of interpretation when ndim > 2.

There's always the Haskell approach: *every* function can be an infix
operator, just surround the name with backticks; functions with
line-noise names (like + * - /) are infix by default.

Not a good idea for python, I think.

Anne.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Colin J. Williams]

Charles R Harris wrote:
> 
> 
> On 3/24/07, *Travis Oliphant* <[EMAIL PROTECTED] 
> > wrote:
> 
> Every so often the idea of new operators comes up because of the need to
> do both "matrix-multiplication" and element-by-element multiplication.
> 
> I think this is one area where the current Python approach is not as
> nice because we have a limited set of operators to work with.
> 
> One thing I wonder is if we are being vocal enough with the Python 3000
> crowd to try and get additional operators into the language itself.
> 
> What if we could get a few new operators into the language to help us.
> If we don't ask for it, it certainly won't happen.
> My experience is that the difficulty of using the '*' operator for both
> matrix multiplication and element-by-element multiplication
> depending on
> the class of the object is not especially robust.  It makes it harder to
> write generic code, and we still haven't gotten everything completely
> right.
> 
> It is somewhat workable as it stands, but I think it would be nicer if
> we could have some "meta" operator that allowed an alternative
> definition of major operators.   Something like @*  for example (just
> picking a character that is already used for decorators).
> 
> 
> Yes indeed, this is an old complaint. Just having an infix operator 
> would be an improvement:
> 
> A dot B dot C
> 
> Not that I am suggesting dot in this regard ;) In particular, it 
> wouldn't parse without spaces. What about division? Matlab has both / 
> and \ for left and right matrix division and something like that could 
> call solve instead of inverse, leading to some efficiencies. 

Yes, thanks to a suggestion from Alan Isaac, this was implemented in 
PyMatrix (based on numarray and not yet converted to numpy). / served 
for one and // for the other.

Regarding an additional multiply operator, I don't see the need for it. 
   A matrix and and array are similar dut different animals.

Colin W.

We also
> have both dot and tensordot, which raises the problem of interpretation 
> when ndim > 2.
> 
> Chuck
> 
> 
> 
> 
> 
> ___
> 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

Re: [Numpy-discussion] New Operators in Python

[dpn]

With the possible inclusion of generic functions in py3k I dont really
see the point of adding more operators. (While i do miss mat1 x mat2
from PDL).

mat3 = mat1.mm(mat2) or the like seems to be sufficient.

I find matrix multiplication annoying in the case of SVD reconstruction:

final = matrixmultiply(matrixmultiply(u, s), v)

A minor gripe though. I'm more inclined to err on the side of clean
python rather than more operators, especially since aforementioned
GF's will help with many cases

dpn

On 3/26/07, Colin J. Williams <[EMAIL PROTECTED]> wrote:
> Charles R Harris wrote:
> >
> >
> > On 3/24/07, *Travis Oliphant* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Every so often the idea of new operators comes up because of the need to
> > do both "matrix-multiplication" and element-by-element multiplication.
> >
> > I think this is one area where the current Python approach is not as
> > nice because we have a limited set of operators to work with.
> >
> > One thing I wonder is if we are being vocal enough with the Python 3000
> > crowd to try and get additional operators into the language itself.
> >
> > What if we could get a few new operators into the language to help us.
> > If we don't ask for it, it certainly won't happen.
> > My experience is that the difficulty of using the '*' operator for both
> > matrix multiplication and element-by-element multiplication
> > depending on
> > the class of the object is not especially robust.  It makes it harder to
> > write generic code, and we still haven't gotten everything completely
> > right.
> >
> > It is somewhat workable as it stands, but I think it would be nicer if
> > we could have some "meta" operator that allowed an alternative
> > definition of major operators.   Something like @*  for example (just
> > picking a character that is already used for decorators).
> >
> >
> > Yes indeed, this is an old complaint. Just having an infix operator
> > would be an improvement:
> >
> > A dot B dot C
> >
> > Not that I am suggesting dot in this regard ;) In particular, it
> > wouldn't parse without spaces. What about division? Matlab has both /
> > and \ for left and right matrix division and something like that could
> > call solve instead of inverse, leading to some efficiencies.
>
> Yes, thanks to a suggestion from Alan Isaac, this was implemented in
> PyMatrix (based on numarray and not yet converted to numpy). / served
> for one and // for the other.
>
> Regarding an additional multiply operator, I don't see the need for it.
>A matrix and and array are similar dut different animals.
>
> Colin W.
>
> We also
> > have both dot and tensordot, which raises the problem of interpretation
> > when ndim > 2.
> >
> > Chuck
> >
> >
> >
> > 
> >
> > ___
> > 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
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Paulo Jose da Silva e Silva]

Em Seg, 2007-03-26 às 01:08 +1000, dpn escreveu:
> With the possible inclusion of generic functions in py3k I dont really
> see the point of adding more operators. (While i do miss mat1 x mat2
> from PDL).
> 
> mat3 = mat1.mm(mat2) or the like seems to be sufficient.
> 
> I find matrix multiplication annoying in the case of SVD reconstruction:
> 
> final = matrixmultiply(matrixmultiply(u, s), v)
> 

Matrix multiplication is just too common in numerical linear algebra,
one of the main areas for numpy/scipy. Even though I can get used with
using dot (or matrixmultiply) to do it, I can easily see the benefit of
having a special operator here. This will be beneficial for
mathematicians that use numpy/scipy to prototype some ideas or to
newcomers from Matlab.

Paulo
-- 
Paulo José da Silva e Silva 
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil

e-mail: [EMAIL PROTECTED]   Web: http://www.ime.usp.br/~rsilva

Teoria é o que não entendemos o (Theory is something we don't)
suficiente para chamar de prática.  (understand well enough to call practice)

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Alan G Isaac]

On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote: 
> Even though I can get used with using dot (or 
> matrixmultiply) to do it, I can easily see the benefit of 
> having a special operator here. 

Some newer languages are taking advantage of the 
expressiveness of Unicode for math purposes.  I believe 
somone on this list asked whether this might provide a way 
forward.  Can it (taking a long view)?  For example, it 
would be natural to use as operators the Unicode 
multiplication sign U+00D7 (×) and the Unicode dot operator 
U+22C5 (·).  

Cheers,
Alan Isaac 



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Joe Harrington]

I strongly agree with the need for different infix operators for
matrix and array multiplication.  In IDL, I have used both in the same
code.  IDL uses * for array and # for matrix (hey, # even *looks* like
a matrix, very intuitive).  It uses ## for right-multiply (why people
don't just M-t the variable names I don't know, though maybe people
who do more linear algebra than I can say).

There's an important justification that hasn't come up yet, and that
is advocacy.  Languages are good or not good depending on how readable
and writeable they are for various purposes.  LISP is a technically
very powerful language.  It was object-oriented a zillion years before
C++.  It had and has powerful proponents within CS, such as Stallman.

But, whenever CS people try to push LISP outside their ivory tower, it
gets trashed.  The LISP dialect Guile was written as the GNU project's
extension language and nobody used it.  Now projects like GIMP have
two extension languages, Guile and Python.  Why?  LISP is great for
analyzing the flow and structure of computer code, but LISP math does
not look like real math, which makes it very difficult and
counterintuitive to use for math or math-heavy topics like graphics.
It has little syntactic sugar to make common math tasks either quick
to write or easy to understand or verify, until you've retrained your
brain.  So, even though there are tons of technical people exposed to
LISP, nobody outside CS adopts it who doesn't have to.

On the other hand, Python, IDL, and Matlab are attractive to us mainly
because their syntaxes allow us to see the math, understand it on
inspection, and verify its correctness.  The math we write in these
languages looks as much like the math we do on paper as ASCII will
allow.  (Obviously, we also choose them because we don't like writing
loops and declaring variables.)

So, whenever I hear someone suggest using a functional syntax for a
concept that exists notationally, I cringe.  We're alienating a class
of users each time we do that.  Those are people who will never come
to Python.  There are extremes to which this argument cannot go - a
prime will never be a derivative because quotes are more important -
but I think that matrix multiplication is a no-brainer here.  We
should let the Python developers know we want it now and then follow
up with a syntax and implementation.

--jh--
Prof. Joseph Harrington
Department of Physics
MAP 420
University of Central Florida
Orlando, FL 32816-2385
(407) 823-3416 voice
(407) 823-5112 fax
(407) 823-2325 physics office
[EMAIL PROTECTED]   (direct)
[EMAIL PROTECTED]   (permanent forwarding address, will work 
forever)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Steven H. Rogers]

Joe Harrington wrote:
> 
> On the other hand, Python, IDL, and Matlab are attractive to us mainly
> because their syntaxes allow us to see the math, understand it on
> inspection, and verify its correctness.  The math we write in these
> languages looks as much like the math we do on paper as ASCII will
> allow.  (Obviously, we also choose them because we don't like writing
> loops and declaring variables.)
> 
> So, whenever I hear someone suggest using a functional syntax for a
> concept that exists notationally, I cringe.  We're alienating a class
> of users each time we do that.  Those are people who will never come
> to Python.  There are extremes to which this argument cannot go - a
> prime will never be a derivative because quotes are more important -
> but I think that matrix multiplication is a no-brainer here.  We
> should let the Python developers know we want it now and then follow
> up with a syntax and implementation.
> 
> 

Sun's Fortress programming language 
(http://research.sun.com/projects/plrg/faq/index.html) will include 
Unicode operators and two dimensional equations.  Something like this 
should be possible for NumPy.  The question is how much can and should 
be pushed into the Python core language.

# Steve
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Bill Baxter]

On 3/26/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
> Joe Harrington wrote:
> >
> > On the other hand, Python, IDL, and Matlab are attractive to us mainly
> > because their syntaxes allow us to see the math, understand it on
> > inspection, and verify its correctness.  The math we write in these
> > languages looks as much like the math we do on paper as ASCII will
> > allow.  (Obviously, we also choose them because we don't like writing
> > loops and declaring variables.)
> >
> > So, whenever I hear someone suggest using a functional syntax for a
> > concept that exists notationally, I cringe.  We're alienating a class
> > of users each time we do that.  Those are people who will never come
> > to Python.  There are extremes to which this argument cannot go - a
> > prime will never be a derivative because quotes are more important -
> > but I think that matrix multiplication is a no-brainer here.  We
> > should let the Python developers know we want it now and then follow
> > up with a syntax and implementation.
> >
> >
>
> Sun's Fortress programming language
> (http://research.sun.com/projects/plrg/faq/index.html) will include
> Unicode operators and two dimensional equations.  Something like this
> should be possible for NumPy.  The question is how much can and should
> be pushed into the Python core language.

Until we get to the point that it's actually harder to find a
non-Unicode console/editor than a Unicode one, I think the idea of
using Unicode symbols as part of the syntax of a general purpose
language is a bad one.

I'm looking forward to see what becomes of Fortress, but it's
basically still an experiment at this point.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Charles R Harris]

On 3/25/07, Bill Baxter <[EMAIL PROTECTED]> wrote:


On 3/26/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
> Joe Harrington wrote:
> >
> > On the other hand, Python, IDL, and Matlab are attractive to us mainly
> > because their syntaxes allow us to see the math, understand it on
> > inspection, and verify its correctness.  The math we write in these
> > languages looks as much like the math we do on paper as ASCII will
> > allow.  (Obviously, we also choose them because we don't like writing
> > loops and declaring variables.)
> >
> > So, whenever I hear someone suggest using a functional syntax for a
> > concept that exists notationally, I cringe.  We're alienating a class
> > of users each time we do that.  Those are people who will never come
> > to Python.  There are extremes to which this argument cannot go - a
> > prime will never be a derivative because quotes are more important -
> > but I think that matrix multiplication is a no-brainer here.  We
> > should let the Python developers know we want it now and then follow
> > up with a syntax and implementation.
> >
> >
>
> Sun's Fortress programming language
> (http://research.sun.com/projects/plrg/faq/index.html) will include
> Unicode operators and two dimensional equations.  Something like this
> should be possible for NumPy.  The question is how much can and should
> be pushed into the Python core language.

Until we get to the point that it's actually harder to find a
non-Unicode console/editor than a Unicode one, I think the idea of
using Unicode symbols as part of the syntax of a general purpose
language is a bad one.

I'm looking forward to see what becomes of Fortress, but it's
basically still an experiment at this point.



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

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Steven H. Rogers]

Bill Baxter wrote:
> 
> Until we get to the point that it's actually harder to find a
> non-Unicode console/editor than a Unicode one, I think the idea of
> using Unicode symbols as part of the syntax of a general purpose
> language is a bad one.

Given that most editors lack good Unicode support, it can be used as an 
alternate syntax, but not the only syntax.  For the foreseeable future, 
both syntaxes would have to be supported.  All that is needed is *one* 
reasonable editor with sufficient support for a Unicode Python syntax, 
and others will follow.  Since Idle is often used by Python beginners, 
it would be a good candidate.

> 
> I'm looking forward to see what becomes of Fortress, but it's
> basically still an experiment at this point.
> 
I think Fortress is more than an experiment, though it is still a long 
way from being useful for real work.

# Steve
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Bill Baxter]

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

Re: [Numpy-discussion] New Operators in Python

[dmitrey]

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

Re: [Numpy-discussion] New Operators in Python

[René Bastian]

Hello,

I am interest both in numarray type multiplication and matrix type 
multiplication.

But I am not shure that I can buy an Unicode keyboard.

May be it would be possible to implement a class with
user "definissable" (?) signs.

My choice :

a * b -> numarray type multi
a !* b -> matrix


-- 
René Bastian
http://www.musiques-rb.org
http://pythoneon.musiques-rb.org


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[dmitrey]

The unicode keyboards sailing everywhere is just a matter of time
And python 2-symbol operators soon will look obsolete, this will 
increase migrating from python to Sun fortress etc. I took a look at 
their unicode syntax for math formulas
http://research.sun.com/projects/plrg/faq/NAS-CG.pdf
it looks (vs Python) (or even MATLAB) like Pentium 4 vs Intel 386 
processors.
It just allows copy-paste from articles of many formulas, including 
"ro", 'beta' and other non-ascii symbols
Also, implementing unicode will allow separate operators for (for 
example) MATLAB cross() equivalent (vector multiplication of vectors).
WBR, D.

René Bastian wrote:
> Hello,
>
> I am interest both in numarray type multiplication and matrix type 
> multiplication.
>
> But I am not shure that I can buy an Unicode keyboard.
>
> May be it would be possible to implement a class with
> user "definissable" (?) signs.
>
> My choice :
>
> a * b -> numarray type multi
> a !* b -> matrix
>
>
>   

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Zachary Pincus]

Hi folks,

Sorry to rain on this parade, but unicode variable names and/or other  
syntactic elements have already been rejected for Python 3:

http://www.python.org/dev/peps/pep-3099/
> Python 3000 source code won't use non-ASCII Unicode characters for  
> anything except string literals or comments.
To tell the truth, in my code (for an n=1 example), I use elementwise  
(or broadcasted) multiplication about an order of magnitude more than  
matrix multiplication. Now, there's plenty of linear algebra in my  
work, but it's usually boxed off enough from the rest that converting  
everything to matrices, or using the 'dot' function (etc.), is just  
fine.

Personally, I even prefer the current way that numpy does things --  
I've always *really* disliked matlab's special syntax for elementwise  
multiplication. Now, clearly there are cases where this is handy, but  
at least in looking over my code, I find that those cases are quite  
rare, really.

So, in large part, I really don't feel a strong need for new  
operators in numpy. (And in the rest of python too! The @ decorator  
pie-syntax is quite enough for line-noise characters, in my personal  
opinion. And I think that python-dev pretty well agrees too, based on  
the raging flame wars about adding even that.)

Now, this is of course just my single opinion, but folks should  
recall that even C++, which rarely met a feature that it didn't like,  
drew the line at adding extra syntactic operators to the language  
that existed only to be overridden/implemented by users. (Which is  
precisely what's being proposed here.)

Anyhow, feel free to disagree with me -- I'm no expert here. I'm only  
mentioning this as a public service to make it clear that most of  
what's being proposed in this thread is, for better or worse, 100%  
dead-in-the-water for Python 3, and the rest will have a fairly  
significant uphill battle.

Zach




On Mar 26, 2007, at 2:42 AM, dmitrey wrote:

> The unicode keyboards sailing everywhere is just a matter of time
> And python 2-symbol operators soon will look obsolete, this will
> increase migrating from python to Sun fortress etc. I took a look at
> their unicode syntax for math formulas
> http://research.sun.com/projects/plrg/faq/NAS-CG.pdf
> it looks (vs Python) (or even MATLAB) like Pentium 4 vs Intel 386
> processors.
> It just allows copy-paste from articles of many formulas, including
> "ro", 'beta' and other non-ascii symbols
> Also, implementing unicode will allow separate operators for (for
> example) MATLAB cross() equivalent (vector multiplication of vectors).
> WBR, D.
>
> René Bastian wrote:
>> Hello,
>>
>> I am interest both in numarray type multiplication and matrix type
>> multiplication.
>>
>> But I am not shure that I can buy an Unicode keyboard.
>>
>> May be it would be possible to implement a class with
>> user "definissable" (?) signs.
>>
>> My choice :
>>
>> a * b -> numarray type multi
>> a !* b -> matrix
>>
>>
>>
>
> ___
> 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

Re: [Numpy-discussion] New Operators in Python

[Steven H. Rogers]

Zachary Pincus wrote:
> 
> Anyhow, feel free to disagree with me -- I'm no expert here. I'm only  
> mentioning this as a public service to make it clear that most of  
> what's being proposed in this thread is, for better or worse, 100%  
> dead-in-the-water for Python 3, and the rest will have a fairly  
> significant uphill battle.
> 

Don't disagree about the uphill battle part, but I believe that you're 
overly pessimistic about Unicode.  Unicode variables and operators have 
only been rejected for Python 3.0, though the degree of Unicode support 
is still under discussion.  If the core developers are convinced that 
enough people would use it, and it is implemented in a maintainable way, 
it is certainly possible for 3.1 or 3.2.

# Steve
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Beliavsky]

On Mar 24, 3:48 pm, "Charles R Harris" <[EMAIL PROTECTED]>
wrote:

> > It is somewhat workable as it stands, but I think it would be nicer if
> > we could have some "meta" operator that allowed an alternative
> > definition of major operators.   Something like @*  for example (just
> > picking a character that is already used for decorators).
>
> Yes indeed, this is an old complaint. Just having an infix operator would be
> an improvement:
>
> A dot B dot C

In Fortran 90 and later versions, A*B means element-wise
multiplication, and there exist intrinsic functions such as
matmul(A,B) and dot_product(A,B). One can define operators so that

A .x. B .x. C

is the same as matmul(A,matmul(B,C))

although I am unsure of the order of operations implied by the former
syntax. The Matran http://www.cs.umd.edu/~stewart/matran/Matran.html
package does this. I think Fortran's infix operators are a good
solution but don't know if it can be carried over to Python.

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[tan2]

On 3/26/07, René Bastian <[EMAIL PROTECTED]> wrote:


May be it would be possible to implement a class with
user "definissable" (?) signs.



Yes, it is possible and is done.
See this recipe to define an Infix operator class either:

x |op| y
or:
x <> y


http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/384122

Eh Tan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion