@chintanp: Even though I did skim the help pages yesterday, I did not locate the output option. Now I have. Thanks.

Concerning your "gem of a syntax": Could you provide the context in which your statement figures? In the form given now, I am unable to execute it in Maple, the variables figuring in it being unknown.

I have never used the CodeGeneration package before, but for a start I am confused to find that expr below is empty:

expr := C((u - 0.2*v^2) / m);
cg = (u - 0.2e0 * v * v) / m;

For how then, I ask myself, is one to build from it some other expression, for instance appending to it 'f << dot(v) ==' using, say, concatenation of strings?

@MrYouMath: Sorry to say, but using % here and there is asking for problems, I think. The only way to make such an approach safe, or as safe as possible, is to re-execute the entire worksheet each time changes have been made to it.

Personally I prefer to modularize my code as much as possible, creating procedures and modules that are placed in independent files, to be loaded into the worksheet itself using the read-statement; in this way I avoid very long worksheets. It is probably not the fastest way to get started on any project, but it pays of handsomely in the long run.

@Carl Love: I agree.

The example you give assigns the equation a = b + 1 to the variable x. Perhaps I misunderstand what you have in mind, but why then not simply write solve(x,{b})?

I get stuck, too, but perhaps differently so. When defining your density operator as

K :=
   +Ket(psi,i,h )*Ket(psi,s,h )
   +Ket(psi,i,nu)*Ket(psi,s,nu):
rho := 1/2*Simplify(K*Dagger(K));

it surprises me that the ordering of the two bras in each of the four addends is wrong. Perhaps this is an error in the Maple 17 version of Physics, which I am using, or perhaps it is me doing something wrong.

@ecterrab: Using expand instead of simplify is quite ok with me. I can easily live with that. If I had had the ephiphany of trying out expand myself, I had not posted any question at all :-).

PS: My apology for the somewhat belated response. I have just right now discovered your answer, having on previous visits to this thread simply jumped to the end of the page by hitting Ctrl+End, without realizing (not the first time, I am afraid) that with the default option of listing answers in order of votes (rather than chronologically), I could be missing some.

@vv: Aah, I see. Thanks. I am wondering, though, what relevance it has, or to what use it is, for the original issue of mine.

@fonsi: Happy to hear that.

@Christian Wolinski: I am baffled by this, seeing D[1](f), etc., being assigned something to, instead of being assigned to something, that is, I am baffled about the left/right-hand side interchanges of your expressions.

@ecterrab: Thanks for your answer. I had a hunch that the issue could not be remedied within my present Maple release. Updating Maple is indeed something I have been considering for some time.

@vv: It certainly is a workaround, and thanks for that. But, hopefully not appearing ungrateful, that was not what my intention with my question was. I would like to know why it has been implemented that way, and perhaps even more, why it has not been fixed (at least not as of Maple 17, which I am using).

@vv: Tweaking your suggestion a bit,

e := (D[1]@D[1] - D[1,1])(f);
unapply(convert(e(x),diff),x);

indeed shows that D[1]@D[1] and D[1,1] are equivalent, the result above being the zero map. But, please forgive me, it still does not seem satisfactory to me. Why does one have to assort to such semi-convoluted things, I ask myself, when the equivalence should have been a no-brainer. I would appreciate some response on that question from some MapleSoft-developer.

@vv: But if no arguments, like x, are present, which is the case I am interested in, then the following results [your code rewritten a bit]:

expr := (D[1]@D[1])(f);
expr := convert(expr,diff);
expr := convert(expr,D);
lprint(expr);

(D[1]@@2)(f)

For comparison, note that (D[1]@D[2] - D[1,2])(f) vanishes without being applied to any arguments.

@Mac Dude: I concur, still. What I assert, at least by now, is simply the equivalence of the two previously given expressions as literally written. Nothing more.