There are no real roots, but fsolve will find a complex root if you ask it to:

fsolve(P1, x, complex);

             0.02825145398 - 3.236871625*I

The issue is not that the for loop doesn't recognize the alias but rather that the aliases, declared as a[1], ..., a[4], don't recognize a[i] even if i equals 1, 2, 3, or 4.

The following two paragraphs from the help page ?alias, particularly the first paragraph, explain your situation:

• Because aliases are resolved at the time of parsing the original input, they substitute literally, without regard to values of variables and expressions.  For example, alias(a[1]=exp(1)) followed by evalf(a[1]) will replace a[1] with exp(1) to give the result 2.718281828, but evalf(a[i]) will not substitute a[i] for its alias even when i=1.  This is because a[i] does not literally match a[1].
   
• Aliases defined inside a procedure or other compound statement are not effective for resolving input matches in the body of that statement.  This is the case because the current statement is parsed in its entirety before the alias command is evaluated.

I think that the command PDEtools:-declare would be more appropriate than alias for this.

The command Grid:-Interrupt can be used for this. See ?Grid,Interrupt.

There's no predefined button for this. I suppose that you could make such a button, but it hardly seems worth the effort to me.

r:= fsolve(P, lambda= -1..3.2);
                        r := 1.376880264

d:= ilog10(op(1,r));
                             d := 9

evalf(eval~(P, lambda=~ [r, r-10.^(-d), r+10.^d]));
           [        -9        -10                 9]
           [-1.28 10  , 4.0 10   , -1.666081101 10 ]

We see that over the smallest possible interval containing the root at the given precision, the function switches signs.

@binbagsss You wrote:

•  I will need to define an alias

One never needs to define an alias. You can use direct assignment instead, as long as you don't use the same names on both left and right sides of the assignment operator. The only potential benefit of an alias (in this situation) is the way that it can simplify the output. However, I think that that simplified output is causing you some confusion. So, I think that for the time being you shouldn't use alias.

An example of potentially confusing aliased output is D(V). You've aliased V to V(h(x)). So does D(V) then mean D(V(h(x)))? An experienced user probably realizes that this latter expression is pretty much nonsense, and thus knows that that is not what was meant. Thus they realize that the V in D(V) is just plain, original V. 

So what does D(V) mean? It considers V to be a univariate functional operator and is expressing the operator form of V's derivative with respect to its unnamed variable. Some more-explicit examples should help: 

D(sin) returns cos.
D(sin(x)) is nonsense, because sin(x) is an expression, not an operator.
D(sin)(x) returns cos(x).
D(sin)(0) returns 1.
diff(sin, x) is nonsense, because sin is an operator, not an expression depending on x.
diff(sin(x), x) returns cos(x).
diff(sin(1), x) returns 0 because sin(1) is constant with respect to x.
diff(sin(1), 1) is an error, because 1 is not a variable.
D(sin)(1) returns cos(1).

The error message that you show is particularly common with boundary-layer BVPs. Unlike most error messages, it is not a result of a programming error, but represents something inherent to the structure of the BVP. Often it means that there are multiple solutions. You have parameters br, k1, and lambda. (You also have parameter blt as a "fake infinity", but, for the moment, I don't want to consider that to be a changeable parameter.) The way around the error is to use approxsoln, as mentioned by @dharr . The first step towards doing that is to experiment with varying the parameters (to "reasonable"^[*1] values) until you find values for them for which you don't get an error. Then we can gradually and contuously shift them to the parameter values that you want with each step using the previous step's result as its approxsoln. If you can find the values for the first step, I'll help with the rest.

[*1] Setting all parameters to 0 would likely converge without error, but that's probably not reasonable.

The key to an efficient solution procedure is to solve the equation symbolically (with solve) just once, and then construct all subsequent numeric solutions from that. Like this:

eq:= %abs[i](%a*x + %b) + %abs[j](%c*x + %d) - %t*x^2 + %m*x - %n = 0;

X:= subsindets(
    {seq}(
        seq(solve(eval(eq, %abs= [x-> x, x-> -x]), x), i= 1..2), 
        j= 1..2
    ),
    anything^(1/2),
    s-> %sqrt(op(1,s))
);

soln2:= subs(
    _X= X, [%a, %b, %c, %d, %t, %m, %n]=~ [a, b, c, d, t, m, n],
    (
        a::integer, b::integer, c::integer, d::integer,
        t::integer, m::integer, n::integer
    )-> 
        (X-> if nops(X)=6 then [[_rest], X] else fi)(
            select(type, value(_X), integer), args
        )
):

Sols:= CodeTools:-Usage((soln2@op)~(convert(L, listlist)));
memory used=29.38MiB, alloc change=-4.00MiB, 
cpu time=360.00ms, real time=334.00ms, gc time=78.12ms

     [[[5, 4, 3, 7, 1, 1, 1], {-4, -3, -2, -1, 1, 10}], 
         ...40 other solutions elided... 
     ]

I'm curious about something: Your equation can obviously have up to 8 solutions. Why are you only interested in 6?

Here is an Answer to your explicit Question about map: The command map replaces only a single function argument (although not necessarily the first argument) with values from a container (vector, list, set, etc.). To do the equivalent thing with multiple arguments simultaneously, use the elementwise operator ~. In your particular case, you could do

(tgf@op)~(convert(L, listlist))

where L is a Matrix or 2D Array. The following also do it:

(tgf@seq)~(convert(L, listlist))
map(tgf@op, convert(L, listlist))

and many other variations are also possible.

However, if your primary concern is reducing time, a change along these lines is insignificant. The time for operating the looping mechanism (whether it be for, seq, map, ~, etc.) too small to even be measured; the vast, vast majority of the time is used by solve. But you don't need to use solve. I gather from your worksheet that you're interested in finding integer 7-tuples (a, b, c, d, t, m, n) for which the equation abs(a*x + b) + abs(c*x + d) - t*x^2 + m*x - n = 0 has 6 integer solutions for x and then listing those solutions. Is that correct? If so, it can be done much more easily than by using solve, fsolve, or any other real- or complex-valued root-finding technique. I'll do it in a separate Answer.

First, a note on terminology: An integral equation is an equation that contains an unknown function inside an integral. What you have is just an integral, which is much simpler than an integral equation.

You have used Sum instead of sum, which expresses the sum in inert form. That is, the sum is shown in Sigma notation (with large uppercase Greek sigma), even though in this case it's trivial to expand the sum to its terms. There's no problem with using an inert form; indeed, it makes the displayed expression much more readable. The presence of inert forms is indicated by a gray (rather than blue) character (or characters) in the prettyprinted display. In this case, the Sigma is gray. Likewise, Int can be used as an inert form of int.^[*1] That wouldn't make much difference in this case. 

Kitonum's Answer replaces Sum with add. This can be done (and often should be done) in any case where the sum has a specific finite number of terms. However, you lose the benefit of the prettyprinted display. You also lose the option of the sum being simplified symbolically via a summation rule (that doesn't apply in this specific case).

