This also seems to work (and provides some functional `ssystem` as a bonus),

restart:

unprotect(ssystem):
ssystem:=eval(`dsolve/numeric/ssystem`):
protect(ssystem):

cp:=Compiler:-Compile( proc(x) sin(x); end proc ):

cp(2.1);

                         0.863209366648873710

Who knew!

acer

@Joe Riel Thanks for the comment, Joe. I wanted an A such that failure would happen at roughly the half-way mark (walking through). Some schemes' performance advantage won't demonstrate "properly" if the first failure occurs very late through the walk, and might be over-emphasized if very early. And I wanted the same number of failures, while running the three methods in distinct sessions. It sure can be tough to characterize advantage accurately for these kinds of tasks -- in part because some aspect of  a user's particular task might make early hits common,.. or rare.

Is there something much better than ormap(evalb,`<`~(A,B))? I can't help but feel that a function call is being done at least once more than necessary for each element (of both).

@Joe Riel Thanks for the comment, Joe. I wanted an A such that failure would happen at roughly the half-way mark (walking through). Some schemes' performance advantage won't demonstrate "properly" if the first failure occurs very late through the walk, and might be over-emphasized if very early. And I wanted the same number of failures, while running the three methods in distinct sessions. It sure can be tough to characterize advantage accurately for these kinds of tasks -- in part because some aspect of  a user's particular task might make early hits common,.. or rare.

Is there something much better than ormap(evalb,`<`~(A,B))? I can't help but feel that a function call is being done at least once more than necessary for each element (of both).

@jscottelder Is it possible for you to upload some example worksheet that demonstrates the issues?

Have you tried the Classic GUI (using 32bit Maple on MS-Windows, say)?

