Attached is an example of accepting an indexed procname call.

2024-11-21_Q_Projective_Vector_Format_ac.mw

Now, for your type question. You seem to be under an impression that whattype gives you THE type of a thing, because you mention "...the type check", and what you have are some whattype calls.

But things can be of several types. And the type system is not even completely hierarchical. In general using whattype is (IMNSHO) a logically inferior mechanism for control flow, dynamic dispatch, etc, and I suggest that you instead check against specific types.

For example, I suggest you later do something like,

    if type(K,foo) then
    ...
    elif type(K,bar) then
     ...
     end if

instead of, say,

    W := whattype(K);
    if W=foo then
    ...
    elif W=bar then
     ...
     end if

and similar for other analogous situations.

You are of course free to do it your way. But in my experience that may eventually get into a muddle, and the fact that your examples so far don't have issues is because they are rather simple.

You asked why. It fails because an indexed reference into an rtable (Matrix,Vector,Array) cannot be evaluated unless the indexing value is an actual integer. The indexing value cannot be a name/symbol/placeholder.

So, the evaluation of Xvector[i] produces that error, for `i` just a name.

But you can make such unspecified referencing for a list (or a set), ie. you can evaluate Xlist[i]. If `i` is just a symbol then that will merely evaluate to itself.

Maple evaluates arguments to procedure calls up front (ie. before the sum routine gets its hands on them). That is Maple's normal evaluation rules for procedure calls.

So, that error occurs before sum even receives its arguments.

See also special evaluation rules.

Download add_sum_Vector_indexing.mw

This relates to why the Help page for the sum command has, in its Basic Information Section, a Note: "Although the sum command can often be used to compute explicit sums, it is strongly recommended that the add command be used in programs if an explicit sum is needed, in particular, when summing over all elements of a list, Array, Matrix, or similar data structure."

There is even an example showing this very issue with sum and a Vector, in the sum,details Help page.

And lastly, that magenta error message in your Question here is a URL and you can just click it and have it open this page. You can even click on it from within the Maple GUI and have it open in your web browser. That web page includes the same sum & Vector problematic example, explanation, and two alternatives.

He might have used the Accents Palette from the GUI's expanded left-panel, with 2D Input, to get the arrow above a symbol.

If I do that (and also use the 2D Input syntax that allows for a function call on the left of an assignment to denote an operator definition),

Download accents_ex.mw

[edit] I'll add that using either the Accent palette as I did, or the short-cut keystrokes for an overscript following by the -> keys as Scot did, both produce the same blob of MathML-like TypeMK-thing which is a name which typesets in that desired manner.

Underneath, both construct the same specially formed name,
    `#mover(mi("v"),mo("→"))`

A variant is to use the Layout palette to insert a generic overscipt placeholder, and then the right arrow from the Arrows palette (or whatever other thing you might prefer there).

An aberration is seen for this example in Maple 2024 (and some other recent versions) with the plot command's default adaptive sampling algorithm.

In this case it utilizes plot's "new" adaptive=geometric algorithm for sampling x values, even if no choice for the adaptive option is supplied. Unfortunately that algorithm goes awry on this example. (I will submit a bug report against this example.)

By supplying the choice adaptive=true one can force the old default sampling, which works fine here.

plot(sin(x)*sqrt(1 - (sin(x)/x)^2), x = 0 .. Pi/4, adaptive=true)

Also, for fun,

plot(sin(x)*sqrt(1 - (sin(x)/x)^2), x = 0 .. Pi/4,
     adaptive=true,
     discont=[showremovable, symbol=solidcircle])

Are you trying to use a default numeric formatting? (Ie. a default number of digits shown for floats, units choices, etc?)

You might look at the Numeric Formatting Help page, possibly then through its link for a User Profile.

Another choice of representation is a 3D plot, of surfaces.

(You could play with the various transparency values, orientation, etc.)

Download enfonction_p_2_cas1_ac.mw

You could also Explore that 3D plot (with a bit more transparency), where an `a` Slider manages construction of solid three colored spacecurves (changing `t`, for `a` fixed) that move across the three surfaces.
         enfonction_p_2_cas1_acc.mw

You can also make a regular animation from that:
         enfonction_p_2_cas1_ac_3danim.mw