The command value can be used to convert inert forms to their non-inert counterparts. So, in this case, you'd use value(eq1).

[*1] Don't assume that every command has an inert form obtained by capitalizing it. The commands for which this is true are diff, eval, int, limit, product, and sum. An inert form of any command foo (including those already listed) is %foo.

Try this link: Maple Learn

The GUI (user interface) is completely different than any of those offered by regular Maple, but I think that the "kernel" (mathematical engine) is the same.

Like this:

restart:
f1:= (x,y,z)-> x*y*z:
f2:= (x,y)-> x+y:
(x,y,z):= (2,3,4):
Grid:-Run(0, f1, [x,y,z], set= {f1}, assignto= 'r1'):
Grid:-Run(1, f2, [x,y], set= {f2}, assignto= 'r2', wait):

r1, r2;
                             24, 5

As you probably realize, the wait is not necessary if you have other work that could be performed asynchronously before r2 becomes available.

Use m &^ e mod n.

The reason that the problem occurs is the order of operations: In m^e mod n, the m^e is computed (or at least an attempt to compute it is made) before that number is passed to mod. But m &^ e is returned as an unevaluated function call `&^`(m, e), and that is exactly what gets passed to mod.

Here's my rewrite of GraphTheory:-UnderlyingGraph:

Underlying:= proc(G::GRAPHLN) 
uses GT= GraphTheory;
local
    V:= GT:-Vertices(G),
    Vi:= table(V =~ [$1..nops(V)]), 
    W:= subs(
        _W= (W-> W+W^+)(GT:-WeightMatrix(G)), 
        (u,v)-> `if`(nargs=1, _W[Vi[u]$2]/2, _W[Vi[u],Vi[v]])
    ),
    e
;
    GT:-Graph(V, {seq}([e, W(e[])], e= (`{}`@op)~(GT:-Edges(G))))
end proc
:

In the interest of time, I've omitted some of the bells & whistles of the original procedure, focusing instead on precisely the features that you implied that you needed.

I am investigating the bug in the original procedure.

Your worksheet shows a 1st-order ODE. Thus dsolve will only use one boundary condition. You said that A is a constant of integration. Well, where is the original 2nd-order ODE that produced that constant? That's what you should pass to dsolve, along with both boundary conditions.

You wrote:

• [I]t seems like the numerical solver cannot solve this type of nonlinear ODE.

It's not that it cannot solve it; it's simply that it chooses not to solve it unless you provide further information that clarifies an ambiguity. Whichever branch of the ambiguity you choose, the numerical solver can very easily handle it. Your ODE is

y' + (y')^2 = 0.

Trivial algebra (which can be done with the solve command if you wish) shows that that ODE is equivalent to

y' = 0  or  y' = -1.

You need to pick one of those choices before passing it to dsolve(..., numeric).

You'll get the same error in any case where the ODE cannot be uniquely solved (algebraically, not as a differential equation) for its highest-order derivative. As long as that can be done, the numeric solvers make no distinction between linear and nonlinear ODEs. However, since your stated interest is nonlinear, it should be pointed out that in this particular, trivial case, once you clarify the ambiguity, the ODE becomes linear.