Maple hanging (for a significant time or "forever") when one right clicks in an execution group, whether on a selected text or not, seems to be related to the long "parsing" time when executing the group that I discuss in the thread "Excessive time for Maple to "Parse" an execution group before computing in the Standard Worksheet". I say this because the "right click hang" goes away when the "excessive parsing time" is cured.

First the apparent cause: As you will see if you read the "excessive parsing time" entries, the problem may be a long way from where  you are clicking in the group and be logically unrelated. It appears that, when you right click on text in an execution group, Maple first seems to "parse" the whole execution group. When certain problems appear in the group somewhere, this may cause Maple to take a long time "parsing" or even, apparently, to go into an infinite loop. If that problem is cleared up, this hanging goes away. In my case, I had to substitute evaln( ) for non-evaluation marks for an indexed variable rather far away from where I was clicking.

The workaround: For some reason this hanging doesn't occur if one uses the "fixed" menus at the top of the screen instead of the context menu. Thus I could edit the text using cut, copy, and paste from the Edit menu. Until the real problem was fixed, right clicking to use the context menu to do these jobs generally led to having to have Task Manager kill Maple and, of course, not getting the editing done.

 

Yes, that is a good idea to put my descriptions on a Software Change Request. Thank you.

But, I believe my contributions also contain useful information to other users about particular bad editiing/typesetting behaviors in Maple for which I have found workarounds.  In the case at hand, it is important for users to know that non-evaluation marks can cause problems in a way that it is not obvious that they are the cause and that evaln( ) might get around the problem, with redoing the work I have done in tracking down the cause and workaround. Maybe others have already found workarounds that I can learn about from this forum, and they may find more in the future.

I have discovered one aspect of the code in my problem execution group that seems to be causing  the problem. The odd thing is that on many worksheets it works fine and on some worksheets it causes a problem.

My code had been unassigning indexed variables (not tables or arrays, etc.) with:

x_G,i := 'x_G,i';

and documenting calculated values by:

'x_G,i' = x_G,i ;

Replacing all the 'x_G,i' by evaln(x_G,i)  reduces the close to half a minute parsing time to about a second.

Thus, for the moment, evaln( ) seems safer than the unevaluation marks for indexed variables, although the later seem to work very, very often. Some hidden aspect of how the code is stored, which depends on exactly how, in what order, with what corrections, etc. the code is input, seems to sometimes interfer with the non-evaluation mark form and cause huge "parsing' times.

Another curious aspect of this problem:

I divided my problem execution group (with no commments) into approximately three equal parts. The parsing time when the parts were in one group is about 22 sec. However, the parsing times when each part is in its own group are 0.4, 0.5, and 2.8 sec. Wow. Dividing the code into smaller groups reduces the parsing time by over 80%!  (Note that smaller here means moving from 30 lines in total to 10 lines each. We are NOT talking about massive execution groups.) Putting the 2nd and 3rd groups together again brought the parsing time up to 22 sec. Although the 3rd group seems like it might be the most problematic, it comes nowhere close to explaining the 22 sec. But there must be some connection between the 2nd and 3rd group that gives Maple real parsing trouble. It is this "hidden" connection that parsing creates across separated statements that makes this phenomenon so difficult to fix.

The method suggested by Joe Riel worked fine with versions before Maple 12. It seems to have stopped working in Maple 12. I found it enormously useful. Maybe this is an oversight in Maple 12. Perhaps they can put out a patch for it. I don't see why they would decide to cut out this feature.

The method suggested by Joe Riel worked fine with versions before Maple 12. It seems to have stopped working in Maple 12. I found it enormously useful. Maybe this is an oversight in Maple 12. Perhaps they can put out a patch for it. I don't see why they would decide to cut out this feature.

The method suggested by Joe Riel worked fine with versions before Maple 12. It seems to have stopped working in Maple 12. I found it enormously useful. Maybe this is an oversight in Maple 12. Perhaps they can put out a patch for it. I don't see why they would decide to cut out this feature.

