If you assign a value to mu (by itself) then you will affect any instances of indexed names like mu[3], mu[4], etc.

So if you also want to have the subscripted names then you can instead use m__3 and mu__4 (double underscore). Those are completely separate and unrelated names.

But the double-underscore names will pretty-print as subscripted names in 2D Output.

The clause, "no computation was needed if basic math knowledge was utilized" connotes (to me) what is called abstract linear algebra.

If there were placeholders (objects, etc) that represented a Matrix, and enough accompanying functional syntax, then a strong abstract linear algebra package might be able to recognize the equivalence of those two forms without doing a computation with explicit Matrix entries.

At the other end of the spectrum is the fact that your pairs of concrete constructions are not producing the same final form. For example, there may be some difference in presence or absence of factorization of numerators or denominators of the resulting multivariate rational polynomials. On that note, getting the final Matrix of zeros for the difference can be attained just by normal (ie. simplify is not needed, and its symbolic option is not relevant here). Also, a true result for the comparison can be had by just,
   Equal(normal(expand(1/`⨂`(A, A))), normal(expand(`⨂`(1/A, 1/A))))
Using_basic_linear_algebra_ac.mw

In the middle ground there might be scope for hybrid abstract/concrete computation, where either of the two calls were somehow analyzed up front. That would require by-passing the usual evaluation of MatrixInverse (or rtable powering) or KroneckerProduct, so that their arguments could be analyzed abstractly. (Maple's usual evaluation of function calls has the inner calls evaluated before the outer calls get to "see" them.) In this example it might even be the case that the faster of those formulations could be used, once the form is recognized. Implementing this is possible, though possibly involved.

Closer to the concrete end is the idea that both results might be simplified/normalized by the commands themselves (though not at present) to a common form. This is not the way that several parts of Maple work; it can be too expensive and heavy-handed to do that in general, and it's often left to the user to do such as a subsequent step.

This could be improved (say, removing entries when no longer active).

Download assum_var_palette.mw

There are several ways to do that.

For example,

restart;
fn := "/home/PNL/test_file.txt":
fprintf(fn,"%a\n", "Hello, it is me"):
fprintf(fn,"%a\n", 3.1415):
fclose(fn);

restart;
fn := "/home/PNL/test_file.txt":
FileTools:-Text:-WriteLine(fn, "Hello, it is me"):
FileTools:-Text:-WriteLine(fn, "3.1415"):
FileTools:-Text:-Close(fn);

restart;
fn := "/home/PNL/test_file.txt":
FileTools:-Text:-WriteFile(fn, "Hello, it is me\n3.1415\n"):

Note that the directory must exist. Note also that the the first two of those require that the file handle be closed (by explicit command, or by a restart). The "\n" is for a new line.

I couldn't tell whether you wanted the Hello string to be written out including its quotes. If so then you could escape the quotes within a string, eg.
   "\"Hello, it is me\""

There are even more ways to do this kind of thing. But let us know if you get it working. It looks as if your OS is not MS-Windows, btw.

You have two main choices for formatting floats in printed output.

1) Set interface(displayprecision), a programmatic solution which will affect anything executed after it's set.

2) Use right-click Numeric Formatting. This has a choice of affecting only the given Execution-Group/Document-Block in which it's done, or as default for the worksheet.

nb. Don't attempt to get this kind of effect by setting Digits so low as 5. That is a very bad thing to do and can actually make some subsequent computations not work properly.

Even wrapping with evalf[5] is tricky to get right and not what I'd suggest to anyone without a strong working knowledge of Maple.

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.