These plots render much less grainily in the actual Maple GUI.

[edited: I've added in the version without the black borders, and with the borders shaded to match one of the adjacent fill colors, and made a correction to the bookkeeping there.]

>  >  Filter:=proc(input_signal) #Band-pass filter >  >  >  >  #Correct timescale >  >  Parameters for STFT >  >  >  >  >  >  >  >  >  >  This works, but its use of subs, in a listdensityplot, seems awkward. The plots:-surfdata command offers an easier way to specify the ranges. (See below). >  >  clist := ["#00007F", "Blue", "#007FFF", "Aqua", "#7FFF7F", "Yellow", "coral", "Red"]; >  Concerning the Second Part of the Question: how to do the above more straightforwardly: Instead of trying to fix up that listdensityplot's ranges, we can use the simpler functionality to specify the ranges that the plots:-surfdata provides. ans_surf:=plots:-surfdata(res1, dimension=2, 152 .. 160, 0 .. 500, view = [t1 .. t2, 5 .. 60],                           style = patchnogrid, colorscheme = clist,                           labels = ["Time (ms)", "Frequency (kHz)"],                           labeldirections = [Horizontal, Vertical], axes = box,                           axesfont = ["Arial", 14], labelfont = ["Times New Roman", "Bold", 16],                           title = "Spectrogram", titlefont = ["Calibri", "Bold", 16], size=[500,500]): ans_surf; >  Concerning the First Part, how to shade a listcontplot by a list of more than two colors: this solution implements multiple regions with solid colorings. (Obtaining multiple distinct shaded gradients would be another interesting goal, possibly done by constructing multiple surfdata results using piecewise undefined data?!) Make a listcontplot with coloring from Black to pure Red. Thus the COLOUR substructures will have RGB values with the red component between 0.0 and 1.0. PP := plots:-listcontplot(res1, coloring = ["Black", "Red"], filledregions = true, thickness=0,                           levels = nops(clist)-1): #clistlist := map(c->[ColorTools:-Color(c)[]], ListTools:-Reverse(clist)): Clist := map(c->[ColorTools:-Color(c)[]], clist): Replace the COLOUR substructures with colors from out list, taking the position based on the relative position of the existing red component between 0.0 and 1.0. recoloredPP := subsindets(PP, specfunc(POLYGONS),                           p->subsindets(p, specfunc(COLOUR),                                         c->COLOUR(RGB,Clist[1+round((nops(Clist)-1)*(op(2,c)))][]))): Instead of fiddling with forced tickmarks, transform the listcontplot from being 1..14,1..513 to 152..160,0..500 .   adj := plottools:-transform((x,y)->[152+(x-1)/(14-1)*(160-152),0+(y-1)/(513-1)*(500-0)]): newPP:=plots:-display( adj(recoloredPP),                        view = ["default", 5 .. 60],                        labels = ["Time (ms)", "Frequency (kHz)"], labeldirections = [Horizontal, Vertical],                        labelfont = ["Times New Roman", "Bold", 16],                        axes = box, axesfont = ["Arial", 14],                        title = "Spectrogram#2", titlefont = ["Calibri", "Bold", 16], size = [500, 500]): newPP; >  #plots:-display(Array([ans_surf, newPP])); >  We can also test the transformer adj, by overlaying an unfilled listcontplot with the sufdata plot. If the transformer is correctly done then the contours would lie on the locations where the smoothed/interpolated colors's underlying values change. This is just a sanity check. unfilledPP:= plots:-listcontplot(res1, coloring = ["Black", "Red"], thickness=0, levels = nops(clist)-1): plots:-display( ans_surf, adj(unfilledPP) ); >  What if we don't like the black lines in the listcontplot result? We can remove them: newPPnocurves:=subsindets(newPP,specfunc(CURVES),()->NULL): newPPnocurves: >  The edges of the filled regions appear ragged when the CURVES substructures have been removed. We can add shaded versions of those CURVES, so that the edges of the filled regions once again appear smooth (but not all the same colour). Note that we have a choice between overlaying any ragged POLYGONS edge with either the lower or the upper adjacent color. We can construct those CURVES (contours) using the same technique as before, but this time leaving out the filledregions option. PPcurves := plots:-listcontplot(res1, coloring = ["Black", "Red"], levels = nops(clist)-1, thickness=0): recoloredPPcurves := subsindets(PPcurves, specfunc(CURVES),                           p->subsindets(p, specfunc(COLOUR),                                         c->COLOUR(RGB,Clist[`if`(op(2,c)=0.0,1,1+round((nops(Clist))*(op(2,c))))][]))): newPPcurves:=plots:-display( adj(recoloredPPcurves),                              view = ["default", 5 .. 60] ): newPPcurves; >  Now we'll combine the multicoloured filled contour plot with the multicoloured unfilled contour plot. newPPboth := plots:-display(newPPnocurves, newPPcurves): newPPboth; >  We could compare the multicoloured listcontplots, both with and without the added multicolored contour CURVES. plots:-display(Array([newPP, newPPnocurves, newPPboth]));         >  We could compare with the original plots:-surfdata plot (keeping in mind that there were only 14 x-data points for each y-data point, which is coarse data). plots:-display(Array([ans_surf, newPPboth]));         >

Download Maple_s_test_3.mw

Your result is from the (deprecated) linalg[eigenvectors] command. It uses a format in which the multiplicity of the eigenvalues is part of the result. Notice that it shows a multiplicity of 2 for the eigenvalue equal to 1000. All the other exact eigenvalues have multiplicity of 1. So eigenvectors returns 7 lists, but they denote 8 eigenpairs.

Download Method-two_1.mw

[edited] Since the rosser Matrix is sometimes used as a classic stress test of floating-point eigen-solvers here is another attachment with floating-point results added. I show (at Digits:=15 to compare linalg results with default double-precision LinearAlgebra results and Matlab) results for linalg, and LinearAlgebra both with and without the input being qualified by shape=symmetric.

Method-two_2.mw

Is that an errant multiplication symbol (centre dot) between Read and the opening round bracket? I mean in the 2D Input line near the bottom of your own code (after the restart). It looks like the Read didn't happen because it was accidentally entered as multipication.  (The blue output supports this view.)

The (**) is the start and finish of a multiline comment. You can start a comment with (* and finish it with *). 

I've seen some people set the prompt string from ">" to "(**)" so that they can cut and paste whole chunks from the Command-Line Interface into either the Standard GUI or the CLI. That allows them to run the code without having to delete the prompts. It looks like the CodeBuilder's help page might have all its red Execution Group statements done that way.

Download sum_trick.mw

[edited] I should mention that the "trick" is not general purpose, and happens to work because of properties of this particular example. So one lesson is that thinking about a problem can sometimes lead to clever reformulation into an equivalent problem that is more easily handled.

This is a bug in the is command. It's surprising to me, because often is does well, yet for this example it produces a wrong result while several other commands get there.

Curiously, it seems to depend on the Pi, in particular.

Download is_weakness.mw

I usually call solve wrapped in square brackets. That makes the result a list of solutions. And then I can always use the indexing the same way, even if there is just one solution.

sol := [solve( ... )];

sol[1]; # first solution, whether there are more than one, or not

sol[i]; # ith solution

sol[1][j]; # jth element of first solution

sol[i][j];  # jth element of ith solution

One thing you can try is to force the alternate method=RC of RootFinding:-Isolate . Or you could try some other options to that command. Note that the problem of finding all roots of a system of polynomials with rational coefficients can be hard.

In Maple you can view the interpreted Library source using commands like showstat command. For example,

showstat(RootFinding::Isolate);
showstat(fgbrs::rs_isolate_sys);
showstat(fgbrs::rs_isolate_gb); 
showstat(fgbrs::rs_rur_sys);

The RS method of RootFinding:-Isolate makes calls to compiled libraries of the FGb and RS applications. It looks like it might be possible to utilize the 3rd party RS compiler libraries without a Maple interface layer, but I have no experience in doing so.

The RC method of RootFinding:-Isolate makes use of the RegularChains package (of which major portions are also in compiled libraries). See also the 3rd party homepage of the RegularChains project. I am not sure how easy it might be (if even possible) to utilize the compiled library portions without the Maple Library interface layer.

I don't think that you'd have joy trying to use these projects stand-alone outside Maple, unless you really enjoy programming riddles.

It might be that either of those 3rd party packages (including Maple full or partial interfaces) has a later version than what is shipped with your Maple version (even if current 2017.3). Even if true I don't know what compatibility issues might arise. It might not even be the case.

The global name can be accessed as :-x which distinguishes it from a local or parameter by the same name.

Below I throw single right quotes (a,k.a. uneval quotes) around it, because it's a good habit to protect such references against the case that the global name has been assigned a value (which is why mint complains). But for your example you can use :-x instead of ':-x' if you really want to.

test:=proc(function,{x::range:=0..1})
  plot(function,':-x'=x);
end proc:

test( sin(x) );

test( sin(x), x=2..4 );

IMO it's not great programming practice to restrict a procedure to work only for expressions that depend upon one particular name. Better would be to pass in the dependent name, or have the procedure figure it out, or pass in both name and range as an optional positional parameter.

Here are two possibilities (for Maple 2015 through 2017). One scheme incorporates the open brackets that Maple used in version 18 and earlier. The other scheme keeps the new, unfenced pretty-printing but applies a color.

Let me know if things like copy&paste work. The context-menu "Units formatting" may not allow changing the "system", but does seem OK with specific unit replacement (eg. N to replace m*kg/s^2).

Note that this only affects output. The behaviour of 2D Input (including use of the Units palette) appears the same.

Since Mapleprimes currently uses an old worksheet renderer (Maplenet?) the display below shows the older open brackets around the two schemes' outputs as well as for the default output of the initial statements executed before I redefine the print extension. (eg. for scheme 1 there are nested brackets.) I'm inlining the attachment here in this Answer anyway. In the Maple Standard GUI those extra open brackets don't appear in the output.

Download unit_print.mw

Please upload your worksheet using the green up-arrow in the Mapleprimes editor, instead of pasting in a screen-shot.

It's difficult to read your screen-shot image. But one thing that does stand out is that you're incorrectly using square brackets for grouping subexpressions. You need to use round brackets for that. (Square brackets are for creating lists.)

The assignments do succeed. They just don't print anything. If you want you can print something after the fact...

Download assignation_1.mw

Whether the 2D Input

   d := "hello"

echoes (in the output region) only the result or the whole assignment statement is behavior that varies according to a few things.

It varies according to whether interface(typesetting) is set to `extended` or `standard`.

It can also vary according to whether you are in an Execution Group (in a Worksheet say) or a Document-Block (in a Document).

I think it only makes sense to compare the same cases between versions.

Note the the default typesetting level changed from standard to extended, between Maple 2016 and 2017.

What major and minor versions are you using, precisely? Which typesetting level in each?

See the Grid package.

You could also look at the Threads package (but I suspect that it will not be suitable, if your computations involve code the is not thread-safe).

There is an undocumented export Hyperlink of the DocumentTools:-Layout subpackage.

You cannot get a hyperlink in regular printed output, but you can include it in embedded content.

hyperlink_embed.mw

With an explicit expression (formula) for the individual terms you can do symbolic summation using the sum command. For your example the summation can be computed to a closed-form expression formula, whose exact limit can then be taken, as Kitonum has shown.

But with a procedure that only computes the addition of a particular number of terms the limit command will not see any formula and so exact computation of the limit cannot be done. The procedure is then a black-box, as far as the limit command is concerned.

With such a procedure it is still possible to compute the limit to a non-exact floating-point value, by using a command that numerically computes the addition of various finite numbers of terms and then determines whether those results converge.

Download evalf_limit.mw