I ran into a problem with the physics package that I subsequently solved. But I am wondering whether this would be a candidate for an SCR and/or be considered a bug.

The calculation I am trying is actually (so far) very simple.

I define a Hamiltonian H:

H := sqrt(p_^2*c^2+m^2*c^4); # note the square of vector p_

p_:=p1*_i+p2*_j+p3*_k;

H;

So far so good. Now I want to take the differentials of H against the components of p:

diff(H,p1) assuming c::real;

Hmm... I am not sure why the p2 and p3 still show up; but then, the product between the unit vectors should be 0 for different ones and one for equal unit vectors so maybe this is ok.

But H behaves weird: I can simplify it:

but if I try to do anything with it, it barfs:

dH+0;

Error, (in Physics:-Vectors:-+) invalid operation * between vectors _i and _j

As it turns out the issue is the square of the vector p_. Maple (or rather, Physics) does not recognize that it needs to expand p_^2 as p_.p_ and seems to treat is like p_*p_.

I would like Edgardo---& others more experienced with the Physics package than I am---to look at this. I do not understand the Physics package well enough to judge whether overloading the exponentiation operator to make this work is the right thing.

The example works once I replace p_^2 by p_.p_. But the ^2 notation is fairly standard usage so it feels slightly awkward.

Thanks,

Mac Dude.

Derivation_of_H.mw

I know this has been dealt with before here, but I have forgotten the proper way to trim a small imaginary round-off from a result. I cannot locate the proper answer in MaplePrimes; and the Mapledocs are either quiet about it or it is hidden in a difficult-to-find place.

What I want is to ignore ny imaginary part below a certain threshold. Ideally, it takes the threshold in relation to the real part but I am not particular about this.

Thanks in advance,

Mac Dude

Here is one I have been struggling with lately:

I have a relatively large module with many procedures inside (plus some other data structures). In one of the procedures, it turns out that it would be convenient to have a subprocedure defined inside to both shorten the code by avoiding duplication as well as make it more error proof (once the subprocedure is debugged it'll be correct everywhere it is used). Here is the skeleton

Lattice:=module() option package;
export Track;   ...
   Track:=proc(arguments) uses LinearAlgebra;
   local trackElement;
      ...

      for ... do
         result:=trackElement(parms); # This does not work
         ...
      end do

      trackElement:=proc(arguments) uses LinearAlgebra;
         ...
      end proc; # trackElement

   end proc; # Track;

end module; # Lattice

The problem I have is that procedure trackElement is not recognized as i found out running the code in the debugger. I can make it work by taking trackElement out of Track and make it local to the Lattice module. While functionally this works (and it is how I have it now programmed), I do  not like it as every proc in the Lattice module can see trackElement. That should not be so, I want it local to procedure Track, which is where it belongs.

I really thought I could define procedures within procedures. Am I wrong? Or is there something else ging on?

TIA,

Mac Dude

PS: The whole module is more than 100 kB of Maple code sitting in a library. I refrain from uploading it here as it would be non-trivial to get going even for a simple test case.

I am working on a problem involving sums in Maple and I find Maple's facilities lacking.

Specifically; I want to convert the square of a sum into a sum of squares plus the cross terms (which is a subtask of a larger problem). So I start with

sum(E[n],n=1..N)^2;

and immediately get stuck as I do not find any command that does anything with it. The expansion of this is known and easy to derive:

sum(E[n],n=1..N)^2 = sum(E[n]^2,n=1..N) + 2*sum(sum(E[m]*E[n],m=1..n-1),n=1..N);

Maple knows nothing about this relation. I have checked out packages like SumTools but have not found anything useful for this purpose. Quite some time ago I have had difficulty distributing a sum over the elements of its expression; this was answered here and involved a custom function.

Does a package exist that has these kinds of conversions, or do I need to roll my own? It seems a general enough issue that I would expect functions for this to exist.

TIA,

Mac Dude

I ran into a problem mentioned here before: With lots of code in one execution group, the standard GUI editor becomes very slow at least in older versions of Maple (I have reason to believe that this is mostly fixed in Maple 17 and, presumably, newer). With one of my packages this has become enough of a problem to force me to deal with it (and Modules and Packages have to be all in one execution group). I have some machines that cannot go beyond Maple 15 so I keep my stuff compatible with it (so far not a big sacrifice).

The fix is rather easy: In the GUI, export the code as "Maple Input" which creates a file with extension .mpl. Then, in the GUI have a small file that uses "read" to read-in and execute the code (of the module). In my case, I have the necessary LibTools statement to save as a .mla right after the package code ends so, bingo, I have just updated the package. I edit the .mpl file in Emacs.

So I installed Joe Riel's Emacs mode maplev-mode.el. This works rather well. However, it took not long for it to show its age: it does not recognize the multi-line comments (*...*). This is kind-of bad as this forces me to not use quotes in the comments since they mess-up the keyword highlighting esp. when using single quotes as in "I'll" and so on. Likewise, maplev-indent-buffer messes up the whole buffer as it interprets the multiline comments as code.

So my question is: is someone still working on this and using it?? I guess I can work around some of these things, but it would be nice if this worked.

Incidentally, my version of maplev-mode.el seems to be dated June 2005.

I know Joe is here on occasion, maybe he can chime in. It is not absolutely fatal; I could forgo using maplev, but if I am forced to go this route of readin in the package; using maplev-mode at least gives me something in return. Unfortunately my elisp skills are not quite up to fixing this myself; at least not in a reasonable time.

If it is relevant: I use Emacs 22.1 on Mac OS X. Yes, I could upgrade to at least Emace 23.4, if that were the issue.

Thanks in advance,

Mac Dude