Your code calls eval like this,

   eval(M, [:-alpha=alpha, :-gamma = gamma, :-mu = mu, :-lambda=lambda, :-B[1]=B__1, :-B[2]=B__2],:-beta[0]=beta__0)

but the closing right bracket is in the wrong place, ie. before beta[0]=beta__0. So you're invalidly calling eval with three arguments. That's what the error message tells you, too. It should be,

   eval(M, [:-alpha=alpha, :-gamma = gamma, :-mu = mu, :-lambda=lambda, :-B[1]=B__1, :-B[2]=B__2,:-beta[0]=beta__0])

Also, you're code tries to substitute for global :-gamma, which you've declared local at the top-level.

Also, some parts of your expression might take either very large/very small values, when done computed at hardware precision. You can force use of "software" floats instead of hardware double-precision. And you might also want to experiment with how much (if any) increased working precision might benefit the accuracy.

You might also need to adjust your hard-coded view, in the plot3d call in procedure G.

plot1_ac.mw

ps. One of the useful ideas behind having such a G procedure is that you can just call it with numeric arguments and get a single plot. That's easier to debug and figure out than is a whole Explore call. Focus on getting a/any good result from G. Then, when that works (at all!) try Explore.

Please check for mistakes. I may have misunderstood, and I wrote it quickly.

The basic idea is that if you can get at the allowed functions (of the Xi names) then you could freeze those function calls. The resulting (frozen) placeholder names might then be added to the set of Xi names and done altogether with the methodology for handling your first bullet point cases.

If you have some particular allowed "functions" in mind then you could adjust the typefunc
specification below, changing from name to something else (eg. identical(...), or other...)

Download typefunc_ex.mw

Download grid_set_module_local.mw

Yes, it is a bug.  If x is real then at least one of the pair is satisfied.

A developer might classify it as a "weakness".

I couldn't get it with a single is call and unrestricted real x (or equivalent) and the point is that ideally that would be possible.

Download is_trig_01.mw

You might guess that I have a hunch that an underlying problem is with combining such pairs, rather than just internal problems with trig handling...

A helping prod, that happens to work:

is(x*y*z = 0) assuming Or(x=0,z=0);

             true

I suppose that `solve` could be leveraged to get that Or() construction programmatically. Multiple results from solve can be taken as Or, and individual results within that can be taken as And (or just themselves if a singleton sequence).

I like nm's Answer.

In your Document, the expression assigned to Ghat contains a name-quoted minus symbol instead of just the infix minus.

That makes it a name, not the expected arithmetic operator. And the spaces around that name make the whole thing get interpreted (2D Input) as implicit multiplication.

It parses your form as,
   2*sqrt(2)*GAMMA(5/2)*`-`*(7*sqrt(2))/6*GAMMA(7/2)/(r^(5/2)*r^(7/2))

If I replace it with just the usual infix minus sign then it goes as expected.

Download asyapprox_ac.mw

Here I've used Maple 2022.2, since that's the version in which your attachment was last saved.

It can be simplified with just,

   simplify(B1,exp)

however below also I give a few minor variants on the final form (and checks on all results).

Download simplify_3_ac.mw

Are you trying to say that previously unopened .mw files on your machine have changed, as saved files?

Or are you trying to say that when you now Open any .mw file (Document) that was previously untouched (as a file on your OS) that the GUI opens it wrongly, and alters the input lines as displayed.

If the latter, then are you also saying the uninstalling/reinstalling doesn't help? Are you sure that when uninstalling your personal GUI Preferences file is removed? It would usually be somewhere like this on MS-Windows:
    C:\Users\%USERNAME%\AppData\Roaming\Maple\2023\Maple.ini
If that's still present (on uninstallinging) then you might consider removing it prior to reinstallation.

(It seems weird, if a wholly clean install were now to show different behaviour when opening files that haven't been changed since before the problem started.)

Here are some fixes that allow the problematic sections 17.6, 17.9, and 17.10 to run in a newer version such as Maple 2018 or Maple 2024.

ch17_acc_2018.mw

The problems come in the following varieties:
i) Failure of plots:-spacecurve with operator-form calling sequence. Remedy is simple: since the operators return unevaluated when passed a name, replace the operator names (in the first argument triple) with those same names applied to `t`, and use t=range instead of just range. Or just use plots:-odeplot (which is usually better, btw), in its usual way. (I will submit a bug report; it broke in Maple 2016.)
ii) Use of bare name y alongside aliases to indexed names y[i] in section 17.9.
iii) Dubious recursive definition in loop in section 17.9,
    for i from 0 to e_order do   
        eta[i] := t -> eta[i](t)
    end do:
The whole alias/macro/defn business of that section is obfuscated.
iii) Repeated (chained) aliases in section 17.6, which is hokey.
iv) Access to casesplit results by location in the returned sequence, in section 17.10, which was fragile programming. Changed it to access by property of nontriviality does better, including in Maple 2024 whose casesplit result differs in form/nature from that of Maple 2018.
v) I also added a few normal/simplification/sort calls, to get some of the (mathematically) ok results to look&feel even more like in the "target" .mws file's output.

There is an example about this on the Help page for assuming. (It's the example about a procedure f).

The essence is that the usual assuming facility does not place assumptions on variables inside the procedure body, up front (which is how it works).

That page documents the following as an alternative, which leverages a revised mechanism that does what you are after:

Download assuming_ac.mw

Another way to handle your example is to first assign your procedure call to an expression, in which case the usual assuming mechanism "sees" the relevant variable name.

Download assuming_acc.mw

Notice the difference, according to whether we assume m__1 is greater than or less than 0, or just real.

Download simplify_side_radical.mw

Here are a couple of ways to get such an effect.

Download expr_inert_mult.mw

You could do,

   (u->FileTools:-ListDirectory(currentdir(),'all',select=u)[])~(["*.dvi","*.pdf"])

or,

   (u->FileTools:-ListDirectory(currentdir(),'all',select=u)[])~(L)

where L is your list of strings with wildcards.

ps. You don't need to right-quote the global name select, which is protected. If you're operating within a proc with a local by that name then use :-select. The usual story.

pps. I half expected to see something like select=".*\\.(dvi|pdf)$" work, as there is mention in the ListDirectory help-page of StringTools and its WildcardMatch, which in turn mentions RegMatch. This not so nice,
     select[2](StringTools:-RegMatch,".*\\.(dvi|pdf)$",FileTools:-ListDirectory("."))
and it's also more work to build up the pattern if there are many allowed extensions.

Your Question doesn't mention whether you mean the limits for the Java GUI, or for the kernel/engine (mservers) that do the computations. They have separate settings and options to control them.

See the Maple launch script options, and/or kernelopts Help page.

That launch script Help page unfortunately lacks mention of its -j option, for the Java GUI, which Rouben has mentioned. See also the kernelopts choices limitjvmheap and jvmheaplimit.

The launch script's -T option allows for specifying limits for the kernel/engine. See also the kernelopts choices datalimit and stacklimit.

You can also call simplify after calling solve. You could do each separately (with the assumptions), or nest the calls.

The empty brackets [] means that there is no solution for that case.

Also, you don't need to do the term cancellation stuff you asked about, to solve the inequality for Cv.

Download Q_12_ac.mw

Why do you have a condition on g2?

If you wanted, you could also replace the final conditions in the piecewise answer. Eg, you could replace them after solving them for R0m. Eg,

Also, the name Ce only appears in an identical amount (ie, with the exact same coefficient, if collected) on both sides of your given inequality. So the given inequality doesn't provide any stipulation or restriction on Ce. Hence, trying to solve the inequality for Ce won't tell you anything about Ce.