@Carl Love That's great, Carl. Vote up.

(I realize that you suspect that this is where I was going with my "on-the-fly" query.)

The GUI memory issue is unfortunate. I will submit a bug report.

There are a few more tricks possible that can reduce kernel/Library side memory use here, eg. Aliases instead of temporary rtables for data passed to the plotting commands, direct construction of final PLOT structures, etc. But I doubt any of that would help with a GUI memory clog on an embedded Plot Component.

It might be possible to get around said GUI memory clog (on a single Plot Component) by actually also replacing it for each frame. One way to do that is to call Tabulate in a loop. Another is to use the insertdirect option (of the embedding streamcall) in a loop. Both are of heavier weight as a single operation, but since the individual plots are simple perhaps the time-granularity might not suffer too much. I suspect that the GUI might not perform Java garbage collection while control is still in a kernel loop operation, but who knows...

@zenterix I had an idea that you might have parallelized some of it, using Grid.

I was wondering whether it might be feasible (fast enough) to compute each frame "on the fly" and display them (one at a time) in a Plot Component. This involves not storing them all, to save memory.

@zenterix What is the end-goal for this animation with thoussands or tems of thousands of frames? Are you hoping to export it to a massive .gif file, or just play it in Maple?

If the latter, then how long does it take to compute each frame if done sequentially?

@Rouben Rostamian  That's a fantastically huge amount of memory use, just to play an animation of an arrow moving around to 1000 points on a sphere.

Memory consumption several thousand times less would be much more reasonable.

@astroverted You can store the odeplot results as entries in an Array. Then you can plots:-display those all together.

DQ4_ac.mw

@Anthrazit 

The last name evaluation of  your x["a"] results in the name a, and whattype considers the "basic data type" of that to be a table.

The last name evaluation of your x["b"] results in the name x["b"] itself, and whattype considers the "basic data type" of that to be an indexed reference. Yes, x["b"] is an indexed name (which is also a kind of name), but apparently whattype considers the indexing aspect to be more "basic".

That distinction also occurs for procedures. This attachment illustrates it more simply, I believe: whattypefun.mw

Personally I don't understand how anyone could use whattype for decent programming, even apart from last name evaluation examples.

I'm guessing that one goal might be to have it be fast and efficient/lightweight.

It's possible that floats stored in a datatype=float[4] rtable could be written over to a (reusable) datatype=integer[1] rtable, and then that could be further decomposed. I'm unsure whether that could be handled directly (by convert, etc), without muddling with sign bits.

(I recall once using a define_external to do such a raw copying of the GMP representation of float approximations of Pi as stored in Maple's memory, to get the bit representation without need for unnecessary computational conversion. Unfortunately I have little idea where I left that code... but the essence was the same IIRC, maybe tricking a BLAS scopy into doing the moves.)

Someone asked a similar Question recently, and I answered with some notes.

Writing a robust conversion utility may have a few tricky parts. In order to avoid any unwanted automatic simplification all input may have to be treated by ToInert, and I can imagine it getting complicated.

@zenterix As mentioned, the RootOf is a placeholder; it's a stand-in for the root.

Maple has a considerable amount of advanced mathematical machinery that can substitute/manipulate/combine/cancel/etc for expressions containing RootOfs.

As you can see from this example, there may be more than one way to express a root implicitly, in terms of RootOfs. Maple's solve command does some post-processing that it thinks will express such implicit polynomial roots in a useful form.

Here are a couple of internal steps it might perform:

SolveTools:-MaxIndepRootOf( RootOf(_Z^2-2*_Z+4, label=_L2) );
                      /  2                      \
              2 RootOf\_Z  - _Z + 1, label = _L1/

SolveTools:-UnwindRootOfs( {y = RootOf(_Z^2-2*_Z+4, label = _L1)} );
           /            /  2                      \\ 
          { y = 2 RootOf\_Z  - _Z + 1, label = _L2/ }
           \                                       / 

I'm not sure whether you are convinced why your original results worked. The quantity R is clearly a root of the equation on the first line below. And it follows that y=2*R is a root of the third line's equation.

p2 := R^2 - R + 1 = 0;

              2            
       p2 := R  - R + 1 = 0

eval(p2, R=y/2);

        1  2   1          
        - y  - - y + 1 = 0
        4      2          

4*%;

          2              
         y  - 2 y + 4 = 0

@zenterix Solve the first equation for x, and then substitute that result for x in the second equation.

Here's an illustration. (The 3rd and 4th steps are only to help make it more clear. I don't know what aspects are holding you up.)

sys1 := [x+y=2, x*y=4]:

solve(sys1[1], {x});

     {x = -y + 2}

eval(sys1[2], %);

     (-y+2)*y = 4

% - lhs(%);

     0 = 4-(-y+2)*y

expand(%);

     0 = y^2-2*y+4

solve(%, explicit=false);

   2*RootOf(_Z^2-_Z+1)

@Joe Riel That's nice. Vote up.

But perhaps its ModuleLoad's conditional statement should test
   if catchall=true ... then
instead of just
   if catchall ... then
As written, that might be neither true nor false, if Catch has not been called but the package loaded, resulting in a runtime error.

And does Clear or similar always need to be used before Caught can be retried with an earlier argument, or else risk a false positive?

Also (quibble?, not sure) could/should,
  print('INTERFACE_WARN'(...)
be,
  streamcall('INTERFACE_WARN'(...)
 

Your approach reminds me of a module I once wrote to redirect voluminous userinfo messages to a TextBox/TextArea.

There is no "method RK45" as you typed it.

There is a method rkf45, for which Carl has given you an answer in the case of a procedure return by dsolve. (There is also a possible array-style return from dsolve, but I'm not sure whether you'd find the relevent dsolve internals directly useful.)

There is also a classical submethod rk4, for which from within dsolve you can see a portion as the meth=4 case as shown in,
    showstat(`dsolve/numeric/classical`)

Warnings are not directly programatically trappable by try..catch or traperror.

The warning you mention is made by a Maple library procedure: an internal of the Optimization package. That procedure gets an error code back from an external call to a compiled C function (NAG library), and in this case it means the numeric situation described.

By having your own procedure which makes the external-calling you could programmatically receive the info return-value and make your own next decisions. If you wanted I could show you how the external call could be made for your given example.

One kludgy alternative might be (on the fly) to replace the key Optimization internal procedure with a close duplicate -- whose difference is that it assigns the externally received info value to a Maple global variable which could be tested programatically.

If any of this seems worthwhile attempting to you, then please say which. (I'm pretty busy but it might be short...)

@zenterix There is a page with a form, linked the "Submit Software Change Request" item in the "More" drop-menu near the top on the Mapleprimes page.

I already submitted it, for that current directory/libname documentation issue.

@zenterix The current directory (or ".", to be more precise) is no longer automatically added to libname.

That changed between Maple 2015.2 and Maple 2016.

IMO it was a mistake to ever have it that way. Any errant .m or .mla could cause mysterious behavior.

The phrase "as well as your current directory" in the note in subsection Custom Libraries of section 11.3 of the Programming Guide is out-of-date, I suspect. I shall file a bug report.