## 30152 Reputation

18 years, 232 days

## MaplePrimes Activity

### These are answers submitted by acer

That post had several comments removed, on different dates. (Spammers seem to latch on to Posts more than Questions.)

Sometimes this confuses the counter.

## NULL...

If the values of b is NULL then the call test(a,b) makes test receive just a as passed argument, since the expression sequence a,NULL collapses here. So then the second positional parameter of test (its own b parameter) can take on its default value.

The spelling is NULL, not Null as you had it.

Also, you had a colon (statement terminator) immediately after the closing bracket of the parameter spec of the definition of the procedure assigned to test2. For 2D Input mode that forms an out of place statement (albeit empty) if you want to have the local declarations following that.

nb. This site doesn't render the 3,2 that gets printed as a side-effect of the r() call. But it does all show in Maple's GUI.

## NumberTheory...

 > restart;
 > with(NumberTheory):

 > q := RepeatingDecimal(1/12);

 > nrp := NonRepeatingPart(q, output=float);

 > rp := RepeatingPart(q, output=float);

 > q := RepeatingDecimal(1/112);

 > NonRepeatingPart(q, output=float);

 > RepeatingPart(q, output=float);

## alternative...

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) ] )

## how efficient do you need it?...

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.

 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.

## Software Change Request...

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.)

## sets...

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}.

## hiddent difference in 2D Input of sigma'...

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.

 (1)

 (2)

 (3)

 (4)

 (5)

 (6)

 (7)

 (8)

 (9)

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.

## exports...

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.

## table(parse~(lst))...

```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));
```

## series to polynom...

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.

## InertForm:-Display...

Is this the kind of effect you're after?

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).

## operator-form calling sequence...

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.

 > restart; J1 := proc()   local z:   z := proc(u) local x; fsolve(sqrt(x)=u, x) end proc:   evalf(Int(z, 0..1)) end proc: J1(); # 0.3333333333

 > restart; J2 := proc()   local z:    z := proc(q1, q2) local x;      exp(        2*(          fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = q1, x)          *          fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = q2, x)        )        -        fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = sqrt(q1), x)^2        -        fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = sqrt(q2), x)^2     )   end proc:   evalf(Int(z, [0.1..0.9, 0.1..0.9])) end proc: CodeTools:-Usage(J2());

memory used=2.35GiB, alloc change=68.00MiB, cpu time=22.24s, real time=22.02s, gc time=1.04s