You haven't shown us how you were testing a pair of expressions against each other.

If you were using evalb then you should read its Help page carefully.

Here are a couple of approaches,

restart;

expr1 := -a*b + a*c:
expr2 := a*(c-b):

is(expr1-expr2=0);

           true

evalb(simplify(expr1-expr2=0));

           true

eq1 := expr1 = expr2;

    eq1 := -a b + a c = a (c - b)

is((rhs-lhs)(eq1)=0);

           true

evalb(simplify((rhs-lhs)(eq1))=0);

           true

# note the following

evalb(expr1=expr2);

           false

evalb(eq1);

           false

If your were doing something else, or had additional examples, then you should show that here explicitly.

This is not really satisfactory, but I'll mention it nonetheless,

restart;
ode:=diff(y(x),x) = 2*(2*y(x)-x)/(x+y(x)):
ic:=y(0)=2:

combine(dsolve([ode,ic],'implicit')) assuming x>0, y(x)>2*x;

     ln(2*(y(x)-x)^2/(y(x)-2*x)^3) = 0

combine(dsolve([ode,ic],'implicit'), symbolic) assuming x>0;

     ln(2*(y(x)-x)^2/(y(x)-2*x)^3) = 0

Your essential problem is not due to differences between map and elementwise ~ .

It is due to the difference between a matrix (as implemented via arrays) and a Matrix.

Your code assigns a matrix to outCx, since that is what linalg:-multiply returned, for Ts_sksul, XCin each a Matrix.

Your code assigns a 3x1 Matrix to outCy, since Ts_sksul, XCin are each a Matrix and that's what `.` returned (with appropriate dimensions).

You got confused about the problem because your examples differed in more that a single way. You guessed the wrong difference, as the cause of the discrepancy.

See the attachment for revisions, etc.

Q20210612_ac.mw

You should not be using linalg:-multiply, since (amongst other reasons) that is deprecated. Use `.` or LinearAlgebra's Multiply command instead.

The error message may be indicating that the name t has been previously assigned a value. Is that the case?

What happens if you do 

   t:='t';

right before calling NonlinearFit?

It would be better if you could upload and attach a worksheet that reproduces the problem. (Green up-arrow in the Mapleprimes editor.) Then we could tell whether the other arguments being passed were also valid, etc.

It might work better using Sum instead of sum. But an actual worksheet would be better.

If I understand correctly what you are after, here is one way.

[edit] I have added some alternatives in my comments under your Reply below. That includes plots:-display(seq(...),insequence) as well as use of Explore.[end edit]

Notice that the number of frames (frames option) and the range 1..nops(L) passed to the animate command both match the number of entries in the list L. Notice also the trunc call, so that the list L is indexed by integers instead of the passed floats.

restart;

F := theta -> plot(sin(x*theta), x=0..2*Pi,
                   caption=typeset("theta =",sprintf("%.2f",theta))
                   ):

L := [seq(sqrt(i),i=1..20)]:

plots:-animate(F, [L[trunc(i)]], i=1..nops(L),
               paraminfo=true,
               frames=nops(L));

discretelist_anim.mw

