@PatrickT The relevance of that quote to `rtable_scanblock` ends before the sentences about Java.

Roughly speaking, Maple consists of a (interpreting) kernel written in C, libraries of procedures and modules (which get interpreted) written in Maple, some dynamically loadable compiled libraries written in C and C++, and a few different user interfaces which communicate (with sockets, say) with the kernel over various streams.

Of those user interfaces, the commandline interface (CLI) is written in C, the Classic graphical user interface (GUI) is written in C++ (and uses the old Starview widget library), while the Standard graphical user interface is written in Java (and related tech).

The thread safety mentioned on ?rtable_scanblock is referring to threading that might be accomplished using the mechanisms underlying the Threads package, which is a kernel thing not a GUI thing.

In other words, it's not related to Java, in this context.

This is a nice idea.

Perhaps someone can come up with super fast code to generate it (as CURVES call, or what have you).

acer

@Michael The angle brackets are a shorthand syntax for the Matrix and Vector constructors.

L1:=[1,2,3,4,5]:

L2:=[1,4,9,16,25]:

<<L1>|<L2>>;

                                   [1   1]
                                   [     ]
                                   [2   4]
                                   [     ]
                                   [3   9]
                                   [     ]
                                   [4  16]
                                   [     ]
                                   [5  25]

Matrix([Vector[column](L1),Vector[column](L2)]);

                                   [1   1]
                                   [     ]
                                   [2   4]
                                   [     ]
                                   [3   9]
                                   [     ]
                                   [4  16]
                                   [     ]
                                   [5  25]

See this MVshortcut help-page.

The usage in the Answer above relates to the calling sequence of `plot` with the first argument being an mx2 Matrix (or a list of same, for multiple data sets).

@Michael The angle brackets are a shorthand syntax for the Matrix and Vector constructors.

L1:=[1,2,3,4,5]:

L2:=[1,4,9,16,25]:

<<L1>|<L2>>;

                                   [1   1]
                                   [     ]
                                   [2   4]
                                   [     ]
                                   [3   9]
                                   [     ]
                                   [4  16]
                                   [     ]
                                   [5  25]

Matrix([Vector[column](L1),Vector[column](L2)]);

                                   [1   1]
                                   [     ]
                                   [2   4]
                                   [     ]
                                   [3   9]
                                   [     ]
                                   [4  16]
                                   [     ]
                                   [5  25]

See this MVshortcut help-page.

The usage in the Answer above relates to the calling sequence of `plot` with the first argument being an mx2 Matrix (or a list of same, for multiple data sets).

@Joe Riel This is a potentially very useful and important observation, Joe!

The speedup and memory use improvement is significant. There are scenarios involving (Plot Component based) "animation" where this could make a big difference to the Library side aspect of performance.

Here's something I noticed, when trying such a "by reference" use of a float[8] Array inside a 3D plot structure (MESH), that perhaps you could corroborate. If plots:-display is used to merely add a view option to the PLOT3D, then memory allocation rises by what seems to be the cost of a full copy. But this might be avoided by instead manually, explicitly generating the new result with something like PLOT3D(op(...),VIEW(..)) or by a subsindets on the VIEW, instead of calling plots:-display to only apply the new view. Is that right?

I had no problem plotting your problematic example, in Maple 14.

Please upload your worksheet, so that we might figure out what's going wrong for you. (Use the green up-arrow in the menubar of the editing window, on this site.)

ps. It's almost never helpful to post mere images of 2D Math input to this site, even if the site works and we can see them.

acer

@PatrickT I suggest keeping the source of your involved procedures and packages in plaintext .mpl files, for a number of reasons:

• It's extremely rare to lose source due to a corrupt plaintext file. In contrast, we've seen reports of members with unloadable .mw worksheets here, about 4 times in the past month.
• Revision control! Organize your revisions, and add protection against clobbering. See RCS (its predecessor CVS) or the many modern alternatives.
• Code edit regions and Start-up code sections are fine and dandy for one-off stuff, but they don't provide the kind of simple intersession & interworksheet re-use that's provided by savelib/libname and library archives. Those code regions are fine, as quiet places to invoke your savelib'd packages & procedures, of course.

You mentioned that you use Linux (at home?). Why not use cygwin on that Windows system (at work?) and take some of the DOS-pain out of the scripting? Just a thought.

@PatrickT I suggest keeping the source of your involved procedures and packages in plaintext .mpl files, for a number of reasons:

• It's extremely rare to lose source due to a corrupt plaintext file. In contrast, we've seen reports of members with unloadable .mw worksheets here, about 4 times in the past month.
• Revision control! Organize your revisions, and add protection against clobbering. See RCS (its predecessor CVS) or the many modern alternatives.
• Code edit regions and Start-up code sections are fine and dandy for one-off stuff, but they don't provide the kind of simple intersession & interworksheet re-use that's provided by savelib/libname and library archives. Those code regions are fine, as quiet places to invoke your savelib'd packages & procedures, of course.

