@Alejandro Jakubi 

Well, maybe one answer would be to use the Application center more often. I do not know the old Share Library so I cannot compare, but at least in the Application Center I can find things. Since you mentioned Fourier series: there is apparently a package by Moiseev that includes Fourier series (amongst others), and there is even a sheet by Lopez that explains some aspects of the use of the package. (I realize you used this as an example, and this may not do what you need). Ongoing maintenance is a problem even the large open source projects don't get right: lots of older packages linger and get stale. If the creator loses interest it's pretty much just tough luck.

I like the idea of something like Sage; but at this point I have invested quite a bit in Maple, it does what I need (mostly), and I have little inclination to try another one. Maple has a lot of programming constructs I really like and use (modules, records, all the semi-oop stuff) that I don't want to let go of. I highly doubt Sage has anywhere near the polish Maple has. (And yes, in daily work just trying to get something done efficiently, and trying to get e.g. publication-quality graphs done, polish counts. Even Maple has a ways to go in that department.)

(Note to self: I should consider packaging one of my programs for submittal to the Application center. It may have some appeal for others, and since its routines by now have been validated one may let it lose on the public.)

Cheers,

Mac Dude.

@Markiyan Hirnyk 

Markiyan, this was unfortunately (as far as examples are concerned) about a year ago so I do not have the broken version around anymore. What I do remember is that a part of the issue was that I had large Arrays declared as "datatype=anything". This means that Maple was not forced to numerically evaluate an expression (unless you use evalf), and at least in my case dutifully kept working in the symbolic domain. So, once I found that out I littered my code with evalf() statements until I smartened up to this datatype issue, after whch things became much better.

As far as timing was concerned, I just ran scenarios with different no. of iterations & wrote the times down. Since I allocated the arrays based on the max. number of iterations there was a component in the time per iteration that depended on the max. # of iterations.

This was, incidentally, a code converted from Mma, which was part of the issue. Mma's structure is sufficiently different from Maple's that the conversion was a lot more involved than expected.

This is probably not quite what you wanted, but I am not able to post a useful example.

Mac Dude.

@Markiyan Hirnyk 

Hi, let me just add (fbo the OP) that I have found it sometimes helpful to analyse the time used vs # of iterations. If you know the behaviour of the algorithm, a different behaviour (e.g. a higher-order dependence) points to flaws in the implementation. I once diagnosed a problem with a numerical calculation in this way: a simple calculation that should have used the same time/step no matter what, actually showed exponential use of time. It turns out that Maple was doing things symbolically rather than numerically, thus creating enormous expressions until it choked to death. The exponential time use clued me in (and the memory consumption pointed in the same direction). And there are of course endless possibilities to get trapped in array-indexing issues, some of which Maple "helpfully solves" by continuously allocating new memory for arrays...

M.D.

@Alejandro Jakubi

I fully agree re. the difficulties of single-author repo's. They come and go as the life of the author evolves and their priorities shift. Keeping up is also a very time-consuming job. Those that have the long enough view to keep it up beyond their own active involvement typically go commercial.

But what is the need we really have? One class revolves around sharing what one does anyway, assuming it may be helpful to others. This can be a very useful thing, and I would argue that the Application Center can serve a purpose here. After all, it is somewhat organized andd I can actually narrow down the field enough so I can scroll through a finite list of entries, which have a description attached to them etc.

A totally different thing would be actual developments with the aim of extending the Maple system itself. This is an area I am not qualified to talk about, but it is much more complex, and do we as a community have the critical mass to do pull such an effort off and sustain it? Is there even a "market" for this?

$0.02 $0.01

M.D.

@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.