Would you care to give us your defn of Lerror?

You'll probably want to change `sum` to `add`, and `int` to `Int` (and throw in a wrapping calls to `evalf` inside `c` and `Fourierf`. And it seems like you'll want `c` to be a proc...end proc rather than just an operator, so that you can give it option remember and avoid needless recomputation.

acer

@Kitonum You're welcome.

I considered leaving the Sign(P) call out of Sign(P)*IntegralPart(P), while also leaving IntegralPart=0 out of the conditional, which would be simpler. I left it the way it is because it reminds me of why the bug can occur.

Of course, even if one lacked the newer NumberTheory routine the individual strings could still be computed (with some additonal code) and stuck together in the manner shown using Typesetting.

@Preben Alsholm I would simply delete this as a Duplicate, except that it now has a response.

Have you considered making the default File->New sheet to be Worksheet instead of Document, and the default input mode to be 1D Maple Notation instead of 2D Math?

acer

There is far too much wasted space. For example, the margins between the left and right edges and any text content (especially in Replies/Answerws). The switch to what appears to be double-spacing is another example. Dead space at the borders of the rectangular image boxes is another example. This problem is severe.

Having the author's member-icon and details appear inside the body of the reply (instead of in the title-box) adds to the wasted space problem.

The Green-Arrow upload doesn't work at all in my Linux Chrome. (I tried inlining a sheet, or just link insertion, with and without Cancel, etc.)

I have to struggle to read the text on the grey background boxes.

On my android phone the whole experience makes the site unusable and unreadable, even if I turn it sideways. The display does not resize properyly and content bleeds offscreen to the right. With my phone upright I often see paragraphs of text formatted in with one word per line (yes, sentences displayed in a huge column one word wide).

acer

@artfin Could you say how much faster the full 50-frame run was, using what I posted above vs the original, for you?

Do you have a rough idea of how fast (relatively speaking) you'd want it?

If you want it very fast then I suggest devising a single procedure that computes the results needed for a whole frame, the numerical computations of which could all be done under evalhf. 

That should be the only proc which takes argument `t`. Better still cut out almost all the function calls and use local variables for the intermediate results.

@Mac Dude  Thanks to Mac Dude and vv.  Good ideas.

@emendes I realize that you are after a Maple 14 solution. But just for fun I could also mention that in Maple 2016 the DocumentTools:-Tabulate command provides yet another (but very easy and flexible) way to get progress information displayed while a procedure is executing.

It's not as lightweight as a pre-inserted Slider, but it allows a moderate assortment of things to be shown, including typeset math and plots as well as just strings of text.

tabulateprogress.mw

@emendes Alas, I remembered things wrongly. It was only in Maple 17 that the basic mechanisms for programmatically inserting embedded components arrived.

So in Maple 14 one would have to manually insert the components from the Embedded Components palette into each worksheet that does this. It works, but it's not so convenient if you want to do it in lots of sheets, easily. Here's an example, anyway, with components manually inserted from the side palette.)

prog14.mw

And if you forget to insert the components, or their identities don't match how SetProperty tries to call them, then the GUI pops up potentially many error boxes. And those raised errors may not be catchable. Too many and a hard kill of the GUI might be needed.

It'd likely be possible to do it fully programmatically in Maple 14 using Maplets instead of Embedded Components. Unfortunately I don't have the time for implementing that, sorry.

This is at least the third thread to which you've posted most of the code. Please don't repost it to yet more threads until you have a truly new issue to address (and not yet another efficiency rehash).

I haven't had time to give it more than a cursory look yet (sorry, but its thanksgiving weekend here). But it is very obvious that the code has a great deal of inefficiency, due to multiple causes. The tensor matrix symmetric yet computes entries twice. The operator passed to the integration (that Preben  answered last night) computes all three dimension's values (of the integrand) each time any of the three is requested. And these problems have cumulative effects.

Its possible that the huge overuse of operators causes more problems. And the there are nested accuracy concerns... is fdiff really necessary? 

I have a strong suspicion the sheet should be almost entirely rewritten. There's like one of more factors of ten speedup to be had... possibly several.

Even the way that the animation frames were made looked suspicious in places... is some of the frame data being recomputed each time?!

But don't post the essentially same material yet again, as I'll just delete-as-duplicate.

@emendes The attached sheet shows how you can save the module to a Library, so that you can simply re-use it without having to recreate/re-execute the module definition each time.

saveprogslider.mw

I've set it up so that it'd be available in other Maple 2016 sessions, but not those of other versions. You might find this useful for other, similar archive tasks.

The module definition now also has `option package`, so that it's package-exports can be utilized inside a procedure by their short names, after a uses ProgressSlider; statement. Or they could be used by their short names at the top level, outside a procedure, after a with(ProgressSlider); statement.

I'll have a look what'll it'll take to work in Maple 14. One big, ugly string substitution might just suffice....

@artfin It doesn't matter how the animations are created, for using them that way.

For example you could assign the two results from your calls to AnimationModel and Eigenvalues_animation to a pair of names. And then you could use those as the third arguments XYZ in the two calls like SetProperty(..., value, XYZ ) which puts the two animations into the two Plot Components.

@Ronan Trying to save to a .mla in the Maple installation lib folder is a Bad Idea.

Trying to do it with savelib is worse still.

@DSkoog The point seems to be more like: why cannot an equation like  P3=3/7*Unit(W) be handled by the right-click units-formatting? There is only one instance of a Unit in it, so the intention seems unambiguous.

The same might apply for an expression such as x+y*Unit(W)+z. Sure, it is not of type with_unit , but it would be more friendly if the formatting were applied, say, just the single indet of type specfunc(Units:-Unit).

Moreover, if the expression cannot be handled by units-formatting then ideally the context-menu item should not appear at all.

Here is an example of using an automatically inserted/deleted Slider, that can get updated inside a running loop.

prog.mw

You could always do the insertion of a Slider manually. By that I mean: insert a Slider from the side palette, then put a line in the loop which calls DocumentTools:-SetProperty to update the Slider bar. The drawbacks of that are several: the position of the Slider in the Worksheet is fixed and doesn't always match your current cursor position/view, you have to do the manual insertion each time, you have to delete it manually each time, etc. (Having to switch repeatedly back and forth from mouse to keyboard is irritating, IMO. And having to repeat all the manual steps the second and third and fourth time you want a progress bar can get a bit much...)

Anyway, if you like how the attachmed Workheeet behaves then I'm somewhat sure I could make it function similarly in Maple 14. Of course in Maple 14 you could also just set up a Slider by inserting it manually, each time you want one.

acer