You have sys_ode and ics both as sets. You need to merge those into a single set when passing to dsolve, instead of forming a new set of (those two) sets.

There are various ways to do that. eg,

   dsolve( sys_ode union ics, type=numeric)

rather than your,

  dsolve({sys_ode,ics}, type=numeric)

SWB_ac.mw

Alternatively you could have created both sys_ode and ics as just comma-separated sequences rather than as sets (ie. without wrapping their definitions in squiggly braces), and then used your original  {sys_ode,ics}.

In your problematic example the first argument to algsubs is not as it seems.

Yes, the LHS looks like an atomic identifier (MathML-like blob of a single name, marked up as 2D Input) that renders in black like sigma' . But it has a difference.

But it seems that atomic identifier in that input actually has the attribute mathcolor="blue" interspersed within that marked-up name. We don't see the difference in what's rendered, because as 2D Input it gets rendered in black. So it merely looks like the sigma' that you're trying to replace.

Here's a version where I re-entered that whole first argument to algsubs.

Download p151_ac.mw

I don't know how you fell into the problem (cut&paste, some bug, something to do with your custom coloring of input or character Style, I don't know...) so it's hard for me to suggest how to avoid it -- except possibly to avoid the custom coloring/style or copying from the output.

I suppose that you might also fix such an inadventant problem example by converting it in-situ to 1D Input (right-click menu), carefully amending the atomic identifiers, and converting it back to 2D Input. That seems tedious. Bt in this example it is a way to see the underlying difference.

Personally I prefer not to use 2D Input, in part because I don't like that what you see is not always what you get.

You can issue the command,

  [exports(GroupTheory)];

to get a list of the exports of that package.

You could also call sort on that list.

There are lots of variants on displaying that list. It's not clear to me whether you merely want it displayed nicely/usefully (and, for a general package, to sieve out anything not a documented/callable command) or whether you want to further manipulate/use the names programmatically.

It seems to be a consequence of the new (Maple 2022) default for the adaptive option. That behaves like adaptive=geometric here.

If you force (the old default of) adaptive=true then that artefact doesn't appear.

ps. In Maple 2021.2 you can reproduce the artefact for this example, by suppling a (now defunct) variant of that option (then-undocumented), adaptive=plotthing
pps. For this example I am not seeing that artefact when using a Beta version under development.

Download Equation_1_Worksheet_ac.mw

lst := [`A=70`, `B=17`, `C=27`, `D=37`, `E=74`, `F=57`, `G=67`, `H=08`,
        `I=81`, `J=28`, `K=38`, `L=48`, `M=58`, `N=68`, `O=90`, `P=19`,
        `Q=29`, `R=39`, `S=49`, `T=59`, `U=96`, `V=010`, `W=110`, `X=210`,
        `Y=310`, `Z=410`, "SPACE=105", "DOT=106"]:

tt := table(parse~(lst));

For some reason the typesetting system is going awry on 2D Output display of the series structure returned by the taylor command. The computation might proceed, even if you cannot print that structure.

