@Mac Dude: Thanks for your comment.

It is comforting to know that I am not alone in experiencing worksheets that freeze. Although I have not noticed any Java dialog so far, I think that you may have a point in focusing on the underlying Java platform. Perhaps it is indeed choking on the shortcut keys entered (perhaps too fast?).

In the Java subdirectory of the Maple 17 directory there is only a single filename containing 'log', and it is a .jar file; that does not seem likely to be a log-file. Perhaps the file structure is different on a Mac, but do you have any idea of where I should alternatively look for such a log-file?

Next time a worksheet freezes, I will have a look at how the CPU consumption is for both the maple.exe and maplew.exe process.

@Christopher2222: Thanks for trying. I am using Windows 7.

Today a Maple worksheet of mine froze again, this time, I think, in connection with pressing Ctrl+S (for save) after having typed some other shortcut keys doing other stuff. I still cannot identify exactly what triggers this behaviour.

@Christopher2222: Thanks for your interest. I guess any worksheet, no matter how simple, can freeze this way (and that is really beginning to annoy me): I have just managed to freeze a worksheet consisting of the following mind-bogglingly complicated code:

restart:
2+4;

I did that by trying out some random combination of E, W, Alt E, Alt W, Ctrl E, Ctrl W, and Esc, I think. Here, obviously, there certainly is involved a key combination differing from the one I originally gave, but I am quite unable to say whether or not involving also Ctrl-key combinations is necessary. In any case, Maple should not, of course, freeze this way due to any such key combination.

@acer: Ah, I see. For the fun of it, I tried A^%HT yesterday (perhaps stupidly), but it did not work, so I decided to ask instead. I do wonder why it did not occur to me to try out A^%H.

@Carl Love: I think you misread my added note. What I write is essentially what Kitonum writes below; note that the linear combinations of vectors in my note are not the same: in the first one, the vectors are from the matrix B, whereas for the second one (the inline one), the vectors are from the matrix A.

Thanks for the nice shorthand for Transpose; I did not know that. The vector shorthand I did know. Usually I (like to) write things out in full, though.

I am curious: Does there likewise exist some shorthand for HermitianTranspose?

@ANANDMUNAGALA: Sorry to say, but your suggestion does not seem to work. Even five minutes after having clicked the debug icon, there is no recovery. The program just keeps hanging, the mouse figuring as an hour-glass. Surprisingly, in the Windows Job List nothing much is happening, the CPU consumption being virtually zero. So what is Maple doing?, I ask myself.

@ANANDMUNAGALA: Thanks a lot for your reply. The suggestion of yours does not seem to work, though: I have just provoked the freezing of some simple test worksheet, and was not able to recover from that by clicking on the debug icon.

@Anyone interested: While awaiting the above-mentioned new functionality of the Physics package, I am using the following function of mine to (recursively) remove any and all occurences of Dagger:

myRemoveDagger := proc(x::algebraic)
    if type(x,atomic) then x
    else `if`(op(0,x) = Dagger,
        map(myRemoveDagger,op(1,x)),
        map(myRemoveDagger,     x )
    )
    end if
end proc:

@Axel Vogt: I would and will not use it either. I only accidentally stumbled upon it because I wondered why Maple did not issue an error in response to me having left out by mistake something in some code of mine, thereby making it mathematically ill-defined.

I guess I was lucky this time; in a more complicated code I might perhaps have had to spend hours tracking down the error of mine because Maple would in this way be of no help, on the contrary. Which makes me wonder why MapleSoft at all chooses to implement such strange behaviour.

@Kitonum: You are quite right concerning LinearAlgebra:-Add(). I did not know that a matrix and a scalar could be added this way. But with the code

restart:
A := Matrix(2,(i,j) -> a||i||j):
`+`(A,1);
`+`(A,a);
LinearAlgebra:-Add(A,a);

producing the following output:

it seems to me that the quantity a is regarded by Maple to be a scalar. I think it is a bit unfortunate to have `+`and LinearAlgebra:-Add() act differently on the very same arguments. And it makes no difference to change the code to include an explicit scalar-assumption:

restart:
assume(a::scalar):
A := Matrix(2,(i,j) -> a||i||j):
`+`(A,1);
`+`(A,a);
LinearAlgebra:-Add(A,a);

@Preben Alsholm: Yep, that is spot on. I was indeed being blind, then.

PS: I guess the name of the function, having no 'Block' in it, may mislead one to think that it takes only scalarly arguments.

@ecterrab: Super, I will get an email notification then.

@ecterrab: Good catch. I myself did not catch the problem with the assumptions on the functions, even though I did use getassumptions; I wonder why.

Thanks for your intention to implement the scalarobject-option in Setup. I will look forward to that. Please feel no pressure - I do, of course, fully understand that you are overloaded for the time being if there is a new Maple release coming up. Could you notify me when the implementation has taken place?

@ecterrab: Thanks for an extensive reply. There seems to be a problem, though, with Grassmann-valued functions: Without functions,

expr := theta1*theta2:
Dagger(expr);
assume(theta1,scalar):
assume(theta2,scalar):
Dagger(expr);
evalc(Dagger(expr));

it works fine, but with functions (of the spacetime coordinates, say) involved,

expr := theta1(t,x,y,z)*theta2(t,x,y,z):
Dagger(expr);
assume(theta1(t,x,y,z),scalar):
assume(theta2(t,x,y,z),scalar):
Dagger(expr);
evalc(Dagger(expr));

the result is not as expected. But perhaps I am using the assume-facility in an illegal way in connection with functions!?

Regarding specifying objects as being scalarly or real, I was wondering if it would not be useful to have a notation analogous to anticommutativepre = theta, i.e. something like scalarobjectpre = theta or realobjectpre = theta, so that there would be no need to explicitly specify a set of such quantities (such as in G).

PS: Thanks for the very nice tip interface(showassumed = 0) to remove any trailing tilde. I will, no doubt, use it in other settings as well.

@ecterrab: Thanks for turning my attention to Dagger, which do indeed act quite correctly on both scalarly and nonscalarly (in the matrix sense) quantities.

At the quantum mechanical level, i.e. when working with operators, it makes perfect sense - indeed it is required - that Dagger of, say, a Dirac four-column field operator is a four-row field operator with each component itself dagger'ed.

But when implementing at the classical level the Majorana Lagrangian or the Dirac Lagrangian, say, using real- or complex Grassmannians, it becomes somewhat a nuisance to carry around the dagger'ed field components (as opposed to just complex conjugated ones), as these components are no longer operators. For one thing, it makes the number of addends proliferate from 36 to 144, i.e. by a factor of four, for the explicitly (i.e. not modulo a four-divergence) hermitian Dirac Lagrangian. [In Maple 9.5, my former working platform, I had implemented my own Grassmannian calculus, and here the 36 terms arose.]

Thus, at least, it would be nice to be able to manually 'kill' the daggers on any real (as opposed to complex) Grassmannian number. Is there a command for doing such a thing? Something analogous to evalc()?