Discussion: Introducing new operators for matrix computation

[Garry Hodgson]

Huaiyu Zhu wrote:

> Point 1.  We _can_ assign a universal meaning to dot operators, as
> "componentwise operators".  For example
> 
> [1, 2] + [3, 4]             # [1, 2, 3, 4]
> [1, 2] .+ [3, 4]            # [4, 6]
> ['a','b'] * 2               # ['a','b','a','b']
> ["a","b"] .* 2              # ['aa', 'bb']
> {'a':1, 'b':1} .+ {'a':1, 'c':1}   # {'a':2, 'b':1, 'c': 1}
> 'abc' .+ 'def'              # exception: you must define string.__dot_add__
> 
> This could be useful in all sorts of situations.  Of course people can still
> override it with incompatible meanings at their own discretion, just as they
> could do to anything else.
> 
> Point 2. If users in completely disjoint domains override a certain type of
> binary operators with incompatible meanings, is there great harm?  Providing
> a few operators for user adoptation might even prevent grotesque overriding
> of more core operators.  After all, there is almost endless supply of names
> for classes, modules, function and so on, but there is almost no binary
> operators free for adoption.

but outside of this thread, we've seen no great outcry of python
users bemoaning the lack of cryptic operators.  changing the language
for this specific domain is not a good idea.  putting in new operators
because they might be usefully overloaded for other specific domains
is little better.

-- 
Garry Hodgson                   Every night 
garry at sage.att.com                a child is born
Software Innovation Services        is a Holy Night.
AT&T Labs                         - Sophia Lyon Fahs