@necron I have used the DirectSearch package with several different algorithms (Powell, Brent, cdos) completely different from the Newton-Raphson used by RootFinding:-Analytic. I've searched extensively in the square 0..Pi x 0..Pi using up to 400 randomly generated seed points. I can find no roots other than those found by RootFinding:-Analytic.

@John Fredsted The second argument to mtaylor is the set {diff(f(x),x), g(x)}. If this set were to be frozen, then mtaylor would think that its second argument were a single name.

I find that my main difficulty with setting up the third argument to frontend is that this argument specifies what's not to be frozen rather than what is. In this particular problem, the only things that need to be frozen are diff(f(x),x) and g(x); everything else is something to not be frozen.

Does "equal" mean that they are identical and have the same list position in the two lists? And if list position doesn't matter, why not use sets? Can there be repetition within the lists? Do you want to check for mathematical equality upon simplification, or is a simple identity check enough?

@Adam Ledger 

If you want to reset a global variable to its original definition at startup, then use kernelopts(unread= ...). For example,

freeze(x+1):
`freeze/count`;

     1

kernelopts(unread= '`freeze/count`');
`freeze/count`;

     0

So, the original value of the global variable `freeze/count` was 0.

@Adam Ledger First study freeze, then thaw. The freeze is very simple: It creates a name and stashes the original reference in the remember table of thaw. So thaw already knows how to revert all the frozen objects from its remember table. It only remains for thaw to map itself over all objects that contain the frozen objects. This is a very common model: A procedure has primary code to define its action on primary objects, then the rest of the code defines how that procedure maps itself over container objects. In the case of thaw, all of the primary action is covered by the remember table, so the entirety of the code defines how the code maps itself!

@John Fredsted For me, the trickiest part of using frontend is always getting that third argument just right. In this case, that's the [{`+`,`*`,`^`, set}, {}]. I welcome any suggestions for the simplification of this argument.

@Mariusz Iwaniuk These are useful worksheets! You should polish these and repost or put them on the Maple Applications Center.

But I need an explanation where the magic numbers 0.5017, 0.6407, 0.6122, and 0.2645*I come from.

See the Wikipedia article on Grigori Perelman. There seem to me to be two main motivating factors: A belief that mathematical prizes are unfair because they don't recognize the contributions of others, and, essentially, an intense hatred of papparazzi.

@nm I understand the desire for "plain text for input and 2D for output"---that's the only way that I use Maple---but why the classical interface? For one thing, the plots are much better in the standard interface.

I don't remember the details---they've been described here before---but there is a specific technical reason why it became impossible to maintain/update the classical interface.

@Allan Wittkopf , wrote, five years ago:

Sorry that the page is not easy to read - the problem is that there's just so darned much to pack in there, and events needed to evolve significantly over the last several releases, so the page grew and grew, so it's quite difficult to follow.

The exposition on the page may have grown and grown, but the examples have not. There should be at least one example for every option. By a very quick count (where I may have repeated some), I count 52 options described on the page. These options are by no means independent. So there's a myriad of meaningful combinations of the options.

No doubt, a great deal of effort went into developing the events system. That effort has largely gone to waste just because of a lack of examples on the help page. I think that there's only a handful of people in the world who understand it.

@taro No, I still say that you are correct that "% before ',' is missed, surely." Whether or not the page's author intended for a % to be there is irrelevant: it should be there. This trend of using equation label references in help pages is deplorable.

The English past participle missed has multiple meanings. It can mean overlooked or forgotten; it can also mean causes emotional pain due to its absence. By contrast, the present participle missing can only mean absent although it was expected without any emotional connotation (as far as I know).

Vote up. Yes, I've been waiting for years for many, many more examples to be added to that help page. There's about 10 times as many options listed as there are examples shown for. The descriptions aren't very useful to me without examples.

First, two small mistakes:

• ms at the end of Eq1 should be m*s.
• h at the end of Eq2 should be h(eta).

Now you need to solve for the highest-order derivatives, and then dsolve separately over the branches.

solve({Eq1,Eq2,Eq3}, {diff(f(eta),eta$3), diff(h(eta),eta$3), diff(theta(eta),eta$2)});
All:= allvalues(%);

Now, in the dsolve command, replace Eq1, Eq2, Eq3 with either All[1][] or All[2][], it doesn't matter which.

At this point, dsolve will complain about complex values. I don't know how to proceed from this point. Hopefully someone else does. Theoretically, it should be possible to solve a matrix-based system of linear equations even if the coefficients are complex.

You should avoid a potentially time-wasting option such as maxmesh= 10000 unless you're sure that it's necessary. If the option will help, dsolve will let you know that by giving you an explicit error message that tells you to increase maxmesh.

Using a simpler example if it's helpful, please explain how this set has anything to do with groups, bases, linear algebra, or echelon form.

A response to my Answer is expected.