The purpose of the special code about which your's asking is to have a call to procedure h return unevaluated (ie. as the same call, itself) in the case that both its arguments are not numeric.

Put briefly, it was done so that the call h(a,b) simply returns as itself, unevaluated, when a and b are merely unassigned, symbolic names rather than actual numeric values.

If h is not set up that way then the calls like h(a,b) -- that get invoked by the call BC2(a,b) -- would induce an error in dsolve/numeric.

Your call to implicitplot contains the call BC2(a,b) in the list that is passed as its first argument. That will get evaluated up-front -- in Maple's usual manner of handling calls to procedures/commands -- before implicitplot starts replacing the names a and b with actual numbers.

Below I show you that -- with your original variant -- the call BC2(a,b) returns with unevaluated calls like h(a,b) (ie. with a and b as symbolic names as its arguments).

Without the special code part of h (about which you're asking) that call BC2(a,b) would throw an error (because h(a,b) in turn would throw an error) before implicitplot even saw its arguments or had any opportunity to start replacing names a and b with actual numbers.

But first I'll show immediately below a variant in which that special construction of h is not needed. I get around the difficulties by using a so-called operator-form calling sequence to the implicitplot command. In this case implicitplot's argument consists of operators/procedures, and BC2 does not get called until its arguments are actually supplied by -- implicitplot's internals -- as numeric values.

Download Mikey_01.mw

The following attachment is as much as I believe can be recovered from your zipped .bak file.

STAT_131_Introduction_to_Prob_acc.mw

There might be two missing (unrecoverable) Inputs, in section "Day 14", between the line with "bivariate random vector" and the line with "Joint distribution functions".

I suggest that you upgrade to Maple 2023, if available to you. It seems to have fewer incidences of this kind of problem.

You can make the animation from your original "Test" collection, by passing the extra option insequence to your call to the plots:-display command.

Or you can account for the fact that plots:-animate passes a float value for i, by turning that into an integer prior to the indexing into your Matrix data.

Note. By default animate uses 25 frames. You could also supply the option frames=18 if you want animate to generate exactly 18 frames for i=1..18. That would make the two approaches produce the same animation. But it'd still pass i as a float, so you'd still need to trunc/floor/etc to get an integer. This option also provides an easy way to slow it down -- ie. duplicating frames by using a higher frames value, eg. multiples of 18 here, say.

Download 23-11-03_Q_Animate_a_line_ac.mw

It's clear from your Questions picture, and the attachment's filename, that you are trying to Read an image stored in your Maple workbook.

With a short edit to your this URI the following zipped workbook succeeds for me using Maple 2023.1.

TestTrans_ac.zip

The following is as much as I believe can be recovered here. (Three input equations were corrupted; somewhat near the beginning.)

Hjemmeopgave_7_igen_ac.zip

I suggest that you upgrade to Maple 2023, if available to you. It seems to have fewer incidences of this problem.

You can use your desired ranges for x and t in the calls to contourplot, along with scaling by Mx and N respectively. And you can also use the desired ranges directly in the (density-plot) PLOT call.

I also made a few changes for (IMO) a better look, such as getting rid of the minus sign on "-0.000", increasing the contourplot grid, etc.

Also, one way to get a nicer final export is to increase the plot size, since you can then scale down using a good external image processing program. I also made the contours thinner using subs, since IIRC Maple 2015's contourplot didn't allow that thickness (thinner than thickness=0 !) 

This direct approach can be more efficient than using plottools:-transform to re-scale/shift the original result (after the fact).

I think that it's often easier to manage in the long run if your calls/functions are properly scaled up front, instead of fudging the tickmarks later on. (I choose forced tickmarks only as last resort, usually. It doesn't work with all later transformations, as one reason.)

By the way, I suggest exporting the plot from Maple in .PNG format. Well, almost anything except .JPG, for which the results are generally poor.

If you want advice about exporting the data then you should describe the required format in explicit and adequate detail. Merely mentioning a product's name, like "tecplot", is not adequate.

ps. Quite a bit of this code looks like bits that I'd written. Is that right? I'm curious now; where did you get it from?

Since you gave a followup example (elsewhere),
 

Download jestrup1.mw

This is as much as I could recover. I think it is most of it.

I left all the sections unexpanded.

prac_exam_ece4179_acc.mw

There may be a missing equation just after the line with "evaluate for the given points" in section 1, and another just after "This decision boundary will realize" in section 4.

I notice that you were using Maple 2022.2.  I suggest upgrading to Maple 2023 if available to you; it seems to have fewer occurences of this problem.