It appears to print ok if you convert that series structure to a polynom (which I expect you'd probably want to do anyway).

maple_primes_question_ac2.mw

I don't really understand your goal with indefinite integration here.

Is this the kind of effect you're after?

Q_2024-02-15_Help_Spread_diagram_ac.mw

Note that the lowercase typeset you were using is not an export of the Typesetting package. (Though Typeset is.) So merely loading Typesetting has no effect, because nothing different gets called.

However if you were to instead replace that lowercase typeset with Typesetting:-Typeset then you'd get the effect of the infix `.`, however it would render in gray not black because you're using the inert %. .

The Display command from the InertForm package does allow you to get the infix %. calls with the dot rendered in black (while also typesetting it all to some MathML-like form).

You could also use the operator-form calling sequence of Int.

Sometimes I use that instead of conditionally returning 'procname'(...) because the syntax is simple. Also, it can still let the integrand be evalhf'ble which sometimes (but not always) makes a speed difference.

However using operator form can get tricky if there are nested Int calls that cannot/shouldn't be collapsed. Then the approach of conditionally returning unevaluated is very useful. And the procedure z could itself call evalhf, so that aspect is not a barrier.

Stuffing in uneval-quotes is my least favored approach. They are ephemeral. Ostensibly simple adjustments to the approach can break due to some overlooked extra evaluation which strips off a pair of such quotes. If you're lucky you get a thrown error when that happens, and if unlucky a wrong result. It is the least robust approach.

Download Int_uneval_ex.mw

ps. On a separate note, these procedures z use the name x as a variable of integration. I suggest that you declare that as a local, to avoid collision with x possibly defined at a higher level. Or you could operator-form calling sequence for fsolve.

In your example the expression assigned to y involves the call g(x). So you could prevent f(x) from evaluating to F(x) when you substitute f for g.

Or you could also substitute (f@@(-1))=(F@@(-1)) .

Or you could instead substitute g for f, since g is unassigned in your example

Download inv_eval_ex.mw

Certainly you wouldn't want those complicated conditionals repeated over and over.

Some code that processes the alternates and gets a canonical form (one of your "Red", "Green", or "Blue") can be a way to deal with this. Then you only need to hard-code the alternates in that single place.

One common approach is to do that processing at the start of the procedure body. Then assign the result of that to some local name. And then reference that local instead of the parameter name, throughout the procedure. (I expect that you already know that you could do that. It's not slick or super convenient to write, but it works.)

But quite a few flavours on this theme could also be handled by using the coercion parameter modifier.

Here an example that also allows other mixed upper/lower case spellings. (You could tighten that up to just your original, if you wanted...)

Download coercion_ex.mw

There are several behaviorally different variants on that. I don't know how you might want additional arguments handled, if they don't match at all. I don't know if you'd want it to throw an error, or return "Blue", or pass it over, etc. Some extra juice can be wrung out, according to whether you make the param-specification of s be tighter, or do something else as the default value of the piecewise, etc.

note: you might not be able to make such a coerced parameter be treated completely like an optional ordered parameter (in the sense of skipping over arguments). It may absorb an argument. That might be ok for your purposes.

The re-usable part, that you've called a "script", can be implemented in Maple as a user-defined procedure.

Afleiding_Euler_knik_2_staven_inc_rotveerRev_3_ingekort_mapleprimes_ac.mw

You may use the numapprox package to construct a rational polynomial that approximates your f (up until its slope gets acceptably small...).

We can start from a small positive value, since not everything here behaves so nicely at x=0 exactly.

I did not raise Digits here. If you plan on exporting the resulting expression into some external application that can handle float double-precision (eg. compiled code) then you could try setting Digits:=15 and see if better accuracy attains (depending on degrees requested).

Download approx_ac.mw

Above I requested chebpade construct a polynomial (degree in denominator as zero). Often one can do better with a rational polynomial. There are also other commands in the numapprox package which might be useful to you, depending upon your example and target criteria.

Download approx_ac2.mw

[edit] I gave this answer because of the following preceding detail from the OP. Up until this time there had been no mention by the OP of obtaining good asymptotic matching. As described below the posed problem had been about getting an accurate match up until some cutoff value:

"Let's say I still wanted to obtain an approximation for f(Gamma) for Gamma from 0 to that Gamma sending f(Gamma) relatively close to sqrt(5)/5...Such approximate polynomial should be a very simple (no more than one line) function of Gamma that well captures its original shape up to the point it starts stabilizing at sqrt(5)/5 (very roughly at which Gamma?). How would you do this?"

The goal of obtaining matching asymptotic behavior (as x tended to infinity), which can involve quite different methodology, was only agreed with later by the OP.

You have not shown us any definition of (or assignment to) xA||i and yA||i for i=1..6. You should explain that.

Download LA_Jamet_ex.mw

The cost of the overhead of wrapping an expression sequence in square brackets -- obtaining a list -- is small.

And then you can use either numelems or nops.

Download numelems_seq_list.mw