There are these two mistakes:

1) You've used geom3d[point] but also loaded plottools. So that evaluates using the export point from plottools, which goes awry. Intead, utilize it as geom3d[:-point] or geom3d:-point.

2) There is an intended comment in ElloidInTet which does not begin with a # hash symbol, and so gets parsed as a product for the lhs of the intended next assignment statement. The intended comment contains the word "in", which is where the error arises.

Strange_Error_ac.mw

Your worksheet is a little weird in that it has a call to ElloidInTet occurring before the later definition of that procedure. But with the two mistakes (mentioned above) corrected then it runs OK for me if executed out-of-order.

Perhaps what you are after involves using Unit(1/s) for the x in your fitted formula. That way the seconds unit in Weight_time entries will cancel, and the result will have mass units (as do the entries of Pull_Weight). Eg,

   1.86*7.03^(x*Unit(1/('s')))*Unit('kg')

The Standard and Simple units environments get in the way, a little, for that. But below it one way (for each):

Maple_Primes_Question-worksheet_Units_ac_Standard.mw
Maple_Primes_Question-worksheet_Units_ac_Simple.mw

It seems somewhat over-complicated (and error prone?) to utilize the SI system and have unit-formatting for output make it all display with FPS. How about using the FPS system for the computations? That way you need't have to enter kg instead of lb, every now and then. Just a thought...
Maple_Primes_Question-worksheet_Units_ac_Simple_FPS.mw

In Maple 2020.2 (which the OP cites in one of his older Questions) it does not stall.

Essentially the same results are obtained much faster (a few milliseconds intsead of 0.25 seconds) by applying evalf to the Matrix before computing the Eigenvalues.

eig_add.mw

Here's one way (amongst several possible) to get that string s from k in Maple 17.02,

k := 5;

             5

s := convert(cat($0..k-1),string);

          "01234"

How much does efficiency matter to you, for that subsequent Vector generation? What other similar examples are you planning on treating? That subsequent, longer call (using StringTools commands) is not most efficient for the given example, though it's not clear what might be your general case.

restart;

kernelopts(version);

   Maple 17.02, X86 64 LINUX, Sep 5 2013, Build ID 872941

a := {x+1, x+2, x^2+1, x^2+x+2}:

a1 := combinat:-choose(a, 3):

map(`*`@op, a1);

     /                / 2    \                  / 2        \  
    { (x + 1) (x + 2) \x  + 1/, (x + 1) (x + 2) \x  + x + 2/, 
     \                                                        

              / 2    \ / 2        \          / 2    \ / 2        \\ 
      (x + 1) \x  + 1/ \x  + x + 2/, (x + 2) \x  + 1/ \x  + x + 2/ }
                                                                  /

In the calling sequence you're attempting last, the "objective procedure" utililized within the fdiff calls should accept two scalar arguments rather than a single 2-Vector.

Continuing your example,

f := (a,b) -> obj(<a,b>):

objgrad := proc(v::Vector, w::Vector)
        w[1] := fdiff(f, [1], [v[1],v[2]]);
        w[2] := fdiff(f, [2], [v[1],v[2]]);
        NULL;
end proc:

NLPSolve(2, obj, objectivegradient=objgrad);

                [                      [0.0364560120817733]]
                [0.276597509679878450, [                  ]]
                [                      [0.603788442821000 ]]

mmcdara_Opt_fdiff_grad.mw

