@Christopher2222 Yes, that's part of the details I've amassed for bug reports on this. It's a really pity, too, since the Maple 12 plot which appears inlined in the worksheet, as seen above, is quite beautiful and "professional looking". It's quite close to what I'd expect to see as high end graphics in a journal. But the smallest pointsize that exports as non-blank, giving similar to the other plot above, well that plot is quite the opposite.

I didn't mention it earlier, but it would also be possible to quickly generate an image file for this that looked good. and the axes & extras can often be faked ok in an image being formed using ImageTools. And this is fastest: no display in the GUI at all, just create and export.

Also, I didn't try the programmatic export drivers for Standard, which seem different from the right-click export drivers. And I didn't try programmatic export from Classic/CLI.

@herclau If I understand your meaning, then, sure, there is often a tradeoff between performance and the need for "expert" coding. I'm pretty sure that one could construct an approach for this post's topics which might be almost as fast and not nearly as obscure.

Sometimes I fiddle with trying to find faster ways just because I'm interested in seeing how much a difference there is between 'natural' ways and optimized ways. And i like to find out what are the bottlenecks. Clearly there is a development goal of making more 'natural' ways to code a task also be amongst the faster performers. And it's often the opposite, unfortunately: that the most natural ways can be amongst the worst performers. So examining alternatives is a useful exercise.

From experience, I know that producing point-plots of many points (10s or 100s of thousands) can be very expensive in Maple, and that writing tuned code can make the feasible size problems be quite a bit larger. This is an area where a lot of improvement is possible,and there seems to be a demand for it.

I don't know what the best way is to learn technique here. Perhaps there is a window of opportunity for a book on the broader subject of numeric computation & performance in Maple. (Some days I wonder if I myself could write one well.) I do think that there is a BIG market for a good book on Maple plotting, but I'm certainly not the right person to write such a book alone.

@herclau If I understand your meaning, then, sure, there is often a tradeoff between performance and the need for "expert" coding. I'm pretty sure that one could construct an approach for this post's topics which might be almost as fast and not nearly as obscure.

Sometimes I fiddle with trying to find faster ways just because I'm interested in seeing how much a difference there is between 'natural' ways and optimized ways. And i like to find out what are the bottlenecks. Clearly there is a development goal of making more 'natural' ways to code a task also be amongst the faster performers. And it's often the opposite, unfortunately: that the most natural ways can be amongst the worst performers. So examining alternatives is a useful exercise.

From experience, I know that producing point-plots of many points (10s or 100s of thousands) can be very expensive in Maple, and that writing tuned code can make the feasible size problems be quite a bit larger. This is an area where a lot of improvement is possible,and there seems to be a demand for it.

I don't know what the best way is to learn technique here. Perhaps there is a window of opportunity for a book on the broader subject of numeric computation & performance in Maple. (Some days I wonder if I myself could write one well.) I do think that there is a BIG market for a good book on Maple plotting, but I'm certainly not the right person to write such a book alone.

As Joe mentions, there are lots of ways to get this for simpler examples. Here's a minor variant. (And yet another here).

restart:

show:=proc(expr::uneval)
   subsindets(expr,And(name,satisfies(t->type(eval(t),constant))),
              ``@eval)
   = eval(expr):
end proc:

a:=5;
                               5

b:=6;
                               6

c:=100;
                              100

show(a+b);
                         (5) + (6) = 11

show(a*b-c^2);
                                   2        
                    (5) (6) - (100)  = -9970

acer

As Joe mentions, there are lots of ways to get this for simpler examples. Here's a minor variant. (And yet another here).

restart:

show:=proc(expr::uneval)
   subsindets(expr,And(name,satisfies(t->type(eval(t),constant))),
              ``@eval)
   = eval(expr):
end proc:

a:=5;
                               5

b:=6;
                               6

c:=100;
                              100

show(a+b);
                         (5) + (6) = 11

show(a*b-c^2);
                                   2        
                    (5) (6) - (100)  = -9970

acer

@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.

@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));