Considering that I've seen that the plotting can be much faster, I think that there are two possible solutions. The first possible solution would be to introduce a new option to plot3d to use an improved plotting routine that might not be completely backwards compatible. I'm not exactly enamoured of this option, and think that introducing a new 3d plotting package (and probably 2d as well). Then, plot3d can be deprecated much like linalg.

I haven't switched over to Maple 11 yet, so I don't know if this is fixed, but, I'd like to see the integration of Heaviside functions fixed. I've written code for a course to help the students and it is based on derivatives and integrals of Heaviside functions and for some problems it gives incorrect solutions and consequently, plots. As a result, I've been contemplating defining my own functions to specify their integration rules and work around the bugs and convert to Heaviside only when evaluated. The other things I want are things that people at Maplesoft know I want and I've been told I won't get. First, better LaTeX support so the LaTeX output isn't so awful. Secondly, support for abstract linear algebra.

The main thing that I know is in Mathematica that isn't in Maple is the support for abstract linear algebra. In Mathematica, I can state that a and c are vectors and B is a matrix, and then peform operations on the product a^T.B.c such as take the derivative with respect to a. This is a common operation in finite element analysis and abstract linear algebra is also important in control systems, but using Maple for these fields is difficult at best.

That's odd. It certainly used to be there. I guess at some point the file was removed (not by me). Here's a link to the file (I haven't made any updates to it yet). Download 62_simpleLaTeX.mw

I took a glance at some of your webpages and I'm curious as to their utility and feasibility in the approximate solution of PDEs using a Ritz type approximation (such as finite elements). It certainly seems like they could be, the question would be how quickly they would converge to the solution and how difficult they would be to work with.

I'll give it a look over and see what I can make of it.

I'll give it a look over and see what I can make of it.

Thanks, that appears to work fine. That's part of my integration by parts system. Now, if I can just figure out the best way to handle the integration by parts for equations like: int(int(diff(theta(x,t),x,t)*diff(thetav(x,t),x,t),x=0..l),t=t1..t2); tmp := int(int(diff(theta(x,t),x,t)*diff(thetav(x,t),x,t),x=0..l),t=t1..t2); and tmp := int(int(diff(theta(x,t),x,x)*diff(thetav(x,t),x,x),x=0..l),t=t1..t2); tmp := int(int(diff(theta(x,t),x,x)*diff(thetav(x,t),x,x),x=0..l),t=t1..t2); I should be all set. Once I figure this out, I should have code that derives the variational equation and then integrates it to get the boundary conditions and the Euler-Lagrange equation, since the equations I'm deriving at the moment don't have simple forms for the E-L equation or boundary conditions.

Thanks, that appears to work fine. That's part of my integration by parts system. Now, if I can just figure out the best way to handle the integration by parts for equations like: int(int(diff(theta(x,t),x,t)*diff(thetav(x,t),x,t),x=0..l),t=t1..t2); tmp := int(int(diff(theta(x,t),x,t)*diff(thetav(x,t),x,t),x=0..l),t=t1..t2); and tmp := int(int(diff(theta(x,t),x,x)*diff(thetav(x,t),x,x),x=0..l),t=t1..t2); tmp := int(int(diff(theta(x,t),x,x)*diff(thetav(x,t),x,x),x=0..l),t=t1..t2); I should be all set. Once I figure this out, I should have code that derives the variational equation and then integrates it to get the boundary conditions and the Euler-Lagrange equation, since the equations I'm deriving at the moment don't have simple forms for the E-L equation or boundary conditions.

Thanks. I remember trying that originally and for some reason it didn't want to work. That's the way I thought it should work. It is much cleaner than breaking it up and reassembling it. I tried it and it works now.

Thanks for improvements to the procedure. I used the terminology dep_var because in the procedure you are trying to find terms that depend upon that variable and the other terms are independent of that variable. I always forget about applyop.

It looks as if Maple is returning eigenvalues as complex numbers since I is its symbol for imaginary numbers. That said, since it is multiplied by zero, the eigenvalues are actually strictly real. If you just use Re and map, you can get just the real parts of the vector by saying map(Re, a); where a is the Vector of eigenvalues. Cheers, Tim.

I'm very intrigued by this. Are you planning on releasing the software somehow?

Thanks for the info on the underscore. My problem is not getting out of fractions, it is often creating them, usually after cutting and pasting something. I cut and paste and expression and then want to divide by another. After pasting I hit the slash to divide and I get something else. At this point I usually end up retyping the pasted expression. I didn't have this problem using the old input mode.

I haven't noticed that there are compatibility problems, but I certainly have noticed a considerable slow down. Taking a Maple 9.5 worksheet and running it in Maple 10 (so making use of no new features) I noticed about a 25 percent slowdown and this is on a worksheet with little printed output so I'm not going to place the blame on new output routines. I know I'm not the only person who has noticed this. I like the new features, although I have problems with the 2D input mode all the time (usually with fractions and I wish I could figure out how to use underscores in variable names again). But I don't really want new features that are going to slow down the computational routines.