@Alejandro Jakubi 

Maybe we misunderstood each other. My comment simply was to explain why I pasted images (which I was well aware of). So far I sort-of avoided uploading sheets, but maybe I should change my attitude here. I do find it important, though, to post the questions in clear text; I myself will not look at question that, basically, says: "Look at the uploaded Maple sheet and fix it." In many cases a questioner just needs some hint and not a fully-worked example. (In fact, for the many students posting their homework assignments that is exactly what we should do, to enhance the learning experience. But I think I am going OT here...).

As far as usage is concerned: sufficiently general and tested functions, rules, etc. go into one of my Packages that I load at the beginning of a worksheet. I certainly do not constantly retype general stuff. On the other hand, I also take some care not to pollute my namespace too much. This all works very well in Maple.

As for a general repository of Maple functions, procedure, rules etc. this would be an extremely valuable service to the community, esp. since MaplePrimes is not easily searched. Some people have posted their own work (e.g. Robert Israel at UBC). Other---shareware---developers maintain their own areas that are in essence curated collections of contributions (e.g. Mark Widholm for MathPad). I guess the Maple applications collection is meant to be something like that and I have gotten helpful routines from that area. Could we make more use of it (both in posting as well as using it)? Could an area be added to it for routines and stuff that is not an actual application??

At any rate, your rule (with a small modification to allow a factor before and after the sum) works very nicely for me.

Thanks,

M.D.

@Alejandro Jakubi 

You are right that I pasted images (Maple output); I'll be fine typing your rule in & making it work. I just needed a pointer in the right direction, which you gave me. And no, I am not trying to get my homework done by a MaplePrimes fellow, these expressions are actually part of a much larger teaching project. In this case I need a way to do in Maple what is somewhat obvious, and do it in a way that does not obfuscate what is going on. I do sometimes struggle with getting rules to work, but that is part of the learning experience of the teacher.

So, many thanks,

M.D.

@ecterrab

@work I have newer machines, running OS X 10.6.8 so I can and do run Maple 17. And in fact, very little of what I have been doing in Maple requires changes between the versions (15-16-17), and many I can program around. The Physics package may be a different case as it is fairly dynamic and appears to be well maintained and fequently updated. What I was actually thinking was whether I could e.g. get a newer version of Physics running on Maple 15 (probably not...) or add features I would like (like the cyl. coordinates with a diffferent axis) in a clean and consistent way. It is probably too time consuming as e.g. I don't even know off-hand how to get from the .mla to an editable source although I seem to recall that there is a way.

But keeping up with the ever faster spinning upgrade caroussel is neither viable for me, nor particularly attractive. Landfills are already growing too fast. And the k$ I'd rather spend on the nicer things in life like traveling, or on keeping the house in shape.

Anyway, thanks for the package in the first place; it is one of the nicer ones even if I have barely scratched its surface.

M.D.

@ecterrab Ok, thanks for clarifying this.

M.D.

@Axel Vogt and @Preben: Thanks much, both of your solutions work.

Part of the trick was to specify sigma >0; although I do prefer Preben's solution using the assignment with eval (to make an expr. out of the function). It is hard to see why that is essential (that scheme works even if I don't set phi0 to 0), but...

M.D.

@ecterrab Thanks, I see what you mean. I'll give it a shot. And thanks for the PDEtools:-Solve hint; I wasn't aware of that.

M.D.

@rashmi Well, you do have imaginary arguments to the Legendre functions, so getting complex results is not surprising per se. I tried to run your formula for lambda=1 putting some (arbitrary) numbers in for M and Q (and varying tau). It seems that (for C1=1 and C2=1) the results are dominated by the term multiplied by C1. Also, the imaginary and the real terms are comparable so you do not seem to be looking at round-off here.

You do want to read the docs on the Legendre functions. It is stated that Maple treats the branch points different from the standard; maybe that is an issue for you. This can be changed; there is an example that seems to indicate that the same arguments can produce a complex solution in the default Maple evaluation but a real result if you change the branch-cut.

As far as picking C1 and C2, you should do what is right. Since the formula is the solution of a diff. equation, you need to find _C1 and _C2 from the initial or some boundary conditions. I.e., for tau=0 you'll have some value for eta that is determined by your problem. Likewise for diff(eta,tau). Put those in and solve for _C1 and _C2. With luck this will take care of the imaginaries (although I suspect it may only for tau=0).

You may be up to a more sinister issue, though. It seems to me that, for certain values of your parameters, you may be able to find a much simpler solution (e.g. something like a sine/cosine oscillatory term) than the one Maple finds for the general case. It may be helpful to restrict the d.e. before dsolve. Also, if you know the form of a solution you can put it in and see whether that solves the equation.

Beyond that I am not sure. Are you certain that your d.e. is correct? I did confirm that dsolve on the d.e. produces your formula for eta(tau). I did not try to find the initial values, though, as you really need to do that using other input you must have.

M.D.

@ebetwalsh What most likely happened is that either x or y had a previous assignment. It is a good habit to begin each worksheet with restart, and occasionally hit the "calculate whole worksheet" button (the !!! button) to execute the restart.

M.D.

@Carl Love Thanks. Got trapped by gamma again.

M.D.

@Timm What is it you are after? In your op you assign a+b to c. Thereby you are telling Maple explicitly to substitute a+b wherever it finds the name c. After that, c no longer shows up in your expressions. This is different than substitution, one of the possible ways shown by Kitonum, which acts only on the expression you use it on. Often substitution gives you better control over your computations as it allows you to substitute only when you want it.

A case like yours can also often be done like this:

subs(b=c-a,expr);

which replaces all occurrences of b with c-a and will replace a+b with c (possibly needs simplify). In this way you ensure you don't end up with a, b and c floating around in your expression, which you often don't want as they are no longer independent. Kitonum's example will only catch explicit a+b expressions but leave other a or b alone.

M.D.

@Carl Love Ok, this seems to work for the things I am trying to do (with frontend it even works for series).

Thanks again,

M.D.

@Joe Riel Hmm... so I guess the `δx` becomes a Maple symbol (or name)? I'll need to try this out & compare to Carl's solution. With the alias it becomes acceptable to use, although I guess I'd have to declare an alias for each one in case I have more than one delta something. I also need to determine whether these can be stacked (delta Delta x).

Thanks,

M.D.

@Carl Love Thanks again, I will try that modification.

As for the hidden thingy, my technique to detect these is (was so far) to select & copy the output & then paste it into a 1-d Input field. Usually that shows me fairly detailed what is actually there, but maybe it is not foolproof. lprint, here I come...

M.D.

@Carl Love It turns out i got to the bridge much sooner than expected:

The print/delta construct appears to actually change the nature of the expression. Specifically:

xpr:=delta(p);

xpr2:=(delta(p)/p);

Hey, where did the p go??? It turns out the print procedure makes this a product which then gets dutifully minimized. As far as I can tell, xpr2 really is just delta (and not some hidden thingy that just prints as delta).

:-(

M.D.

PS: The limit issue could be solved, albeit somewhat clumsily, with frontend. You are certainly correct in questioning the meaningfulness of this construct.

I know this post is 3 years old, but it is still relevant (to me :-).

Question: what about parentheses, as in a+b*(c+d)  ??

M.D.