The method suggested by Joe Riel worked fine with versions before Maple 12. It seems to have stopped working in Maple 12. I found it enormously useful. Maybe this is an oversight in Maple 12. Perhaps they can put out a patch for it. I don't see why they would decide to cut out this feature.

When first entering a post, my Post box always comes up pushed to the right and up, partially covering "|Help" on the upper left and partially covered by your Maple Application Center logo on the upper right. When editing a post, the right quarter, at least, of the Post box is covered by the menu frame on the rhs of the page. All this and I am not using HTML and I don't use any angle brackets! Something is clearly more wrong than users just not "escaping angle brackets". Hope you can fix this. It very annoying.

Just to try to state my view of the major symbolic matrix "goal": My goal is to find a way which is as simple and straightforward as possible to give the unknown elements of a Matrix a stable (root) name, that is a name that can be used throughout a set of computations, and which can be used to assign values to this name using matrix methods. Acer's method certainly seems to me the closest to this so far. I don't know yet whether it will stand up under usage in more complicated calculations, but so far it looks good. I say closest because the ideal would be to just be able to use "symbol" as an option by itself to make the root name for the unknown elements the name of the matrix itself, which is what happens automatically in linalg. Alex Smith's method seems to lack several of my desired attributes. (1) His method puts a proc frontend on all the matrices, lacking simplicity. (2) His method gives the root name "a" to the elements of A, rather than "A", as Acer's method would. (3) The method requires a quit non-matrix (element by element) method to assign values to the unknown elements. Objection (2) can probably be fixed, but (1) and (3) seem essential to the method.

Neat! Using double non-evaluation marks with a functional definition of the matrix elements seems to be just the trick that is needed to pass on the truly desired symbol for the undefined elements. After seeing your code, I tried single non-evaluation marks just to see, but that still gave the recursive definition error. I also tried just symbol=''A_LA'', but that ended up in a horrible misinterpretation with indexed matrices. I am going to start using this trick to see how it works out in more general computations. Thanks.

Whoa! Do you see what you did? The goal is not to get C_LA to have a(i,j)'s in it. The goal is to have the original symbol used for the unspecified elements of A_LA to show up in C_LA! You have changed that symbol to "aa", but "a" is now what shows up in C_LA. So the goal hasn't been achieved. Doing what you have done would lead to a long sequence of new symbols for the unspecified elements of A_LA as the computations get more involved, build on each other, and come around to meet each other again. Actually, one would end up with a whole network of symbols which would be very difficult and surely annoying to keep track of.

The Jordan form of a matrix with floating point numbers is almost always, generically, going to be diagonal. To get a non-diagonal Jordan form one needs a well-constructed matrix with rational number entries so that maple does the compution exactly. (Almost) any slight perturbation of a matrix with a non-diagonal Jordan form will have a diagonal Jordan form. Thus in general one should do an eigenvalue/eigenvector problem to get the Jordan form. One should only sensibly try for a non-diagonal Jordan form when one is dealing with rational commponents. The matrix [[1,1],[0,1]] is one of those; [[1,1],[0,1.001]] is not. Of course, some very special non-rational matrices like [[1,pi],[0,1]] do have non-diagonal Jordan forms.

Since previous poster was not familier with Economics, and you did not explain the context, he thought you wanted to plot Income as a function of X and Y. Of course, what you want is Y as a function of X with Income, P1, and P2 given numerical values, in other words a budget constraint. Essentially what you have is a very simple implicit function. You can do this with the following simple code where you replace the ?'s with numbers: Income:= ?; P1:=?; P2:= ?; plot((Income-P1*X)/P2,X=0..Income/P1);

The general eigenvector problem K.x=lambda.M.x gives the same set of eigen values and vectors as the simple eigenvalue problem M^(-1).K.x=lambda.x . However, since M^(-1).K is not symmetric, the eigenvectors are not orthogonal.