Download rep_dec.mw

There are quite a few alternatives. For example, (using textplot rather than as a title, since you did),

   plots:-textplot( [ 3 ,3, Typesetting:-Typeset(A^``(1))(x) ] )

I didn't check for very high efficiency, though I made a few tweaks (putting the digits in sets, using ormap for quicker bailout instead of nops, etc).

What size of sets, and how many, do you need to handle?

A := {12, 17, 24, 28}:
B := {358, 568}:

TA:=table([map(a->a={StringTools:-Explode(convert(a,string))[]},A)[]]):
TB:=table([map(b->b={StringTools:-Explode(convert(b,string))[]},B)[]]):

{seq(seq(`if`(ormap(member,TA[a],TB[b]),
              NULL,parse(cat(a,b))),b=B),a=A)};

           {12358, 12568, 17358, 17568, 24358, 24568}

I didn't test whether parse(cat(a,b)) is a near-optimally efficient way do the blend. (I don't know whether all the second set's values will be of the same length, and that knowledge may bring improvements.)

For some kinds of problem like this the best approaches depend on the example class. One approach might be better for doing very many smaller examples, and another approach might be better for doing even a few very large examples. We haven't (yet) been informed of such details. Without knowing, there's less point in comparing the ormap'd member versus set intersection.

[edit] The above code rejects the unwanted results during the formation of the cartesian product. That's in contrast to, say, forming the whole cartesian product and only afterwards removing the unwanted values. Sometimes (but not for this small example) the whole cartesian product can be prohibitively large.

You could fill out the form for a Software Change Request (a euphemism for "bug report").

(Don't worry that it appears Maple-specific. Some person should read it and assign it appropriately.)

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.