Your attempts at forming a Matrix try to use Ans[k], but your loop simply assigns (repeatedly) to just Ans. It looks like you meant to assign to Ans[j] and Ans1[j] in the loop.

In your systems of equations you have terms like Theta(eta,t), but in your attempts at forming a Matrix you have the arguments of Theta reversed, like Theta(0.5,eta). Did you mean Theta(eta,0.5) instead? The same happens for the other functions.

When you write,
   eval(diff(Theta(0.5,eta),eta),Ans[k])(0)
are you wanting instead to take from Ans[k] the derivative of Theta(eta,0.5) w.r.t. eta, and then evaluate that very close to eta=0? If so then this is essentially the same as your query in your previous Question. You are mistakenly using technique appropriate for a result from dsolve(...,numeric) rather than from pdsolve(...,numeric). Have a look at this: error_in_table_value_ac.mw

You could avoid duplication of conputation by computing the Matrix entries (involving the other terms that I omitted) in a loop.

Are you trying to get something like the following?

Download Qop2_ac.mw

Those are actually equations, and you could use or access their lhs and rhs separately.

Note that formation of the string may not be strictly necessary, compared with simply calling the operation on the arguments directly to get the inert expression. (But there seemed to be a few corner cases, where using the inert operators with prefix form helped.) Did you really need the string representation, using infix form, or is the above result from InertForm:-Display enough?

I notice that you had B set up to avoid being A. Is that because you didn't want A-B to produce 0? If so perhaps you'd also want to avoid A+B=0 when B=-A? And perhaps you'd prefer neither A nor B to be -1 or 1 when multiplying?  Qop2_ac2.mw

It sounds as if your preferences were not migrated to your new installation. (There's usually a dialogue that asks about that, during installation.)

You can set the preference by using the main menubar,

   Tools->Options->Display

and then set the drop-menu box "Input display" to "Maple Notation".  Then press the "Apply Globally" button to set it as default.

@zenterix You could use the terser,

   m::{Matrix,list(Matrix)}

instead of using `Or` in the type specification.

The LinearSolve command in the LinearAlgebra package can handle this.

Let's write out the coefficients (of x) for your polynomials, as column Vectors. Form a Matrix of the ones from S.

Then call LinearSolve.

Download LS_ex2.mw

note: You wrote, "corresponding linear system", which indicates that you recognize that this problem can be expressed as a linear system. Using LinearSolve might then not be unexpected. Reformulating the polynomial relationships as a linear system, programmatically, might then be useful for you.

Notice that you were using the %d format code for this item, in printf. That's for integers. But you mentioned wanting them as 1.0,1.2,...2.0, which are floats. So you could use the %2.1f format, in printf.

Now, you already have the float values you mentioned wanting, available directly via t[i] .

If you didn't already have them using t[i] then you could also get n values evenly spaced between a and b by using the formula,
   a + (b-a)*(i-1)/(n-1)
which for this example would be,
   1 + (2-1)*(i-1)/(n-1)
which can be shortened to,
   1 + (i-1)/(n-1)

Download frm.mw

For future programming, you might also care to think about how the following work. These kinds of construction occur pretty often in programming. It can be a useful thing to get familiar with.

<seq(1.0..2.0,0.2)>;
n:=6:
<seq(1.0..2.0,numelems=n)>;
<seq(1.0..2.0,(2-1)/(n-1))>;
<seq(1.0+(i-1)/(n-1),i=1..n)>;
Vector(n,i->1.0+(i-1)/(n-1));

You are using module locals like Chevron2A as the keys of some of your tables.

That will prevent you from accessing table entries if you subsequently try and use (say) the global names like Chevron2A as the key, trying that access outside the module.

You could, instead, use global name :-Chevron2A as the table key when creating the entry. Then you can use that as key, for access elsewhere. [edit] I would prefer this, over a module export. Using strings is also a good possibility, as Carl has mentioned after I posted this Answer. If you use the global name as key then you ought to quote it (and protect from evaluation), in case it is also assigned some value, eg. ':-Chevon2A'.

Or you could instead declare Chevron2A as an export of the module. Then, later, you could use it as key in its long-form (fully qualified name),  calculateblahcubitblah:-Chevron2A. Or you could make the module a package, so after doing with(calculateblahcubitblah) its exports become the new bindings for reference via the short-form Chevron2A. [edit] This is not my favorite choice, and I can only think of convoluted scenarios in which it'd provide extra contextual usefulness.

The code snippets that you showed above indicate that this problem that I've described occurs in your code. I cannot tell whether you also have other issues, eg. last-name-eval of tables assigned to names. I suggest using eval(nameoftable) when putting into lists or if returning them straight from procedures.