@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

@Carl Love For a starting value of 2 the other isolating formula seems needed with the PointFixe above. Ie, passing exp(x)-x-5 wouldn't suffice even the procedure were modified to "add x to g".

How about uploading a worksheet with the full details?  It sounds like your rotating object might be 3D, but it's not clear.

The Explore command can do that with an display of an Array of two plots. But depending on the details there may be nice alternatives. For example if the frames are individually slow to compute then pair of plots-animate style animations could still be advanced (essentially) in sync by advancing them together in two separate Plot Components.

If the rotating object is also 2D the even a dual-axis plot might suffice. If the rotating object is 3D and you don't need the see it rotate with respect to the axes, etc, the you may get better performance instead by changing the "point of view" (fly around it), which affect which method is easiest while also practical.

acer

@Preben Alsholm I don't know what causes this recurring and long-standing problem.

Ok, so the above is the 25 minute version, upon waking at 5:30am. (10 mins of that being mental design while the water boiled...)

My improvement wishlist grows: 1) passing the inbound color through ColorTools, to allow several more input formats, 2) careful handling of names which already have their own print-slash proc (saving it aside, forced clobber, proper reinstatement), 3) colouring braces, and 4) distinct colouring for function application of specific arguments (eg, F(x) versus F(t) ).

@John Fredsted Wouldn't you need the module to have 'option package' in order for it to work using 'with' ?

Perhaps the Programming Manual is a good place to start, as it contains an example of doing this.

The relative performance with increased problem "size" here can depend on on which gets larger: the number of items in the inner lists, or the number of inner lists, or both. I deliberately repeat one of the computations in each run below, to test whether the order of execution is affecting it's timing.

For example,

restart;
A := [seq([seq(i*j,j=1..1000000)],i=1..3)]:

ans1 := CodeTools:-Usage( op(map(op~,[1,2],A)) ):
memory used=1.70KiB, alloc change=0 bytes, cpu time=7.00ms, real time=7.00ms, gc time=0ns
ans2 := CodeTools:-Usage( op([1..2],ListTools:-Transpose(A)) ):
memory used=53.42MiB, alloc change=371.64MiB, cpu time=2.90s, real time=1.28s, gc time=2.48s
ans3 := CodeTools:-Usage( op(map(op~,[1,2],A)) ):
memory used=1.73KiB, alloc change=0 bytes, cpu time=8.00ms, real time=7.00ms, gc time=0ns

ans1-ans2, ans1-ans3;
                                    0, 0

restart;
A := [seq([seq(i*j,j=1..1700)],i=1..1700)]:

ans1 := CodeTools:-Usage( op(map(op~,[1,2],A)) ):
memory used=187.17KiB, alloc change=32.00KiB, cpu time=8.00ms, real time=8.00ms, gc time=0ns
ans2 := CodeTools:-Usage( op([1..2],ListTools:-Transpose(A)) ):
memory used=22.11MiB, alloc change=260.31MiB, cpu time=56.00ms, real time=56.00ms, gc time=20.00ms
ans3 := CodeTools:-Usage( op(map(op~,[1,2],A)) ):
memory used=187.34KiB, alloc change=0 bytes, cpu time=8.00ms, real time=7.00ms, gc time=0ns

ans1-ans2, ans1-ans3;
                                    0, 0

restart;
A := [seq([seq(i*j,j=1..3)],i=1..1000000)]:
ans1 := CodeTools:-Usage( op(map(op~,[1,2],A)) ):
memory used=106.82MiB, alloc change=47.27MiB, cpu time=2.08s, real time=919.00ms, gc time=1.58s
ans2 := CodeTools:-Usage( op([1..2],ListTools:-Transpose(A)) ):
memory used=22.89MiB, alloc change=22.90MiB, cpu time=40.00ms, real time=42.00ms, gc time=0ns
ans3 := CodeTools:-Usage( op(map(op~,[1,2],A)) ):
memory used=106.82MiB, alloc change=-7.63MiB, cpu time=1.72s, real time=815.00ms, gc time=1.23s

ans1-ans2, ans1-ans3;
                                    0, 0