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).

It works for me using lists.

By the way, even if it did work for sets, it would not be best because the ordering of elements of sets is lexicographic, and they uniquify. So you could get an unintended color/expression pairing, depending on how the sets get ordered. And it's even possible (under assumptions, etc) that the set of expressions could end up with less entries than the set of color strings. It's better to use lists, if you have them only in the plotting call.

Download impl_examp.mw

If you can show it working in 1D input, but not in 2D input, then it's usually a good idea to upload the full set of code-to-reproduce as an attachment (green arrow in Mapleprimes editor).

You may have been using a toy expression just to illustrate a difficulty, but in case you're interested your can get smooth curves by doing explicit plots here, eg.

sol1 := [solve(evalc( Re(w)=2 ),y)];
sol2 := [solve(evalc( Im(w)=2 ),y)];
plots:-display(
 plot(sol1, x=-5..5, view=-5..5, color="Red"),
 plot(sol2, x=-5..5, view=-5..5, color="Blue")
);

Lastly, if you're using 2D Input then you can do yourself a favour by using the arrow notation like f:=z->z^2 for assigning the procedure/operator. I mean, don't do f(z):=z^2 to define the operator.

Your worksheet is a bit of a muddle, I'm afraid. Please see the attached which is an attempt at revision.

Let us know when you want to set the example's general formula based on radio buttons.

doubt2_MathContainer_ac.mw

If you use the name form in a general context then you should use it as  ':-value'  which is the unprotected global name. That protects against the situation that either your or the end-user has assigned to value at the current scope.

If you use "value" then that should not be a concern (supposing that SetProperty works properly).

Other than that, it doesn't really matter.

As an experiment, assign something like 2.1 to value, outside your components. Then test which of these work:

  value    "value"    ':-value'

Let me know if I've misunderstood or made a mistake.

Download abs_sort.mw

The default value for an entry of an rtable (Array, Vector, or Matrix) is zero.

Notice that you are using lprint.

There's not much benefit from rtable_elems returning (or lprint displaying) the indices that take on the default value.

There are a variety of ways.

And, if you have a list of lists (of the pairs of arguments) you can map or interleave.

[iquo,irem](p,q);

                    [iquo(p, q), irem(p, q)]

([iquo,irem]@op)([p,q]);

                    [iquo(p, q), irem(p, q)]

([iquo,irem]@op)~([[p,q],[s,t]]);

      [[iquo(p, q), irem(p, q)], [iquo(s, t), irem(s, t)]]

map([iquo,irem]@op, [[p,q],[s,t]]);

      [[iquo(p, q), irem(p, q)], [iquo(s, t), irem(s, t)]]

map(eval,[iquo(x,y),irem(x,y)],[x,y]=~[p,q]);

                    [iquo(p, q), irem(p, q)]

map(eval~,[iquo(x,y),irem(x,y)],map[2](`=`~,[x,y],[[p,q],[s,t]]));

      [[iquo(p, q), iquo(s, t)], [irem(p, q), irem(s, t)]]

It will run faster if the computation done by the objective function can run under the fast hardware double-precision evalhf interpreter.

One way to accomplish that is to remove SoS's global declarations, and instead have it accept those globals as extra parameters, and then call NLPSolve on an unevaluated function call that includes those (as well as the parameters) as arguments. I haven't done that.

Another, straightforward, way to get most of the same benefit is to create an inner procedure which is called by SoS under evalhf. By doing that I didn't have to change how you set up NLPSove to call SoS.

HN_fit_of_DMA_data_ss_proc_v5a_ac.mw

There are other ways to squeeze even better performance out of the objective procedure (adjust the loop code perhaps, use Compiler:-Compile, etc, none of which I've done), but making the bulk of the work be done under evalhf is one simple way to get a significant improvement.

A related, easy improvement comes from giving a hardware datatype to each of those data Vectors accessed by the objective. This slightly improves the benefit from the evalhf adjustment.
 HN_fit_of_DMA_data_ss_proc_v5a_ac2.mw 

You might find this interesting reading.

The revised objective evaluates quicker than does the original objective. So the benefit would also come into play if using an alternate optimizer such as the global optimizer from the DirectSearch add-on package. Global optimizers generally do many more objective evaluations, so in terms of absolute timing comparison the performance benefit would likely be greater. (I haven't been able to attain a better minimum using DirectSearch:-GlobalOptima and the same variable bounds, however. I also didn't examine the objective for possible convexity.)

If things get awkward when you assign a value to t, then don't do it.

Instead you can evaluate u at a numeric value for t, when you call plot.

This easier than having to repeatedly assign a value to t, and then unassign t, if you want to do multiple plot calls  (possibly for different t values) and plot3d calls.

In future, please either upload a worksheet (green button), or inline only 1D input and not the output. Also, please don't submit multiple posts of essentially the same problem.

restart;

l := 4: m := 1: n := 2:
k := 1/sqrt(-6*beta*l^2+24*beta*m*n):
w := alpha/(5*beta*sqrt(l^2-4*m*n)):
B[0] := -(1/25)*alpha*(5*l^3/(5*sqrt(l^2-4*m*n))
        -20*l*m*n/(5*sqrt(l^2-4*m*n))-l^2+2*m*n)
        *sqrt(-6*beta*l^2+24*beta*m*n)
        *(5*sqrt(l^2-4*m*n))/((l^2-4*m*n)^2*beta):
B[1] := -(12/5)*m*alpha*(5*l/(5*sqrt(l^2-4*m*n))-1)
        /sqrt(-6*beta*l^2+24*beta*m*n):
B[2] := -12*m^2*alpha/(sqrt(-6*beta*l^2+24*beta*m*n)
        *(5*sqrt(l^2-4*m*n))):
theta := sqrt(l^2-4*m*n):
xi[0] := 1:
F := -l/(2*m)-theta*tanh((1/2)*theta*(xi+xi[0]))/(2*m):
beta := -2:
alpha := -3:
xi := k*x-t*w:
u := B[0]+B[1]*F+B[2]*F*F;

plot3d(u, x = -30 .. .30, t = -30 .. .30);
plot( eval(u, t=0), x = -30 .. 30);

plot3d(u, x = -30 .. .30, t = -30 .. .30); # still works
plot( eval(u, t=1.5), x = -30 .. 30);

The reason it does not work is that add uses the global :-`+` and not the rebound `+` that is exported by the Tolerances package.

When you call with(Tolerances) the name `+` is rebound to the package export. But most Library code and (in this case) the kernel builtin add, still use the global :-`+`. 

Carl's Answer is saying that it would have worked if Tolerances also exported its own add implementation (which could be written to use its own `+`). That kind of Library code is hard to write correctly, however, if one tries to replicate the special evaluation rules that global :-`+` has.

I'll also note that (somewhat strangely) the simple calling sequence you've used for elementwise multiplication is picking up the global :-`*` rather than the rebound `*` from the Tolerances export.

I'd call the behavior of add a weakness, but the behavior of *~ might be a bug.

Download tol2.mw