Download simptrigexample.mw

[edit] I see that others have responded since I last refreshed this webpage in my browser (which I did only after I posted my answer). So, taking the OP's hint, I can reduce the number of steps in my original answer, by avoiding my previous separation of numerator and denominator,

convert(simplify(evalc(evala(expand(convert(f1,exp))))),
        phaseamp,y);

                            /    1   \
                         sin|y + - Pi|
                            \    6   /
convert(simplify(evalc(radnormal(expand(convert(f1,exp))))),
        phaseamp,y);

                            /    1   \
                         sin|y + - Pi|
                            \    6   /

note: Simplifying the intermediate result immediately prior to these latter calls to evalc may illustrate that I'm using evalc primarily as a convenient shorthand for conversion to trig (and avoiding a division by zero), not because I'm trying to concede something about realness of y more generally).

You didn't tell us the aspect ratio (relative lengths displayed of the axes) that you wanted.

So you can try this, with a value for the parameter that suits you,

Download 3d_aspect_example.mw

This is simply a one-off of the idea I posted on more generally (but for 3D implicit plots) here.

You have previously installed the Syrup add-on package. It is bundled with a Help database file in the old .hdb format. The message is informing you of that.

You can convert that older format Help database Syrup.hdb to the newer format by following the instructions on the Help page whose topic is HelpTools,Migrate. The message is informing you that details are available on that Help page.

If you're not using the Syrup package's Help pages then you could simply ignore the message. If the message bothers you then you could remove the add-on or follow the instructions to update/migrate its help database file.

It is unclear whether you are asking about selected item or the action code of the Component. It's also unclear what you mean by "preprogrammed".

So I've done both for you, using two examples. If you're trying to ask about the selected item then my first example should make it clear. If you're trying to ask about the action code of the component then you can make it a string containing a procedure call of your choice (as I did in my second example), and you can define that procedure either before or after the insertion.

I've also fixed several mistakes.

ASK_ac.mw

I also toggled your Question as being for Maple 2016, since that's the version in which your attachment was last saved. It'd be helpful if you could do that yourself for future Questions.

You might be able to use something like this, for such (simple) ordered piecewise with a single parameter. I don't know whether you need to distinguish that the lower end-point is a strict inequality.

Download pwsupport.mw

Do you want it for all the procedures which are exports, or "package exports", or all exports and local procedures?

By "package exports" I mean those procedures returned by with (see also M:-_pexports() ).

If you want all the procedures which are exports of module M then you could do it like,

map(p->showstat(M[p]),
    select(p->type(M[p],procedure),[exports(M)])):

If you want only the procedures which are "package exports" of module M then you could do it like,

map(p->showstat(M[p]),
    select(p->type(M[p],procedure),M:-_pexports())):

If you also want the local procedures of module M then you could also process the names in [op(3,eval(M))] which are of type procedure. But for those you msy need :: syntax or :- syntax after toggling kernelopts(opaquemodules).

You could substitute for exact Pi using evalf, in the BCs and range, when calling pdsolve.

Download solving_wave_pde_evalfPi.mw

Did I do this right? (Even if ok, I expect someone will do it more cleverly.)

Download recur.mw

[edited] Using rsolve, (for S(n), an idea which Carl conceived and posted before I did).

Download recur2.mw

The call_external is a Maple mechanism which calls a function in an external dynamic library of compiled functions. For example such dynamic libraries have filename extension .dll on MS-Windows and .so on Linux.

Like much of the Maple kernel itself such functions are compiled (and stored in external dynamic libraries) for execution speed, or because they come from 3rd party sources as code in a language other than Maple.

