@acer I think that your disparagement in the ending paragraph of your Answer may be due to conflation of the name-forming quotes `...` and the empty-named function ``(...). Only the former can lead to inappropriate changes in typography, such as italics. Here is each applied to the OP's situation (assuming one wanted to directly input the expression as inert). Compare the 2D output of these:

1. `3`*(a - 1)  #3 becomes an italicized name.
2. 3*``(a - 1)  #produces desired output; a-1 remains type `+`.

The expand command will turn #2 back into what one would've had if `` weren't used in its input.

I think that the OP may want to deconstruct to an inert form an already-automatically-simplified expression. In that case she can use (assuming expr is an expanded polynomial such as 3*a - 3):

content(expr) * ``(primpart(expr))
or (same thing in a more-functional style)
(content * (``@primpart))(expr) 

Vote up.

I converted this from a Question to a Post yesterday. I only mention it so that it'll appear on the "Active Conversations" list. The conversion process seems to remove it from that list.

The default grid is [49,49], so your [200,200] is more than 16 times larger, so it likely takes more than 16 times the amount of time.

@NIMA112 In  your case, singularities occur along the lines in the A-B-plane where the arguments to your lns are 0. Specifically, those lines are B = 0, A = -B, and A = -100*B.

@NIMA112 I think that you've downloaded an older version of DirectSearch. Try this one:

https://www.maplesoft.com/Applications/Detail.aspx?id=101333

It's a shame that the Maple Applications Center returns the older version as the primary "hit" with barely a hint that there's a newer version. It's especially a shame considering that this is, IMO, the most useful third-party package ever written for Maple.

@Ritz11 That's a decent answer written from a non-language-specific functional-programming perspective. That is, there are no Maple-specific details other than precisely those copied verbatim from the original Question. So, was that written by ChatGPT or similar AI?

Here it is with some Maple details:

p:= 2*(x-2)^2*(x-1);
F:= factors(p);
seq[fold= (`*`, fun(F[1]))](fun(f[1])^f[2], f= F[2]);
 

@NIMA112 I suspect that the roots are found by trial-and-error. Making implicitplots (as I showed above) helps. Roots are where the red and green cross. You need to change the ranges of A and B. Many choices will show no roots. If you find an intersection, that gives you about 2 significant digits of A and B. You then use these as seed values to fsolve to refine to as many digits as you want (which doesn't always work). The plots are computationally intensive, taking about 2 minutes each.

@sand15 That's strange. I don't know what's happening there. If one were really interested, one could display all the results of the assignments leading up to the creation of the two equations and check where the numeric values in the two executions (2015 and 2023) begin to diverge.

Anyway, this implicitplot clearly shows the 2 roots that I proposed. And by adjusting the ranges appropriately, it'll show the 2 latest roots that @Axel Vogt found. (And it finds another root fairly close to Axel's [A= 37.6324, B= -0.356503].)

plots:-implicitplot(
    Re~(rel), A= -4..1, B= -1..2, 
    gridrefine= 3, crossingrefine= 3, color= [red, green]
);

@sand15 I had moved the OP's Digits:= 50 from where it originally appeared in the worksheet to immediately after the restart: Making that change in your version of the worksheet and re-executing your computation of the residuals using my posted numeric solution yields

eval(rel, {
    A = -2.7553365135418814642586082436429575890825402826031,
    B = -0.70285804987973303586180028708027467941012949957141
});
[-4.426*10^(-43) - 0.*I, 
-4.0506731414438437950164110646723220186973915791808*10^(-40) - 0.*I]

which seems sufficiently close to 0 to me.

@Joe Riel I also found those lines of code, and they clearly show why expand isn't idempotent in this case. The question to me is Shouldn't it be idempotent by design? That is why I only said that perhaps it was a shortcoming or bug. Making it idempotent would be easy.

Yes, I think that the defaults should be changed. Specifically, 

1. It's often difficult to appreciate the 3-dimensional nature of a plot without gridlines, though, unlike your example, I wouldn't necessarily include them on both the inner and outer surfaces unless they were differently colored (which IS fairly easy to do).
2. With the current defaults, the colors of the inner and outer surfaces are too similar to each other.

@rlopez Dr Lopez's suggestion can be given the full sign, primpart, sort treatment to put the results into your requested format, doing them all at once with this single command:

`[]`~(
    L,
    (sign*primpart@sort@lhs@Student:-VectorCalculus:-TangentPlane)~(
        (x - 1)^2 + (y - 3)^2 + (z - 5)^2 = 13^2, `<,>`~(L)
    ) =~ 0
);

I am suprised that this Student command doesn't check whether the specified point is actually on the specified surface. It'll happily return results for points that are not. (This is mentioned on its help page.)

@NIMA112 Why do you suggest this obscure numerical method that'll require much work to get coded into Maple? I'm not saying that it's not a good method for this problem---that I don't know. Do you have any reason to suspect that this method will work better than any of the numerous more-standard methods that are already coded?

@Art Kalb That's a good question, but I don't know the answer. It is perhaps a shortcoming or bug of expand.

@Laurenso Here is the version of the procedure with the on-the-sphere check included:

tangent_plane:= p-> local P:= <p>, R:= <1,3,5> - P;
    [p, `if`(R.R = 13^2, (sign*primpart@sort)(R.(<x,y,z> - P)) = 0, FAIL)]
: