## How can I define a ⊕ operator?

6

1

What is wrong with the following code?

CirclePlus := SparseArray[Band[{1, 1}] -> {##}] &
a_ ⊕ b_ := CirclePlus[a, b]


SetDelayed::write: Tag Function in (SparseArray[Band[{1,1}]->{##1}]&)[a_,b_] is Protected. >>

I want to define the operator ⊕ to work like +,-,*,/, so it can be used as a ⊕ b.

2CirclePlus := SparseArray[Band[{1, 1}] -> {##}] &; Normal[a\[CirclePlus]b] – Dr. belisarius – 2014-01-08T03:51:06.883

@belisarius Thanks! Can you explain why? and I want to define the operation \[CirclePlus] like +,-,*,/ which can be used as a \[CirclePlus] b. – Eden Harder – 2014-01-08T04:53:49.077

3@EdenHarder Then you should define it as CirclePlus[a_, b_] := SparseArray[Band[{1, 1}] -> {a, b}] and this can be used as a ⊕ b. – rm -rf – 2014-01-08T05:12:07.353

@rm-rf Thanks! Can you analyze the error in my original code to teach me a lesson? – Eden Harder – 2014-01-08T05:17:19.980

Certainly! But I'm afraid I'll have to write it in the morning... it's night time here and I'm sleepy. Sorry about that, but I'll come back to it. – rm -rf – 2014-01-08T05:57:42.857

1

– Mr.Wizard – 2014-01-08T13:52:55.097

9

CirclePlus is a built-in symbol already with no meaning for the kernel, but meaning in the front-end.

The second definition tried to use the first definition (with head 'Function'), which is protected. (Note the pattern [a_,b_] appearing in the error message, which tells you the left-hand-side is the issue.)

Just one line is enough as @rm-rf said, like this...

a_ ⊕ b_ := SparseArray[Band[{1, 1} -> {a, b}]]


The front-end translates ⊕ for you into CirclePlus - this is what I meant when said that it has meaning in the front-end.

More detailed explanation

I was thinking that what I said may not be clear enough, in the sense that the workings of SetDelayed (aka :=) were not clearly exposed.

The fact that SetDelayed has attribute HoldAll does not mean that the expression on the left is not evaluated by the kernel in order to determine which head the defining rule gets attached to. No, it is actually evaluated!

Let me illustrate with a simple and quick example. If you execute the following

MyX[1] := Y;
MyX[x_] := Z;


then which heads are being defined here?

MyX[1][a_] := a^2;
MyX[x][a_] := a;


?Y


?Z


Interesting, ah?

So, this is what happened in your case. CirclePlus was undefined for the kernel until you gave it the first definition without a pattern. When you attempted the second one, the kernel already knew something about the head and try to evaluate it and got Function. There the evaluation stopped and then it tried to associate the second rule with this Function head - error.

By the way, be careful your definition only knows about CirclePlus[a,b], but the front end treats a ⊕ b ⊕ c as a single CirclePlus[a,b,c], which is unknown to the kernel with the definition provided.

Thanks for your wonderful answer! But we should wait for @rm-rf waking up. He has promised to give an answer. – Eden Harder – 2014-01-08T11:38:48.143

"When you attempted the second one, the kernel already knew something about the head and try to evaluate it and got Function", can we avoid this? – Eden Harder – 2014-01-08T11:41:01.623

@EdenHarder caya has written a nice answer to your question and I have nothing more to add :) – rm -rf – 2014-01-08T15:52:25.350

1In the original two-line definition, one can also just switch the order of the lines. The reason why this works is exactly what caya wrote. – Jens – 2014-01-08T16:54:26.227

Thanks @rm-rf, I couldn't resist explaining this aspect of the Mathematica programming language :) – carlosayam – 2014-01-08T18:10:06.797