Discussion: Introducing new operators for matrix computation -gen

[bjorn at roguewave.com.bbs]

Andrew Henshaw wrote:

> Gregory Lielens  wrote:
> >John Lull wrote:
> ...snip...
>
> >> I'm don't think this is quite fair.  You could just as easily write:
> >>  b = rDiv(X, y) >> if you simply had an appropriate rDiv() function.
> ..snip..
> >Indeed, but it is the old choice between functional/operator notation...
> >For example, the second expression, b = (X'*X)\(X'*y), would be in
> >functional notation
> >something like b=rDiv(Mul(X.T(),X),Mul(X.T(),y))
> >This is ok, but imho far more error prone than operator notation,
> >because
> >- all linear algebra textbooks present expressions with operator
> >notation
> >- the operator notation is more natural to almost everybody when dealing
> >with arithmetic
> >
> I wonder if some of these problems could be approached in a more general
> manner.  What if Python could support the definition of operators in the
> same manner as functions? If that were the case then something like:
>
> opr rDiv(X, y):
>
> would define a new operator function that would work like:
>
> b = X rDiv y
>
> The big advantage would be that special purpose grammars could be easily
> imported.  The core language could be kept as simple as possible, but still
> be extensible in a  way that matters to a lot of people.
>
> I suspect that whitespace would be required around these new 'operators',
> although many people already do that with regular operators.  Also, I'm not
> sure how you'd specify an operator that wasn't valid as a function name, but
> I can think of possibilities.

Prolog does this (you'll of course have to specify the precedence of the
operator also, and to solve the current perceived problem probably their
associativity too...)

It's something that works relatively well in Prolog, but then Prolog doesn't
have namespaces etc... If you think you can solve those problems, I would
encourage you to try to implement it and try your solution in a couple of
different domains (matrix-, db-, xml-, string- processing?)  It could be useful,
and if it is, then we can discuss whether it should be added to the core.

Thankfully, Python doesn't add new ideas to the core before they have been tried
out sufficiently first. C++ did, and has ended up working around design problems
(how many people really know how Koenig lookup works...?)

python-the-lean-mean-fighting-machine-with-batteries-included'ly y'rs
-- bjorn