This link may or may not be of interest. (Common subexpression labelling can sometimes greatly reduce very long output, and can also work well in Classic as well as CLI. But it's not yet clear whether you have very long output expressions or just very many output expressions.)

If you are finished with viewing of the outputs of previous calculations, then in the Standard GUI you might get some relief from Edit-Remove Output from the main menubar. This does not undo computations or clear previous assignments to variable names.

@jscottelder Is it possible for you to upload some example worksheet that demonstrates the issues?

Have you tried the Classic GUI (using 32bit Maple on MS-Windows, say)?

This link may or may not be of interest. (Common subexpression labelling can sometimes greatly reduce very long output, and can also work well in Classic as well as CLI. But it's not yet clear whether you have very long output expressions or just very many output expressions.)

If you are finished with viewing of the outputs of previous calculations, then in the Standard GUI you might get some relief from Edit-Remove Output from the main menubar. This does not undo computations or clear previous assignments to variable names.

@Preben Alsholm Right, for starting from T=755 the eval(ans,1) can reduce the large timing by 1/2. And whhen starting from T=800 using the previous iteration's inital point can reduce the smaller total timing by about 1/4.

@Preben Alsholm Right, for starting from T=755 the eval(ans,1) can reduce the large timing by 1/2. And whhen starting from T=800 using the previous iteration's inital point can reduce the smaller total timing by about 1/4.

@Christopher2222 I suspect that in your vision of animation-on-the-fly you may be a little stuck, conceptually, in the old paradigm of animation. Yes, it is desirable to have the animated display start right away, but there is more to it than that.

If you don't need to export the "animation", then you don't likely need to record and save all the frames (ie. all together). In terms of frame-on-demand animation, there could be no frames stored at all.

There are other advantages to this, besides memory savings.

Consider an animation with 2 parameters which vary in time. And I don't just mean that they vary on different time scales, or as different functions of time ("time" being the master concept of progression, ie. timestamp=frame number). Rather, I mean that each could stay as the parameter-of-animation, while all or some of the other(s) could become active but nonanimating.

I don't remember if I ever shared this kind of worksheet here. Disregard the aesthetic look-and-feel, and consider the prototype functionality. While the animation is running either or both of the parameter sliders can progress in time. But with a simple checkbox click either of them could be decoupled from time, and made nonanimated. But a nonanimated parameter could still be active(!). By this I mean that a nonanimating slider could still be moved manually, and the updated parameter value get used, even while the rest of the animation continues.

sinusanimation2.mw

In the attached worksheet, press the Play button to begin. While it animates the "animate" checkboxes beside either slider can be toggled off and on. But even while a slider's "animate" checkbox is toggled off that slider can still be moved, manually, and the ongoing frames of the animation will use that slider's new values.

This is a simple example, of course. More involved examples could have more parameters. And there are different models of behaviour for what happens when a nonanimating slider gets toggled to "animate": it could catch up to the others, or it could proceed from its current state at the same "rate" as the others, or it could proceed from its current state and attain its final value in sync with the other sliders, etc, etc.

In this paradigm of frame-on-demand, in GUI Components, it's not necessarily desirable to record all the frames if you don't want to export. Saving all frames -- if they are not needed -- is just a big waste of memory. (Of course, a mechanism to record the frames would be easy to program into this.)

(If anyone is interested, I started thinking seriously about this topic after this Post. But I forget when I first started. It may have been quite some years ago.)

acer

One can avoid unnecessary re-evaluation (re-computation) by fsolve in the cases in the loop where it has returned unevaluated by doing the type-check as type(eval(ans,1),...). Or the whole loop might be done in a procedure, with `ans` declared locally so that it is evaluated 1-level by default.

In the given worksheet,. where it fails for T=755 to T=800, the time spent by fsolve searching in vain for a solution can be cut in half. On my machine, the total time in the loop lowers from about 105sec down to about 55sec.

Let's suppose now that we knew in advance not to start T as low as 755. This worksheet seems to be another example where using the previous iteration's solution (for x1 and x2) as a starting point for fsolve in the current iteration can speed things up. Starting from T=800, then this crude but effective technique can drop the total time in the loop from 4.8sec down to 3.2sec on my machine.

anotherfsolve.mw

(It's curious, that this is about the third time a a week or so that this kind of benefit to fsolve in a loop has come up. I would expect that the re-use of the previous result as initial guess to the next iteration is not limited to fsolve; it might well help a little with DirectSearch or another searching rootfinder.)

acer

One can avoid unnecessary re-evaluation (re-computation) by fsolve in the cases in the loop where it has returned unevaluated by doing the type-check as type(eval(ans,1),...). Or the whole loop might be done in a procedure, with `ans` declared locally so that it is evaluated 1-level by default.

In the given worksheet,. where it fails for T=755 to T=800, the time spent by fsolve searching in vain for a solution can be cut in half. On my machine, the total time in the loop lowers from about 105sec down to about 55sec.

Let's suppose now that we knew in advance not to start T as low as 755. This worksheet seems to be another example where using the previous iteration's solution (for x1 and x2) as a starting point for fsolve in the current iteration can speed things up. Starting from T=800, then this crude but effective technique can drop the total time in the loop from 4.8sec down to 3.2sec on my machine.

anotherfsolve.mw

(It's curious, that this is about the third time a a week or so that this kind of benefit to fsolve in a loop has come up. I would expect that the re-use of the previous result as initial guess to the next iteration is not limited to fsolve; it might well help a little with DirectSearch or another searching rootfinder.)

acer

I've previously expressed some thoughts on the general topic of your point a) about memory performance.

acer

You write that the red is less easy to read and takes longer to type down.

Does this mean that by "red" you mean 1D plaintext Maple Notation input, and by "black" you mean 2D typeset math input?

acer

The FileTools:-Compressed subpackage is set up to use gzread from zlib, I think, and so works with gzip'd files.

You might possibly be able to set up a define_external to an inflate function that would work with a pkzip'd file. You could look at the zlib manual, and maybe get hints from,

kernelopts(opaquemodules=false):
print(FileTools:-Compressed:-ModuleLoad);
print(FileTools:-Compressed:-defun);

acer

@Christopher2222 It's not that the first argument to Remove evaluates (by itself) to true. It's that in Maple 12 it has to be an appliable thing (eg. procedure) which can be applied in turn to each character of string `a` and return true or false for each.

@Christopher2222 It's not that the first argument to Remove evaluates (by itself) to true. It's that in Maple 12 it has to be an appliable thing (eg. procedure) which can be applied in turn to each character of string `a` and return true or false for each.