In general it is not possible to view the source of such functions, unless they were compiled with debugging information. (That's an OS thing, rather than a Maple thing.)

Few if any of the stock external libraries shipped with Maple were compiled with debugging information -- and if they were then you'd still need an external debugger that could run the whole process, not just Maple's user-facing debugger.

The Maple command showstat is for displaying source of procedures in the Maple language. That has nothing to do with compiled functions in dynamic libraries.

I was looking at the second paragraph of the first bullet point in the Description of the help page for Topic rtable_eval, which reads as,

    Evaluation is needed provided the following two conditions are met.
    Firstly, eval(A[i],1) <> eval(A[i]) for a given element  "A[i]". Secondly,
    full evaluation must have been applied to A prior to calling rtable_eval(A).

So, for you example, the eval(v) could be before (or within) the rtable_eval call. At the top-level the eval call would not be needed I suppose.

proc() local x, v:= <x>; x:= 1; rtable_eval(eval(v)) end proc(); 
                              [1]

In Maple 17.02 I see the addition working that way (without evaluation) as for the multipication. I am not sure why the two now differ in behavior.

So, you want the running value of x in v to be used at each iteration?

Download matrixevalexample.mw

Here's an outline of the general idea. Adjust to taste.

for i from blah to blech do
    try
        dodgy_thing;
    catch:
        print("error encountered; skipped...");
    end try;
end do;

The name `&Delta;` (which line-prints similar to an HTML entity) gets pretty-printed like a Greek Delta in 2D Output.

You can concatenate that with another symbol of your choice, to get the effect you describe.

Download PutDelta.mw

In Maple 2018 and Maple 2019 something similar attains without having to specify method=ftocms for the int command.

Below I use Maple 2017.2,

restart;

kernelopts(version);

   Maple 2017.2, X86 64 LINUX, Jul 19 2017, Build ID 1247392

ig := R^2/(cosh(2*R)+cosh(rho))^2:

res := int(ig, R=-infinity..infinity, method=ftocms) assuming rho::real:

lprint(res);

(1/6)*exp(2*rho)*(-2*exp(2*rho)*Pi^2*rho-2*Pi^2*rho-2*exp(2*rho)*rho^3+2*exp(2*rho)*Pi^2+6*exp(2*rho)*rho^2-2*rho^3-2*Pi^2-6*rho^2)/((exp(2*rho)-1)*(-exp(4*rho)+2*exp(2*rho)-1))

eval(res, rho=1.2);

                         0.07643822467

evalf(Int(eval(ig, rho=1.2), R=-infinity..infinity));

                         0.07643822459

You asked why it goes wrong. It looks like the undesirable infinite result is coming out of the ftoc method (using regular series and limit).

Let's just take a rough look at the indefinite integration result, and compare :-limit vs Multiseries:-limit .

foo := int(ig, R):

limit(foo, R=infinity) assuming rho>0:
op(0,eval(%,1));

                 limit

MultiSeries:-limit(foo, R=infinity) assuming rho>0:
lprint(simplify(%)) assuming rho>0;

-(1/3)*exp(2*rho)*((Pi^2*rho+rho^3-Pi^2-3*rho^2)*exp(2*rho)+Pi^2*rho+rho^3+Pi^2+3*rho^2)/((exp(2*rho)-1)*(-exp(4*rho)+2*exp(2*rho)-1))

alt := MultiSeries:-limit(foo, R=infinity)
       - MultiSeries:-limit(foo, R=-infinity) assuming rho>0:

altres := simplify(alt) assuming rho>0:

lprint(%);

-(1/3)*exp(2*rho)*((Pi^2*rho+rho^3-Pi^2-3*rho^2)*exp(2*rho)+Pi^2*rho+rho^3+Pi^2+3*rho^2)/((exp(2*rho)-1)*(-exp(4*rho)+2*exp(2*rho)-1))

eval(altres, rho=1.2);

                         0.07643822463

[edit] In Maple 2019.1 the result attains for int even with method=ftoc, and :-limit also handles the latter computation.

Why the need to post this in a whole new Question thread? It simply duplicates this earlier topic, and senselessly splits the responses. (And you were provided a few robust and fast ways to compute a floating-point result in Answers in that thread.)

In your definition of operator L you have just speed and not speed(t). But you subsequently redefined speed as an operator. So you have confused expressions and operators.

You may have intended something like,
   L := proc(b) local t; int(speed(t), t = 0 .. b); end proc;

Do you think that symbolic int will be able to handle all your examples or r, for symbolic upper bound b? Why not stick with floating-point approximation as in your previous example?

What are you planning to do when the symbolic integration takes a very long time? Or when the equation involving the symbolic integration result cannot be solved explicitly for name b? Or when -- for nonnumeric upper bound b - the symbolic integration with method=ftoc runs amok while method=elliptic produces a result with special function calls that evaluates more slowly?

What are you really trying to accomplish with this entirely symbolic approach?

In the following attachment I illustrate some of the issues with your approach, and once again demonstrate a fast root-finding approach.

more_sc.mw