ps. I've used Maple 2019, as did the OP.

restart;
L:=[3,4,x,x^2,x^3,sin(x)]:

map(proc(X) local la;`if`(patmatch(X,x^'n'::nonunit(anything),'la'),
                          eval('n',la),NULL);end,L);

             [2, 3]

# Or, with a small edit to your original,

map(X->[unassign('n'),`if`(patmatch(X,x^n::nonunit(anything),'la'),
                           [assign(la), n][],NULL)][],L);
Warning, (in anonymous procedure) `la` is implicitly declared local

             [2, 3]

In your approach you had put each successful result in [assign(la), n], which created those inner lists.

I don't see how one might easily get solve to show you only all the steps, ie. without getting a lot of internal procedure's details (infolevel, printlevel, the debugger, etc).

Solving for s can be done using just one of the equations, using a command from the Student:-Basics package.

nb. you might also observe the similar form of rhs and lhs of that equation, and the common position of s and j. (ie. you might solve it mentally, without even needing solve/identity etc.)

It's unclear what you're trying for h2, since it seems that you might have made a typo in the name to which you assigned the other expression. Also if you use the "correct" name then -- since the rhs=lhs for that other equation -- you're just going to get h2=h2, ie. anything works.

I use Maple 2019, in which your attachment was last saved.

Download Q_3_ac.mw

The muddy part of the (otherwise red) ball is due to having an semi-transparent greenish-yellow portion of surface between it and the viewer, no? Is that ameliorated enough by making the surface more transparent, or altering the color/shading choice?

The jagged shadows seem to be artefacts visualizing a farther portion of surface through the transparent closer portion, combined with how the GUI's surface renderer deals with the (discrete data) plotting structure.
1) The jagged shadowing might be lessened by decreasing the cylindrical data granularity (ie. increasing the grid resolution, at least for cylindrical theta), eg. using grid=[351,51] or such for the sphereplot. After doing so there still some oddness with dropped color from the front portion at some angles, but at least it's not jagged.
2) You might be more satisfied with a single color for the sphereplot.

ps. plottools:-transform and plottools:-rotate lose several parts of axis information. Some such aspects are not always sensibly translatable, but it's heavy handed in dropping it all. I've gotten in the habit of putting that kind of "global" stuff in any final plots:-display, instead of having it "local" to any one particular feature that I'm combining with others. Not ideal, but I often do it now from habit.

What you've shown is a consequence of applying a list of equations to an argument. Each side of each equation is applied to the argument. Note also what happens when you apply a single equation to an argument.

In short, it's doing what's been asked of it.

Note also that a(t) is a mere function call, and not a procedure or operator; It's instance of t has nothing to do with the 1 used as an argument.

When you use output=listprocedure then only the rhs's of the equations in the returned list are procedures/operators. The lhs's are just unevaluated function calls. Applying those unevaluated function calls to some argument doesn't do anything special; each makes an unevaluated function call of an unevaluated function call. If you apply H(q) to argument p then (with H unassigned) all you get back is H(q)(p) .

If you don't want to deal with that then don't use output=listprocedure. There are other choices of output form.

Alternatively, you could in fact accomodate that behaviour. You could apply only the rhs of some of the equations, etc.

Or, you could pick off the resulting applied rhs's using a variant like,
   foo := dsol(1);
   eval(x(t)(1), foo);
etc. Here is just one way to do that in your sheet. There are other variants, naturally. (ie. your claim about a substitution not being possible is not true; it just needs doing differently),
dsolve_numeric_output_with_extra_brackets_ac.mw

nb. It wouldn't make sense if the various output choices for dsolve,numeric all acted just the same. You might use which one suits your followup tasks best for you.

edit: Readers of this Question thread might also be interested in this related, earlier Question.

In addition to the mentioned listprocedure (and the default procedurelist), there is also the choice of output=operator. So for this example, subsequent substitutions into an existing expression eq0 (in terms of x(t),y(t),etc) might also be done as,

dsol := dsolve({daes, ics}, numeric, output = operator):
# and then,
eval[recurse](eq0, [t=1,dsol(1)[]]);
# or,
eval(eval(eq0,t=1),dsol(1));

