You can parse the string to obtain a math expression for the MathContainer. Ie,

SetProperty("MathContainer0","expression",parse(GetProperty("TextArea0","value")));

Download MathContainerEntry_Doubt_ac.mw

Using the DocumentTools:-Tabulate command you can get an effect something like an animation, but with the Sample and Histogram generated on the fly. You may find it a bit easier than setting up a whole "App" with Embedded Components.

Adjust to taste.

histo_fun.mw

Have you tried relerr=10.0^(-x-7)  ?

Download PDFColorTitle_ac.mw

You may find this kind of step useful in construction of such things:

foo := chi^2;
sprintf("%a", Typesetting:-Typeset(Typesetting:-EV(foo)));

This is fast.

Download for_k=2_M=3_ac.mw

Download fsolve_Therm_units.mw

restart;

a:=[3,3,1,5,7,8,5,4,4,4,4,3,9];

          a := [3, 3, 1, 5, 7, 8, 5, 4, 4, 4, 4, 3, 9]

subsop(ListTools:-Search(4,a)=NULL,a);

              [3, 3, 1, 5, 7, 8, 5, 4, 4, 4, 3, 9]

Or, as a re-usable procedure,

R:=(N,A)->(NN->`if`(NN>0,subsop(NN=NULL,A),FAIL))(ListTools:-Search(N,A),A):

R(4, a);

              [3, 3, 1, 5, 7, 8, 5, 4, 4, 4, 3, 9]

R(14,a);

                              FAIL

Download rootsqu.mw

Be careful using Calculus1:-Roots with the numeric option, since you may have to supply a range for x in order to get all the roots. (Not this example, since the default range is x=-10..10 for the numeric option.)

Notice also that applying evalf to the exact, symbolic roots can incur roundoff error (in this example, using default precision not all the last digits are correct).

Inside the procedure there is a call to procname. That means the procedure calls itself there. It's not passing itself enough arguments to match its own expected number of parameters.

The call to procname is a recursive call. But Newton's method can be implemented quite simply with an iterative approach (which you mentioned as being part of the assignment), which is what your do-loop is attempting to accomplish.

So, why did you put a call to procname there? What did you hope to accomplish with it?

What version are you using? In my Maple 2018.0 I am seeing the prettyprinted infinity symbol in the Table.

Does it change if you set interface(typesetting=extended): ?

Oh, I see now that the Tabulate command has its own option for that. I'd forgotten that was there. It's there so that you don't have to change that interface setting globally in the worksheet (even if only temporarily).  So try it like so, while retaining your standard typesetting level for the worksheet,

    restart;
    a:=infinity;
    DocumentTools:-Tabulate([a], typesetting=extended):

Why are you using  P*(Q-q) in Fract1 and p*(Q-q) in Fract?

If you're going to try and use a functional programming approach then you might want to start off by building up the inner step(s) and examining the intermediate results. Or use the debugger and stopat...

Take a look at the results from isolve, for your original.

See if you can figure out whether this stands up (and I mean in terms of what it does, not just what it returns).

Fract1 := proc (P::posint, Q::posint)
    local p, q, t1, Z;
    t1 := [isolve({(P-p)*q-p*(Q-q) = 1},Z)];
    t1 := eval(t1, Z=0);
    `~`[`~`[`/`@op]](select(type,
                            map2(eval, [[p,q], [P,Q], [(P-p),(Q-q)]],
                                 t1),
                            [[posint$2]$3]))[][];
end proc;

[edit] Note the use of local name Z for the parameter introduced by isolve. That is there so that the procedure Fract1 doesn't break after side-computations like, say, solve({sin(Pi*n)=1},n,allsolutions) .

Are you trying to say that you want a new table with the entries from both?

If so then I'll let you inject that wherever you want it inside your procedure. You can ignore the fact that I made it return the two tables, and undo that.

Download help_table_ac.mw

You can specify both the from and the to units, for a temperature conversion.

convert(0.0, temperature, degC, kelvin);

                          273.1500000

That might handle your example at hand.

More broadly, it is a general problem of the units implementation (via multiplication) that a value of zero drops the unit, as a consequence of automatic simplification by the Maple kernel.

In case anyone feels like suggesting that units be re-implmented via objects, to avoid this issue with the quantity zero, I would say the following. It's harder than you might imagine. It's dead easy to code up the simple cases for it. But that's not the point. Having an object be treated by general Library code like an algebraic expression entails teaching it (ie. giving it static exports) to do many, many things. And it can turn out that many operations work nicely only if the object absorbs everything it touches, eg. the quantity with-the-unit has to get merged into the unit object, and so on down a rabbit hole. There is a possibility that someone could be really ingenious about it.

It's interesting that it produces your expected result with the strict inequality u>0 .

restart;
kernelopts(version);

    Maple 2018.0, X86 64 LINUX, Mar 9 2018, Build ID 1298750

with(Statistics):
C := RandomVariable(GammaDistribution(2, 2)):
f := unapply(CDF(C, t), t) assuming t > 0:

s := solve({f(t)=u, t>=0}, t) assuming u > 0, u <= 1;

        s := {t = -2 LambertW(-1, (-1 + u) exp(-1)) - 2}

plot(eval(t,s), u=0..0.95, labels=[u,t]);

solvething.mw

See the Help topic worksheet,documenting,2DMathShortcutKeys (or just search the Help for 2DMathShortcutKeys).