@Christopher2222 If I may offer a little advice here, it would be to listen to Erik's suggestions. Statistics:-Sample can already produce what you've asked about, so why expend effort making some other routine do it too? The routine you write about changing merely calls Statistics:-sample to do the work anyway.

Erik's example a4 above shows that lines 18 and 19 of ArrayTools:-RandomArray might be combined (optimized) into just a single line using Statistics:-Sample.

You mentioned altering routines. Do you mean like this? The only reasons I did it that was because a) I was doing it for someone else to use, and so could publically post a solution without posting the full source of the routine and potentially violating copyright, and b) it was fun. That is overkill, for rewriting something for yourself. (...and nobody else needs it, as Statistics:-Sample does it directly already).

The ArrayTools:-RandomArray routine is only about 30 lines of non-comment code. Instead of using `showstat`, you could just `print` it, then edit it to suit yourself, and then savelib to a new private archive if you want to re-use. You could change the parameter-processing typecheck on the 'distribution' keyword parameter so as to accept something like 'normal(m,s)' instead, and to use the `m` and `s` when it calls Statistics:-Sample internally.

It should be a very simple set of edits. But I would still advise leaving ArrayTools:-RandomArray by the wayside.

One thing that you very much ought not to do is to change and then savelib your working copying of RandomArray in such a way that your sessions get the new version by default. You almost certainly cannot know (without a comprehensive test suite) that no other standard routine does not rely upon the current behaviour (restrictive as it may be) and might malfunction were it changed.

SCRs to submit: RandomArray might call Sample better, to remove some calls to Reshape. RandomArray should use 'datatype'='float' instead of 'datatype'='float[8]'.

@Christopher2222 I don't know exactly what herclau intended, but here is one way to adjust that code,

restart:

N := 30000:

start_time:=time[real]():

t := Vector(N, i->evalf[4]((2*i-2)*Pi/N), datatype = float[8]):

x := Vector(N, i-> cos(10*t[i])+I*sin(10*t[i])
     + ArrayTools[RandomArray](distribution = normal)/10.0
     + I*ArrayTools[RandomArray](distribution = normal)/10.0,
            datatype = complex[8]):

time[real]()-start_time;
                             44.754

plot(<map(Re,x)|map(Im,x)>,style=point,symbol=solidcircle,symbolsize=4);

time[real]()-start_time;
                             48.649

Without the imaginary noise component it might come out like this, with such an approach,

restart:
N := 30000:
start_time:=time[real]():
t := Vector(N, i->evalf[4]((2*i-2)*Pi/N), datatype = float[8]):
x := Vector(N, i-> cos(10*t[i])+I*sin(10*t[i])
     + ArrayTools[RandomArray](distribution = normal)/10.0,
            datatype = complex[8]):
plot(<map(Re,x)|map(Im,x)>,style=point,symbol=solidcircle,symbolsize=4);

I really do not wish to offend anyone, but it can be done about 100-1000 times faster (see my other Answer).

I suppose that <map(Re,x)|map(Im,x)> might also be obtained more efficiently using ArrayTools:-ComplexAsFloat. Anyway, I was only guessing at what herclau intended.

@Christopher2222 I don't know exactly what herclau intended, but here is one way to adjust that code,

restart:

N := 30000:

start_time:=time[real]():

t := Vector(N, i->evalf[4]((2*i-2)*Pi/N), datatype = float[8]):

x := Vector(N, i-> cos(10*t[i])+I*sin(10*t[i])
     + ArrayTools[RandomArray](distribution = normal)/10.0
     + I*ArrayTools[RandomArray](distribution = normal)/10.0,
            datatype = complex[8]):

time[real]()-start_time;
                             44.754

plot(<map(Re,x)|map(Im,x)>,style=point,symbol=solidcircle,symbolsize=4);

time[real]()-start_time;
                             48.649

Without the imaginary noise component it might come out like this, with such an approach,

restart:
N := 30000:
start_time:=time[real]():
t := Vector(N, i->evalf[4]((2*i-2)*Pi/N), datatype = float[8]):
x := Vector(N, i-> cos(10*t[i])+I*sin(10*t[i])
     + ArrayTools[RandomArray](distribution = normal)/10.0,
            datatype = complex[8]):
plot(<map(Re,x)|map(Im,x)>,style=point,symbol=solidcircle,symbolsize=4);

I really do not wish to offend anyone, but it can be done about 100-1000 times faster (see my other Answer).

I suppose that <map(Re,x)|map(Im,x)> might also be obtained more efficiently using ArrayTools:-ComplexAsFloat. Anyway, I was only guessing at what herclau intended.

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

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