dsolve_numeric_output_with_extra_brackets_ac2.mw

The various choices (listprocedure,procedurelist,operator) for dsolve's output option can all be made to work here, often each in several ways. But depending on the particular use-case some choices might be more straightforward to utilize. And some may be more efficient; again it depends on the example goal. No size best fits all.

You might be able to utilize the size option to get a specific number of pixels.

That option is accepted by, say, the plot and plots:-display commands (and others). Eg,
   plot(..., size=[504,208])

You can also set it just once at the start of a worksheet, as a kind of default for the session. Eg, for 2D plots, eg.
   plots:-setoptions(size=[672,384]):

The conversion of that to inches will depend on the resolution of your device (which I cannot know). Your monitor might be at 72 ppi or 96 ppi (pixels per inch), etc. Or you may have hi-res. Or you may be exporting/printing the worksheet at 300 ppi, etc. Whichever it is, you might do the arithmetic to get the pixel values needed.

ps. I'm not sure whether you are trying to export/print the worksheet as a whole (to paper or to PDF file, say), or exporting plots individually to file using plotsetup, etc.

In the worksheet attached below, those coefficients are stored in a Matrix.

The main point here is that the coefficients you wanted have been extracted and stored separately, so that you can re-use them programmatically (and separately).

If you wanted you could form equations with all the entries of the Matrix equated to zero, or do so with the numerators, etc. Use the entries of M the Matrix as you wish.

The extraction happens in the short double-loop in red 1D code. The remaining portion of the worksheet merely demonstrates that the coefficients are as desired, and also provides a visual.

Download collect_sb_ac.mw

Your calls like,

   evalf(sum(f(h*i+a)*h, i = 1 .. n))

are prematurely calling the passed f procedure before index variable i gets any actual integer value. In other words, it is evaluating f(h*i+a) with i being just a symbolic name.

Instead, try those like,

   evalf(add(f(h*i+a)*h, i = 1 .. n))

The add command has special evaluation rules, which here can prevent the call f(h*i+a) from being evaluated until the index i gets actual integer values from the 1..n range.

forum_ac.mw

You might also need to examine your algorithms for correctness; I haven't.

See also the third note on the Basic Information section of the Help page for sum.

Another choice is,

   plot(t->eval(r,dsol1(t)), 0..10)

which seems pretty natural to me. As you can see the operator can be more directly constructed, more tersely and without the longer and more complicated use of unapply and uneval-quotes.

Using eval (or subs) for the substitution is pretty natural Maple here, as you have given an r formula up front, and want to substitute into it.

You may wish to compare approaches, for efficiency. Your followup approach with double uneval-quotes is slower.

In the attached worksheet I also try to force a similar number of points for all approaches, for sake of comparison.

computation_with_dsolve_exports_ac.mw

Some other approaches in which the x(t) and y(t) instance are computed separately (for each numeric t value) may also be slower than pumping each numeric t value just once into the returned dsolve thing and then extracting -- though that might also depend on how they get utilize. I won't bother to give such. Note that odeplot is optimized to utilize the computed components efficiently in this respect.

ps. I won't mention the output=listprocedure (or operator) choices since you might find those too complicated for your liking.

[update] I see that Kitonum has since added another answer. You'll see that his suggestion,
   r:=s->eval(sqrt(x(t)^2+y(t)^2), dsol1(s)):
   plot(r, 0..3);
is functionally nearly identical to mine. (I used the assignment you already had to `r`.)
   r:=sqrt(x(t)^2+y(t)^2);
   plot(t->eval(r,dsol1(t)), 0..10);

Given your own r formula up front,
   r:=sqrt(x(t)^2+y(t)^2);
then you can of course assign the operator to a name, and then re-use it in plotting, rootfinding, optimizing, etc.
   fr := t->eval(r,dsol1(t));
   plot(fr, 0..10);
...and so on.

Note also that with the syntax I gave you can reassign name `r` with another new formula in x(t),y(t) and that same operator can then be re-utilized and access the updated formula. (Kitonum's answer hard-coded your original formula in the operator; though it's just a step to recreate a new operator.) 

Is this something like what you're trying to accomplish, checking whether any of the solutions can be verified by odetest, for each set of parameters?

Download odetest_ac.mw