Of course you can comment out the caption option of the plotting command, or alter how the value gets used (you don't need to make it a float, but I dislike jitter as the caption length varies...).  You could also pass paraminfo=false to the animate command. I set both those up so that you could see the effect.

It's often difficult to pinpoint the precise cause of a problem without having code that reproduces that problem. And you haven't supplied that (or even the call-stack in the debugger session).

In which case perhaps trying alternatives might be more straightforward than guessing back and forth as to the underlying cause.

You might try these instead (in your procedure):

is(tmp_1);

is(simplify(tmp_1));

is((rhs-lhs)(tmp_1)=0);

is(simplify((rhs-lhs)(tmp_1))=0);

evalb(simplify((rhs-lhs)(tmp_1)=0));

Without knowing your general case, I might prefer the 4th or 3rd of those.

By the way, if you are trying to establish a mathematical equivalence then evalb(simplify(...=...)) is not best in general (even if it works for your example, including at the top level). That is because, in general, two expressions from each side of an equation that are mathematically equivalent might be represented in separate classes that don't produce a exactly matching simplifed/canonical form (including under simplify). This might not be the case in your given example, but I offer it as a general consideration.

This attachment has two ways to handle your followup example, which you gave as,

   fcty := RootOf(T, r);
   polarplot(fcty);

mpprime_acc.mw

[edit] I've replaced my earlier attachment and removed the method=_d01ajc suggested by Preben for your original issue, which works well in Maple 2020.2 but not Maple 2021.1 due to a bug. I have replaced that method specification by use of the operator-form calling sequence (using unapply), as an alternate mechanism for prevent discontinuity checks. This works quickly in both my Maple 2020.2 and 2021.1.

By the way, it looks like you're still using Maple 2020.0, and the update to point-release 2020.2 is a free download.

The animate command is part of the plots package.

It won't work if you call the only plain name animate without having loaded the plots package (or that command).

It works for me if instead I call it as plots:-animate, or plots[animate] in very old versions. Ie,
   F:=...
   plots:-animate(...)

It works for me if I first load that command from the plots package. Ie,
   with(plots,animate):
   F:=...
   animate(...);

It works for me if I first load the whole plots package. Ie,
   with(plots):
   F:=...
   animate(...);

It's not quite clear precisely how you wish to extend your given example.

But this might give you some hints, as two ways to regenerate your given example, along with a simple extension.

restart;
my_alph := [ "A1", "B1", "C1", "D1", "E1", "F1", "G1", "H1", "I1",
             "J1", "K1", "L1", "M1", "N1", "O1", "P1", "Q1", "R1",
             "S1", "T1", "U1", "V1", "W1", "X1", "Y1", "Z1", "AA1",
             "AB1", "AC1", "AD1", "AE1", "AF1", "AG1", "AH1", "AI1",
             "AJ1", "AK1", "AL1", "AM1", "AN1", "AO1", "AP1", "AQ1",
             "AR1", "AS1", "AT1", "AU1", "AV1", "AW1", "AX1", "AY1",
             "AZ1", "BA1", "BB1", "BC1", "BD1", "BE1", "BF1", "BG1",
             "BH1", "BI1", "BJ1", "BK1", "BL1", "BM1", "BN1", "BO1",
             "BP1", "BQ1", "BR1", "BS1", "BT1", "BU1", "BV1", "BW1",
             "BX1", "BY1", "BZ1" ]:

AZ := StringTools:-Explode(StringTools:-Iota("A" .. "Z")):

ans1 := [map(cat,AZ,"1")[],
         map[2](cat,"A",AZ,"1")[],
         map[2](cat,"B",AZ,"1")[]]:

evalb(ans1=my_alph); # they are the same

               true

ans2 := [seq(map[2](cat,p,AZ,"1")[], p=["","A","B"])]:

evalb(ans2=my_alph); # they are the same

               true

#
# And now one way to extend it. (output omitted...)
#
[seq(map[2](cat,p,AZ,"1")[], p=["",AZ[1..7][]])];

Do you need to know how to get a generated list whose desired number of entries is known beforehand, but might not be a multiple of 26? The math for that is not difficult, but I don't know whether you need that step. Would you want that number constructed from the ranges of values that Ql, Tl will take?

The last example above can be modified, say altering the p=["",AZ[1..7][]] portion to get additional entries or nesting.

In 2D Input mode, use the key-strokes y _ _0 ( ie. y underscore underscore 0 ) to enter a subscripted name for the initial value. (That keeps the variable distinct from the name y.)

In several places your document muddles up text, inlined 2D Math, and executable 2D Input.

Also, your sheet does quite a lot of cut&paste of values, but you could instead make it flow nicely in a programmatic manner. Ideally you should rarely if ever have to cut&paste previously computed values, since that is error prone, awkward to read, and does not allow recomputation if any parameter values are changed, etc.

See attachment, and check for mistakes(!).

Worksheet_1_ac.mw

Adjust to suit your own style, add back the removed commentary, etc.

Note that some of your original comments are incorrect. For example you had, "Now that we know that the half-life of the isotope is roughly 0.693147180559945 years..." but that is wrong. The half-life is given as 24360 years. The computed value 0.6931.. simply approximates ln(2). What you were solving at that part of the sheet is actually the value of the parameter k.

Member vv is correct, in that the Tabulate approach in Maple 2015 needs interface(typesetting=extended) or equivalent for the piecewise call to pretty-print as desired. In Maple 2017 the default was changed to extended.

Also, in your DocumentTools:-Layout approach the calls to Equation could simply be passed the (documented) typesetting=extended option. So both approaches can work even in Maple 2015.

See attached,

DT_piecewise_ac.mw

Your followup remark used the word "depends". And since that is what seems to really matter here, why not utilize the depends command?

Also, it seems more robust to remove the piecewises which depend upon x, rather that merely select those which happen to have identically t as one side of only some non-compound relation.

I added conditional t<0 or x[1]<0 to make it harder.

expr := piecewise(x[1](t)<0, -1, x[2](t)<1, 0, 1) + f(t)
        + piecewise(t<0, 0, t<1, 1, 0) + x(t)*piecewise(t<0, 1, t<1, 0, 1)
        + a*piecewise(t<0, 3, t<1, -1, 2)
        + a*piecewise(t<0 or x[1]<0, 3, t<1, -1, 2);

# testing whether the piecewises depend upon x
#
indets(expr,And(piecewise,
                satisfies(pw->not depends(pw,[x]))));

# testing only whether the conditionals of the piecewises depend upon x
#
indets(expr,And(piecewise,
                satisfies(pw->not ormap(depends, op~(1,PiecewiseTools:-ToList(pw)),[x]))));

# first of those, but in two separate steps...
indets(expr, piecewise);
remove(pw->depends(pw,[x]), %);

pw_depends.mw

This is not fast, since it has to decode the 2D Math contents.

But it can help in the case that the input code is in only 2D Math form. Ie, when the desired/queried-for code appears only in 2D Input but not also as plaintext.

This approach also happens to search the 1D Maple notation plaintext code, as well as conversions of input from 2D Math.

rough_mw_text_search.mw

Of course you'd need to adjust how ListDirectory is called, for your machine and directory locations. You could also make it more defensive, add bells & whistles, etc.

By the way, the Maple program code contents are not in a "binary format". The encoded portions are in a base64 encoding of Maple's .m dotm format. That is neither impossible to decode nor exceptionally strange, and in the attachment that aspect is all handled automatically by the WorksheetToMapleText command.

ps. On my Linux machine I use its grep utility to search files for plaintext strings. But 2D Math is a trickier situation.

The "Dragged" action code of a PlotComponent is called multiple times while the mouse-pointer is dragged around. (The frequency at which it gets called is not adequately documented.) But that is the main difference between the "Dragged" code and the "Drag end" code which is only executed once per drag, when dragging stops. The "Dragged" code allows you to get a kind of continuous effect, programmatically, as the mouse is dragged around the plot.

Here is a simple example, with comments.

ECPlot_dragged_example.mw

I prefer to make the relevant "action code" property of the Component be just a simple call to a procedure that I define elsewhere. That makes it easier to adjust the code. Eventually such code could be tidily hidden away inside, say, the Startup Code Region of the worksheet.

It's easy to make other fun applications. This second example uses the endx,endy pair as initial value for a phase-portrait of a 2D ode solution, using DEplot. As you drag the mouse-pointer around the resulting solution curve moves through the field-plot. Execute all the code in this attachment, then left-click&drag around the plot...
ECPlot_dragged_DEplot_example.mw
(This example is designed for simplicity, not efficiency. Otherwise I'd call dsolve once up front, and then odeplot in the action code.)

The .mws file from the Application Center loads in Maple 2017.3 with the definitions of id, eq1, and eq2 missing.

I retyped the three missing definitions, by reading the display rendered on the App Center. (Check for mistakes in my transcription.)

I also corrected the faulty calls to plots:-odeplot. (Even the display on the App Center page demonstrates those as being wrong.)

Download half-wave_full-wave_diode_rectifiers_ac_2017.mw

I will submit a bug report against that App Center item.