Your original object was created as an operator (a kind of procedure) whose body contained the active summation using the sum command in 2D Input.

As mentioned, you can use the Sum command instead to get an inert summation which will not produce the Bessel result when the procedure is invoked. If you want inert summation in 2D Input then you can use the command-completion template for Sum. You can get this by invoking (I use the Escape key) command-completion after you have typed in just the letters S u m while in 2D Input mode, and selecting from the popup menu.

You can also use D the functional differentiator and obtain D(X) as a new operator. You could furthermore call that at a point x, also as D(X)(x). That is another (slightly better here, IMO) was that as you had it with the 2D Input form of diff(X(x), x) .

And, naturally, you can apply the value command to turn the inert summation expressions into their Bessel results.

I've put all this in the attached Document:  bessel_ac.mw

I'll mention that there is also an inert differentiator Diff, as in Diff(X(x), x) , which also has a command-completion template for 2D Input.

What about,

ans1 := [alpha[3, 7], alpha[3, 8], alpha[3, 9]]:

map[2](op, 1, ans1);

            [3, 3, 3]

map[2](op, 2, ans1);

            [7, 8, 9]

Or were you looking to form both with a single call? For example,

ans2 := [alpha[3,7], alpha[3,8], alpha[3,9],
         alpha[2,2], alpha[7,19]]:

(A,B) := map(op~,[1,2],ans2)[];

     A, B := [3, 3, 3, 2, 7], [7, 8, 9, 2, 19]

A;

               [3, 3, 3, 2, 7]

B;

               [7, 8, 9, 2, 19]

Your code has this line, which is invalid due to the recursive assignment of the name e in terms that involve function calls to itself. As written, it does not make sense.

e := (beta*(1-u[1])*s(t)*sigma[2]*e(t)+sigma[1]*i[t])/w[3];                         
Error, recursive assignment

There is some similar mixup going on with i and i(t), and in one place you also have i[t] with square brackets.

And you also use these names in max calls that appear in the RHSs.

It's a muddle.

What meaning did you hope for these statements to have?

If I understand it properly then you want to be able to select some group of line segments (in an existing, already displayed plot) so that they are all highlighted together, by performing a single left-click with the mouse pointer.

But you also want to be able to construct these individually using the plottools:-line command. Have I got that right?

Each line segment is formed as its own CURVES plotting substructure. You can group these together by combining all their data values into a single CURVES structure -- yet separated by Float(undefined) values. For example, lineseg_group.mw . You could modify that to retain other properties of the curves, but the end "group" of segments would have to share a single color, linestyle, etc.

There are several other ways to programmatically construct such a group of line segments. You could use the plot command on a list of points that you split up front. That might make it more convenient to set the color, style, etc. For example, lineseg_group_2.mw .

Apologies, if I've misunderstood the goal. If I recall correctly, the GUI will highlight (all of) only a single CURVES structure at once, when left-click selected in an exisiting, displayed 2D plot.

Carl's suggestion to apply simplify to the integral does work here, but his supposition that the cause of the problem is the piecewise (and also of why simplify fixes it) is mistaken.

The problem is due to the floating-point exponent (0.99 in the denominator, ie. a power of -0.99), and not because of the piecewise form.

You can get rid of that problematic float exponent in several ways -- one of which happens to be as a side-effect of applying simplify. Indeed, using simplify will even work if applied to the integrand directly, ie. it does not need to know the integration bounds and resolve the piecewise branches.

There are, in consequence, several other ways to complete the floating-point numeric integration successfully, since there are other ways to obtain an equivalent integrand without that floating-point exponent. They work, even though they still contain a similar kind of piecewise (except that the particular exponent is no longer a float).

NumericInt_acc.mw

Up around 9 lines from the bottom of that file you should see a text line like,

    map(x->assign(SF[x],cat(`SF/`,x)),

Try changing it to,

    map(x->assign('SF'[x],cat(`SF/`,x)),

where the edit is the addition of two right single-quotes (forward quotes).

You can wrap your calls to ModularSquareRoot inside try...catch to trap the error (and then proceed how you prefer.)

For example,

  try
     ModularSquareRoot( blah, blech );
  catch:
     FAIL;
  end try;

Or you could put that into a convenient and reusable procedure, ie.

  TrapMsqrt := procedure( )
    try
       ModularSquareRoot( args );
    catch:
       FAIL;
    end try;
  end proc:

  TrapMsqrt( example1 );
  TrapMsqrt( example2 );

There are several variations on this theme. You could add basic argument checking to the wrapping procedure. You could get fancy and catch some specific kinds of errors (eg, related to invalid input, etc) and rethrow them. You could turn errors (that related to the failed conditions) into an informative message -- which could be optionally emitted using Warning or userinfo. And so on.

The problematic floating-point computation is encountering roundoff error, due to the forced low working precision induced by the call,
    evalf(..., 5)

Do not lower working precision just to produce a numeric formatting effect. That is very much not a good way to do numeric computation in Maple.

It is usually inadvisable to lower working precision down to 5, for almost all nontrivial computations.

If you really want your numeric results rounded to 5 significant places then assign the computed results to some name, and then apply something like evalf[5] to that. Then display or assign that, as your choice.

Or just set the displayprecision (using the interface command or Tools/Options in the GUI), although in some versions there is difference between trailing digits (after the decimal) and the number of displayed digits. I do not think that the GUI always does it usefully.

Note. The syntax evalf(...,5) is inferior to the syntax evalf[5](...) , since the former is awkward if the expression is itself an expression sequence. I am not suggesting that you simply replace one with the other as the solution to your problem. You should not wrap either around your computation.

I don't have much time today to look at this, sorry, but judging only from the followup comment made to Tom, I'd like to ask this:

    In order to reduce the memory cost couldn't procedure P admit
    (premade) Matrix X as an additional argument and then act
    on it "inplace"?

The procedure P could optionally call ArrayTools:-Fill, if it was strictly required to "zero out" X at the start of each call.

The higher level code which called P could be done with two statements, in the case that separate result Matrices were needed conconcurrently. Ie,  Y:=Matrix(..) and then P(...,Y).

Note the for the task of repeatedly calling P(...,X) many times there is not just the possible savings in memory space cost. There can also be considerable time cost savings since garbage collection (memory management overhead) costs to clean up all the "discarded, unreferenced, prior" separate returned Matrices is alleviated. It takes time to do garbage collection.

This is a stock technique for improving performance. For example, an optional "inplace-container" procedure-parameter was added to Statistics:-Sample for these same reasons. That command can be passed an extra rtable argument, into which the sample is written.

Look at how your procedure assigns to uvp at the end of its loop.

Your procedure did it differently than you had it in the top-level code, ie. a list of equations like name=number.

I didn't search for other discrepencies in the uncommented procedure.

faq_ac.mw

The error message seems clear: you passed Data to subs (and not as the last argument, the expression to be changed) but it is not an equation (or a sequence or list of set of equations).

Perhaps you have mistakenly tried to use the mere name Data for this subs call, even though Data has not actually been assigned anything? Or perhaps(?) Data was assigned a table?

Why not upload and attach a worksheet that reproduces the problem?

You haven't told us whether you're trying to do a global or local search.

[edit. You didn not clearly explain just why the varying results are problematic for you. One reasonable interpretation -- in the absence of an explanation -- is that the central issue is that sometimes the results are suboptimal, and that you are looking for a best result -- or consistently very close to it. If that is not the central issue then you really ought to explain the difficulty more clearly.]

You could trying adjusting the options (especially those which the DirectSearch Help pages describe as affecting reliability and accuracy).  See especially the options checkexit and timelimit, and if you choose to use its GlobalSearch command then also the number option.

Read the relevant DirectSearch help pages carefully. The options are there because, as a general rule, global optimization of difficult problems can produce a solution whose quality depends on how hard and for how long you make it work. That's not specific to the DirectSearch package or Maple -- it's true of numeric global optimization in general.

Another possibility is to adjust some code I once wrote for automating repeated calls to the DataFit command of DirectSearch -- although you may well find that for using its GlobalOptima command the number option suffice to produce similar or better benefit.

restart;

kernelopts(version);

    Maple 2020.0, X86 64 LINUX, Mar 4 2020, Build ID 1455132

ans := convert( int(arccos(x)*arcsin(x),x), arcsin );

                    /                       (1/2)\                     
               1    |              /  2    \     |            2        
        ans := - Pi \x arcsin(x) + \-x  + 1/     / - arcsin(x)  x + 2 x
               2                                                       

                                  (1/2)
                         /  2    \     
           - 2 arcsin(x) \-x  + 1/     


simplify(convert( diff(ans,x) - arccos(x)*arcsin(x), ln) );

                               0

Executing a restart will cause the Startup Code to be re-executed.

Perhaps you worksheet contains a restart statement.

You could also use plots:-listplot for this. For example, using your definition:

plots:-listplot([seq(b(i),i=1..10)],
                color=red);

plots:-listplot([seq(b(i),i=1..10)],
                color=red,style=point,symbol=solidcircle);

You could, of course change the style and size of those plots.

See also here, where you could divide by the suitable power of 2.