I've used Maple 2024.0 here.

Download QuestionSimplifyMultivariateRationalFunction_ac.mw

Since simplify is not by itself (well, no longer, since M2023) finding the trig simplification then the key to my approach above is to force the trig combine of the sin and cos terms in the second expression. The subsequent trig expand gets the simpler thing with just cos.

I shall submit bug reports against the regression & weaknesses in simplify.

If you're going to use plot3d to construct 3d lines then you might as well pass the option grid=[2,2] and cut down the wasted memory. The default is [49,49], but you only need the end-points, so without that option your plot3d construction is unnecessarily about 25 times too big.

Similarly, if you're using spacecurve for mere lines and want solid colors then you could pass numpoints=2 to that command, again to avoid unnecessarily wasting time and space. (It's hard to measure the time gain, since the example is already very quick.)

That might all seem pedantic, but those kind of considerations can really come into play when one starts animating/exploring plots, etc.

But why not just use plottools:-line, with the two Vectors you already have? I mean, instantiating them both at the end-points for lambda. That get's that memory efficiency directly.

Download Perpendicular_3D_lines_ac.mw

You might be able to get by with,

     is(simplify(tmp - r) = 0)

quite often.

I'm not sure what you want, as "simpler".

I haven't included anything like alias or LargeExpression:-Veil.

But maybe there are some ideas here for you (including a variety of "expression size" metrics),
expression_to_simplify_ideas.mw

You also asked about this behavior in August, 2021.

Your call to the parse command constructs the global name `a`, which is not your procedure's assigned local a.

Download parse_ex.mw

Download parse_ex2.mw

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

Sometimes this confuses the counter.

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.

Download Curry_ac.mw

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.