@casperyc I think I cautioned against having multiple calls to `p` and running with the menubar's triple-exclamation (execute worksheet). It seems necessary for the GUI to finish inserting components before calling `p` again, else perhaps it gets confused about the names of inserted components.

It does seem ok to call `p` (once each) in separate and multiple execution groups or document blocks, as long they don't occur in too rapid a succession.

Capital P is the local variable which gets assigned the plot. I'm not sure why it might return unevaluated. If you run into issues with this then you could send me a private message and your code. I didn't use any try..catch mechanisms or other checks that plots had indeed been created. Were you planning on calling it many times, or were you just trying to stress test it all?

@casperyc Here is a version in which the procedure creates and embeds a Plot Component, updates it while computing, and then finally returns the final plot (after apparently clearing off the embedded component).

Calling procedure `p` shows intermediate results by updating an embedded Plot Component, but the return value of a completed call to `p` is an actual plot and can be assigned like any other result (as long as the call to `p` is allowed to complete).

It works best in a Worksheet, in an execution group. It may work in a Document, in a paragraph (document block). But it appears to not work as in an execution group in a Document. It likely works best in Maple 18.01, and not at all in anything before 18.

The technique is full of undocumented commands. The basic idea is also a trick, relying on the fact that in M18 (and perhaps M17) a procedure call in an input region can have not only a usual output region but also a task region. (This is how Grading:-Quiz and Explore work, btw.)

The attached worksheet may only work as intended if the seperate examples of calls to procedure `p` are in separate execution groups.

ticker2.mw

Upon reflection, it might be easier to handle efficiency as simply as possible here. I've pretty much just relied on the garbage collector doing a decent job. And an easy improvement is to only update the plot every 100 (or whatever) iterations.

@casperyc It can be made to plot either all the points, or just the later ones, sure. It's ok to have A be local, but of course for efficiency Array A must be created just once outside the loop. There are more efficient ways to build the PLOT structure, yes -- more on that later. And it is possible to have the procedure emit the PlotComponent (right below) any eventual output. And distinct calls to your computation routine could emit and use their own distinct PlotComponents. The return value could also include the final plot, sure.

It'll take me a while to construct a more thorough example with these ideas. Perhaps later this evening...

@rightClick I see. If I try it on the output of the following command then I get the problematic behaviour you described if I have typesetting level set to "standard". But it seems to work ok if instead I have that level set to "extended".

`𝓍__2`(s) = 1/(s^2+3*s+2);

There are at least two ways to set the typesetting level to the extended mode. One way is to use the menubar choice Tools->Options-Display and change the dropmenu "Typesetting level" from being "Maple Standard" to being "Extended". Another way is with the command,

interface(typesetting=extended):

I will submit a bug report against this problem.

It works for me, in Maple 18.01 on Windows 7 64bit, using both 2D Math and 1D Maple Notation modes for input as well as using both "standard" and "extended" typesetting modes.

I used x[2](s) as the left-hand side of the equation, which I would have expected not to matter here. Your italic x seems larger. Just for interest's sake, what did you enter it as?

acer

@Alejandro Jakubi Ok, it is sold by Maplesoft (and I edited my comment accordingly). It's still a bug in the IDE add-on if it claims that valid Maple syntax is invalid. Do you disagree?

Note that I have at no point claimed that such add-ons are de facto at fault if their behavior goes against that of the Maple product proper. In this particular case it seems to me that the described behavior of Maple is fine, and the syntax is valid.

The one accepted by Maple itself is correct.

The Maple IDE is an add-on product. This appears to be a bug in the add-on product.

acer

@Joe Riel It would be great to see such a useful package be included directly in the next major releases of Maple.

@jzivku I downloaded your linked file BioCalc.zip and unzipped. This produced a directory named BioCalc, which contained another zip file named Biocalc.zip.

Now, in Maple 18.01 on 64bit Linux, I get,

questions:=MapleTA:-Import(cat(kernelopts(homedir),"/Downloads/BioCalc/Biocalc.zip"));
Error, (in MapleTA:-Import) module does not export `questions`

What should I being doing instead, to access the questions directly in Maple 18.01 using the Grading:-Quiz command?

@Carl Love These approaches of conversion to seq (or list, or listlist then flattening) following explicit Matrix transposition can break down for large size Matrices. For example, with a 1000x1000 Matrix M with entries between 0 and 9 say, the system may take much more time and possibly even hit stack limits.

Using a single sprintf call with tailored rtable (Matrix, Vector, etc) formatting such as printf("%{ns}ld\n",M) holds up much better at larger sizes. It can also walk entries by column with a minor modification, ie, printf("%{tns}ld\n",M) to act on the data columnwise (as if transposed).

@Carl Love There is a need for better handling of oscillatory integrands taken over a semi-infinite range, or an oscillatory integrand over a finite range which can be mapped to the former. Suggestions in the past have included something like the Levin-u transform for numeric summation, possibly taking the addends as the integral  over each cycle. A quick google search reveals this hit of a feature new in Mma 8. (I've tried splitting some examples with NextZero, then using evalf/Sum, but it needs a more serious effort I'm sure.)

Also, there are some examples of complex-valued integrals which can be easily split (manually) into real and imaginary components with evalc and then fed separately to fast methods such as _d01ajc. But the system doesn't seem to handle that automatically.

@nm Note that without square brackets around the arguments to Vector the first argument will specify its size. So Vector(91, blah) produces a Vector with 91 entries.

@Markiyan Hirnyk You forgot to restart between the two cases, so in your worksheet some computations are remembered and your second call is artifically appearing faster than it is.

Also, it's a mistake to re-execute with !!! rather than line by line, and to display the plots. On avg the second example is slightly faster (about 109ms versus 125 ms on my machine, over many separate runs). This difference might be due to the fact that the `map` case has an extra custom operator call ( as i->i*sin(i) ) for each entry's construction. And the `map` case produces two lists (one of which is temp garbage) rather than just one, so there is a memory used and alloc difference as well. But these effects might become negligible as the examples becomes much larger and involved.

restart;
with(CodeTools):
Usage(plot(map(i->i*sin(t),
           [seq(i, i = .1 .. 1, 0.2e-2)]), t = -2*Pi .. 2*Pi)):
memory used=131.28MiB, alloc change=41.86MiB, cpu time=1.90s, real time=2.09s, gc time=46.80ms

restart;
with(CodeTools):
Usage(plot([seq(i*sin(t), i = .1 .. 1, 0.2e-2)], t = -2*Pi .. 2*Pi)):
memory used=131.58MiB, alloc change=41.12MiB, cpu time=1.89s, real time=2.10s, gc time=46.80ms

The small size of the example makes the variation relatively huge, between runs. So without a larger run, or averaging, it's too easy to get an erroneous conclusion.

@Markiyan Hirnyk I ran your worksheet in Maple 18.01 and it displayed z not z~ as output.

@Preben Alsholm I wonder whether this kind of output -- or something similar -- might relate to why inttrans is still table-based. Perhaps there are recursion or efficiency issues. I'm just wondering out loud -- I don't know.