If you right-click on a Slider then one of the choices in the drop-menu is "Edit Value Changed Code".

That is the code that will be executed whenever the Slider's position is changed manually, by sliding it with the mouse.

In the following attachment, I have made this be that code.

a := Pi/DocumentTools:-GetProperty("Slider0", ':-value');

DocumentTools:-SetProperty("TextArea0", ':-value', a);

When the mouse slider is moved manually then this code is executed. It does two things: it assigns Pi/(the new value) to the name a, and it writes the assigned value of a to another component that I'd inserted (a TextArea component).

CreatingSlider_ac_ac.mw

You can adjust that code as you see fit. You could have it assign to a, but not write to the TextArea component. Or you could use the value to write to the TextArea component without assigning to (or using) a separate variable such as a.

Another useful approach can be to have the component's action-code be a call to a user-defined procedure which you set up outside the component. But for now, perhaps it's best to focus on getting the basics of the control flow working.

note. I suggest that you refer to the identity of components as strings (here, "Slider0" and "TextArea0") as strings using double-quotes, not as names. I also prefer GetProperty/SetProperty over Do.

remark: in your original attachment you had  sin*(a) which is a multiplication, not a call to the sin command. I suppose that is an accidental syntax mistake.

You could look (again) at this prior Post.

note. I don't really understand why some people seem to prefer a graph that might not encapsulate at least as much detail as the dismantle command provides.

I also don't think that the more convenient layout for such a graph is one which splits each level horizontally.

restart;

ig := L*(1 - a^3/r^3)^(-1/2)/r:

eq := u = 1 - a^3/r^3:
IntegrationTools:-Change(Int(ig, r), eq, u);

      Int(-1/3*L/u^(1/2)/(u-1),u)

sol := eval(value(%), eq);

    2/3*L*arctanh((1-a^3/r^3)^(1/2))

diff(sol, r) - ig;

                    0

I used what seemed a reasonable candidate for a change of variables. I get the same final result (with different intermediates, of course) using u=a^3/r^3 or u=1/r^3 instead.

This seems to be a consequence of the 2D output typesetting in extended mode.

It doesn't happen for me if I first set (in a separate execution group from a restart),

   interface(typesetting=standard):

If you have a procedure that evaluates v__c(t) for any given numeric value of t, then there is no need for using point-probes (and I think that doing so in that case would be a relatively poorer approach, on several different grounds).

note: even in the less common scenario that the function for v__c(t) is not explicitly available (and, say, the original curve is obtained using the implicitplot command or similar), numeric rootfinding should still be possible for each known t-value.

Here is an example, using an invented operator for v__c(t).

plotting-ilines.mw

If you have only an expression for v__c, rather than an operator (procedure) then show us, and the adjustment should be straightforward.

The following considerations might be obvious to some people, but I'll spell them out anyway. I consider these advantages for someone learning Maple:
1) The solution is programmatic. After addition of additional t-value points, or a change to the definition of the plotted "function", the plotting code can be re-executed directly.
2) The various pieces (text-plots, dashed lines, etc) are on separate code lines for clarity, and each could be easily removed, adjusted, etc.

Shorter solutions are possible, although very terse approaches (eg. via more functional programming) are less legible and more difficult for the beginner to adjust.

I didn't put in cross-symbols at the intersection points. That would be a straightforward addition.

You mentioned linear regression in a few places. Perhaps you want something like these:

regr_3d2d.mw

pts:= Matrix([[19.8,12, 1.62],[24.7,14, 1.2],
                   [26, 16, 1.25],[35.1,20, 0.84],
                   [37.8,20.83,0.74],[10.8,9, 3.98],
                   [16.1,12, 2.46],[38.3,18, 0.52],
                   [24.5,16, 1.42],[15.8,11, 2.35],
                   [28.2,17.8, 1.19],[56.8,27, 0.37],
                   [25.4,17, 1.34],[29.3,18.1,1.12]]):

F3d:=Statistics:-LinearFit(a*x+b*y, pts, [x,y]);

       F3d := -0.210960256326733 x + 0.440339719466169 y

plots:-display(
  plots:-pointplot3d(pts,color=red,
                     symbol=solidsphere,symbolsize=12),
  plot3d(F3d,
         x=min(pts[..,1])..max(pts[..,1]),
         y=min(pts[..,2])..max(pts[..,2]),
         color=gray,style=surface,transparency=0.1),
  labels=[x,y,""], lightmodel=none, axes=box);

F2d:=Statistics:-LinearFit(a*x, pts[..,[1,2]], x);

                   F2d := 0.560023063311019 x

plots:-display(
  plot(pts[..,[1,2]],style=point),
  plot(F2d,
       x=min(pts[..,1])..max(pts[..,1])),
  labels=[x,y], axes=box);

For the explicit solution, my Maple 2021.1 can get the following,

restart;
kernelopts(version);

   Maple 2021.1, X86 64 LINUX, May 19 2021, Build ID 1539851

ode := diff(y(x),x)-y(x) = x*y(x)^(1/2):
ic := y(0)=4:
maple_sol_e := dsolve([ode,ic], 'explicit'):

odetest(factor(maple_sol_e), [ode,ic]) assuming real;

               [0, 0]

For the implicit solution, I wonder whether odetest might be utilized twice (bootstrapped)!?.

Your code is set up to only ever execute the Bez:-Click procedure, upon clicking. And that procedure is only set up to add the current clicked point.

What you want, I think, is to have the Click code call procedures which appropriately add or remove a point, according to the state of the checkboxes. You  can do that in two ways, as conditonal code in the Click procedure:
1) have Click examine the values of the checkboxes, and dispatch according to procedures which add/remove the current clicked point.
2) have Click examine a module local which stores the current mode or operation (adding, or removing), and dispatch accordingly.

Also, if you select/toggle-on either of the checkboxes then you'd want the other unselected/toggled-off. Instead of putting in code to manage all that, it's simpler to replace the two checkboxes with a pair of radio-buttons in the same "group". That way the GUI automagically toggles the other off when either is toggled on. (That's the main distinction of of radio buttons versus checkboxes.)

The modification in the attechment takes route 1), and examines the values of the radio buttons in the conditonal check. The way I have it, there is no action code directly inside the radio buttons.

An alternative to the conditional checks on the values of the radio buttons is to have a new module local which stores the running state/purpose, and do the conditional checks on that local instead. Then you could have the action code of those radio buttons set the value of that local appropriately. I did not do it that way, but both ways can work.

Also, I changed the reset checkbox into a button.

I also added a line which (I hope) will make the Plot1 component be set into a state where mouse manipulation actions are click/click-drag instead of point-probe/etc. Without that your original worksheet was re-opening for me with the manipulator in the wrong state.

sketch_ac.mw

(I used Maple 2015.2 for the changes.)

[edit] If your collection of checkboxes/radiobuttons has only two members, reflecting a single boolean condition, than another alternative is to use just a single toggle-button. (You could even toggle its caption between "add" and "remove".)

Maple is a case-sensitive language, and the command you were trying to utilize is spelled with, all in lowercase.

You accidentally used the capitalized name With.

Note that you can also call the GetProperty command by its fully qualified name. See attached.

CreatingSlider_ac.mw

Most "new" user-level Library commands (created since around 2000) have so-called Camel case spelling, but there are many much older commands that have purely lowercase spelling.

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.