(You could also construct scalar-argument procedure f first, and then construct your procedure obj to call that f. I believe that's how I did it in this old Post.)

One way is to have your deltaHat procedure return unevaluated if its arguments are not both numeric. That's an alternative to trying to use single right-ticks (a.k.a. uneval quotes) to prevent premature evaluation.

maple_primes_question_acc.mw

There is one case in which you specify the desired lower and upper values as well as their regular increments (for each direction, x and y). In this case the Matrix dimensions are dictated by those details.

Another case involves knowing the designated lower and upper values and then being given a Matrix whose dimensions are not specified up front by you. Here the Matrix entries might be interpreted as representing x-y values in the known ranges. In that case the increments follow from those details.

For example, matrixplot_ticks.mw

If you have some other scenario (eg. of what is given versus specified) then you should explain which parts are which and supply a concrete example.

The width thing can be solved a few ways, eg.

DocumentTools:-Tabulate( <header, dat>,
                         widthmode=pixels, width=330,
                         ':-fillcolor' = ((T, i, jj) -> `if`(i = 1, cyan, white))):

For the fonts, I'll have to wait until I get back in front of an actual computer (hopefully later tonight) to show how the result from Tabulate could be manipulated.

Or the entire Table could be constructed using DocumentTools:-Layout commands. That can become a chore for re-use, or more involved math examples, or repeated applications. I'll likely do your single example that way too.

There are actually two kinds of fonts and sizes in play, for strings and fortypeeset math equations. Handling each separately would be nicely more flexible. The numeric data is typeset like math (rendering nicely in upright Roman). Using text strings for floats otherwise can otherwise look poor. Both kinds of font size can be massaged after a call to Tabulate, I believe but must check later...

Having Tabulate accept additional cell-by-cell look&feel options (in a manner similar to how it allows for coloring) has been on my minor wishlist for a while now.

You wrote, "The proc needs to basically generate constansts to use to build an expression, similar to how dsolve uses _Cn".

That's fine, as a goal. But generating locals is quite likely going to be problematic for you, if you subsequently need to extract those names (eg. for the purpose of substitution). Utilizing indexed local names is not much better, and it's not really better at all if you would still need some additional mechanism to avoid collision or duplication or to robustly extract and re-use for manipulation.

Returning escaped locals is generally a poor technique which often requires more work and hoop-jumping after the fact.

If you are concernced that you should not use global names because they might collide with previously assigned names, then there's a convenient mechanism to avoid that. The following mechanism is utilized by other respectable Library procedures, and consists of concatenating a symbol with a nonnegint such that the result is a previously unassigned (non-colliding) global name.

For example,

restart;

# First, your approach with escaped locals.
foo:=proc(var::name)
 local A;
 return A[0]+A[1]*var
end proc:
ans1 := foo(x);

           ans1 := x A[1] + A[0]

# The following doesn't work, because we don't have
# the local version of the name A, to pass to `type`.

indets(ans1, suffixed(A, nonnegint));

                    {}

# Now, using generated, noncolliding global names.
bar:=proc(var::name)
 return `tools/genglobal`(':-A')
        + `tools/genglobal`(':-A')*var;
end proc:

We can even assign safely to global base name A, and still get a useful process.

A := 13:
ans2 := bar(x);

           ans2 := A1 x + A0

indets(ans2, suffixed(':-A', nonnegint));

               {A0, A1}

bar(x);

               A3 x + A2

bar(x);

               A5 x + A4

indets(%, suffixed(':-A', nonnegint));

              {A4, A5}

Let's suppose that you were writing your own symbolic ordinary differential equations solver. In that situation I think that you generally would be better off with generated non-colliding global names (say, for constants of integration, or arbitrary constants) than with indexed references to escaped locals.

Your problematic call to select is selecting individually from the operands of a single product, not a sum of products.

Note that the empty product is 1 (akin to how the empty sum is 0). Since none of the individually tested operands in the product expression satisfy the whole type query the select result is the empty product.

You seem to have the mistaken impression that the single expression (a product) is merely one term in a sum (of one term only). But that is incorrect.

This is not the first time that you've been in this particular kind of muddle in the past few weeks.

In one recent Question of yours on the very same topic I showed and mentioned that a preliminary test may be needed, ie. in this case testing whether the the overall expression is of type `+` before calling select on it as if it were a sum of terms (eg. sum of products).

Using Maple 2020.2,

simplify(rationalize(f(-2)));

           1  (1/2)   1
           - 5      + -
           2          2

evala(g(-2));

           1  (1/2)   1
         - - 5      + -
           2          2

evala(h(-2));

                1

Here is one way, which you should be able to adjust as wanted.

You had only two values in the lists for labels and labeldirections, but 3D plots require three. I fixed that.

Note that the size option is not available in Maple 2019 for 3D plots. I put in a workaround.

Help_3D_ac.mw

With M=0.2 fixed,

Or with M=0..10 as the second plotting variable,

(The above approach could be figured out by reading the Help page for topic textplot3d.)

You are probably aware that in general quintics are not solvable in terms of radicals. I don't see any avenue to an explicit exact solution here. But a numeric result can be obtained straightforwardly.

restart;

eqn := 64/19683*t^9 - 16/729*t^7 = (-t + sqrt(t^2 - 4))/2:

S := solve({eqn, t>2}, t, explicit):

    {t = 1/2*9^(1/2)*2^(1/2)
         *RootOf(4*_Z^5-2*_Z^4-2*_Z^3-4*_Z^2-_Z-1,index = 1)^(1/2)}

evalf(S);

               {t = 2.557990173}

fsolve(eqn, t=2..infinity);

                 2.557990174

Are you asking for a formal proof or demonstration that this quintic might not be solvable in terms of radicals? If so, what is your math background?

Would you be satisfied by seeing messages about what the internal routines underneath solve are ascertaining?

restart;
eqn := 64/19683*t^9 - 16/729*t^7 = (-t + sqrt(t^2 - 4))/2:
infolevel[solve]:=6;
S := solve({eqn, t>2}, t, explicit):

restart;
infolevel[solve]:=6;
solve(4*tt^5 - 2*tt^4 - 2*tt^3 - 4*tt^2 - tt - 1, tt, explicit);

I usually find it more convenient to use assuming rather than assume. It might also help you avoid this particular difficulty.

pi_filter_osc_anal_ac.mw