You mentioned that you use Linux (at home?). Why not use cygwin on that Windows system (at work?) and take some of the DOS-pain out of the scripting? Just a thought.

@Feryal In Maple 14.01, on Windows, it worked for me (after adding missing semicolons to ends of lines) if the result from the final call to animate got another evaluation.

Ie, using,

eval(animate(display, [g(p)], r=-1..1));

@Feryal In Maple 14.01, on Windows, it worked for me (after adding missing semicolons to ends of lines) if the result from the final call to animate got another evaluation.

Ie, using,

eval(animate(display, [g(p)], r=-1..1));

How come you use your own transformer, instead of using plottools:-rotate?

By some weird coincidence, I was just working on an efficiency improvement to how plottools:-rotate does this task, but for 3D. It makes a nice improvement, since plottools:-rotate always converts a float[8] rtable inside a GRID or MESH into a list of lists. It's more efficient to produce another float[8] rtable instead. And it's even more efficient, if rotation is all that happening for the animation, to do it in-place on the original rtable. (I'll edit this later, hopefully with some useful code, and also properly cite Joe Riel who first posted that superb inplace trick, by having the plot structure merely reference a 2D PLOT rtable by name. But I have to do something else for a few hours.) Anyway, stay tuned if you're interested in squeezing this to be as fast as possible.

acer

@PatrickT Just an idea, for a stripper of trailing zeroes,

restart:

P:=piecewise(t < 10., (.50*(1-.100*t))*exp(-0.500e-1*t)
                       +.50*exp(-.10*t), .50*exp(-.10*t)):

strip:=Z->subsindets(Z,{float},z->parse(sprintf("%g",z))):

plot(P,legend=[D(t)=strip(P)]);

plot(P,legend=[D(t)=evalf[3](strip(P))]);

Another possible advantage of the first of those pair above, over simply hitting the whole expression with `evalf[d]`, is that constants like Pi can be preserved.

You may have to slightly resize or stretch the inlined plot, if you want the legend items to be typeset all on a single line. This is a more general issue, and not related to methods suggested here, I think.

Another variant is,

strip:=(Z,d)->subsindets(Z,{float},z->evalf[d](parse(sprintf("%g",z)))):

bug?: when using so-called array-plots (like plots:-display(Array([plot(..),..plot(..)]))) the piecewise structure is not nicely typeset as 2D in the legend.

As for the subject of legend placement, it maybe that for many plots a very nice location would be in the blank, white area that can fall inside the axes area itself. For this plot, a slightly smaller sized legend in the top-right corner of the axes-boxed region could be a very economical and appealing use of the space. And Maple is powerful enough to code such a determination (including whether its even feasible, for any given plot). It's just more involved.

@PatrickT Just an idea, for a stripper of trailing zeroes,

restart:

P:=piecewise(t < 10., (.50*(1-.100*t))*exp(-0.500e-1*t)
                       +.50*exp(-.10*t), .50*exp(-.10*t)):

strip:=Z->subsindets(Z,{float},z->parse(sprintf("%g",z))):

plot(P,legend=[D(t)=strip(P)]);

plot(P,legend=[D(t)=evalf[3](strip(P))]);

Another possible advantage of the first of those pair above, over simply hitting the whole expression with `evalf[d]`, is that constants like Pi can be preserved.

You may have to slightly resize or stretch the inlined plot, if you want the legend items to be typeset all on a single line. This is a more general issue, and not related to methods suggested here, I think.

Another variant is,

strip:=(Z,d)->subsindets(Z,{float},z->evalf[d](parse(sprintf("%g",z)))):

bug?: when using so-called array-plots (like plots:-display(Array([plot(..),..plot(..)]))) the piecewise structure is not nicely typeset as 2D in the legend.

As for the subject of legend placement, it maybe that for many plots a very nice location would be in the blank, white area that can fall inside the axes area itself. For this plot, a slightly smaller sized legend in the top-right corner of the axes-boxed region could be a very economical and appealing use of the space. And Maple is powerful enough to code such a determination (including whether its even feasible, for any given plot). It's just more involved.

This was a good idea 4 years ago, and seems just as good today(!).

Do you imagine that in practice one might actually need an explicit formula (eg. symbolic expression, or piecewise of same)?

Or would it suffice to have returned some black-box procedure which could be efficiently polled for values. Ie. you supply a single numeric point and it returns a scalar numeric result. Such a procedure could (if you deem it wise) be numerically integrated, or searched for extrema, etc, as well as used to get the pointwise squared residuals.

Having both 2D and 3D versions could also be nice.

Implementing this might be fun, especially for 3D. Inherently expensive... so lots of motive for parsimony. A crude first attempt might just leverage Statistics:-Fit, with repeated calls according to the window-width. (Oh, for a 48hr day...)

acer

@Markiyan Hirnyk The tougher challenge is to have a root-finder get a real root for this problem when not supplied with a narrow search range.