It is well-known amongst numerical analysts that those 500 year old formulas for the roots of a cubic are numerically very ill-behaved. But 500 years of tradition are very hard to change, so the better formulas (involving arctan) are not used, because they are not the ones that show up in textbooks. One day, some system builder will feel brave and buck the tradition and use a better, more modern (only ~120-150 years old!) formula instead. Ah, the day that computer-based mathematics system actually uses mathematics that is as young as 100 years old uniformly and correctly, that will be a joyous day.

It is a software engineering disease to fold "feature requests" and "bugs" under the same heading of SCR, a fairly common terminology. But it is quite silly, as the prioritization and management of bugs and feature requests are quite different, end up on different schedules with different timeframes, etc. They may appear rather similar from a surface point-of-view, and it might please bean-counters to have just one management system, but it makes the life of a project manager very difficult to lump these together. I know both of you have been indoctrinated with this system for quite a long time, so you might not have had the time to sit back and ponder whether the axioms underlying SCRs as unifying all "change requests" are actually sound. From my experience, they are not.

For those of you who are puzzled about the terminology used (ie 'tracked'): Maplesoft uses a bug-tracking system called "Tracker", so that it became natural lingo to say that a bug was 'tracked' once it was entered into "Tracker". If you hear about SCR numbers, that's "Software Change Request" [since some really silly people consider it to be bad to openly admit that a piece of software actually has bugs!].

I could easily create a "virus" in Maple, and hide it fairly well in a .mw file. There are maybe 25 people in the world who could do that, with at least half of them working at Maplesoft, another few active on this list. In other words, it does seem like serious overkill to me. I would not blindly run any .mw files with 'hidden' or 'closed' document blocks - that's just asking for trouble. They are unlikely to contain anything harmful, but they are likely to contain code that will make the rest of the document impossible to understand if you don't know what that does. I don't run Excel Spreadsheets with embedded VB code either - too much black magic for my taste there too. I try to avoid spreadsheets altogether, but am less successful there. I do allow JavaScript in my browser. I am about to shut off Java in my browser -- that's an essentially dead technology in browser-land.

I was able to reproduce the first one [didn't try the others] in TTY Maple 10. So it's definitely a deep bug that is not new. Ouch.

For the maple view of that, see ?LinearAlgebra,LUDecomposition. Given a matrix A, it is always possible to factor it as A.P = L.U, where P is a permutation matrix, L is lower-triangular with 1's on the diagonal, and U is upper triangular. Then the determinant of A is simply the product of the diagonal elements of U. The process which gives this factorization is none other than Gaussian Elimination (with pivoting).

reduce_opr is a new builtin that was added to Maple after my time -- I have no idea what it does, and it's not documented. Since we can't peek at the kernel source to find out, our only hope is that someone from Maplesoft will reply to this one. reduce_opr might also do some quite useful transformations that should not be lost.

I believe that this is an example of planned inconsistency. The developers know that the 'core' functionality is weird, so in a setting where 'weird' is unacceptable (like education), task helpers and the Student package and ... contain reimplementations (or hacks around) some internal functionality, to get around 'weird'. Of course, this creates inconsistency, but at least if you stick to the most-recently-coded way of doing things, things are less-weird. But think about what the real cost of this is: all this time that the developers are spending re-implementing core functionality in some dark corner of Maple is time not spent improving something else. Worse, because these pieces of code are buried in strange places, they can't easily be re-used, so these hacks are actually re-implemented multiple times! And of course, the hacks are frequently library-level code, getting around kernel code, with all the inefficiencies that that entails. This is the real, tangible cost of backwards compatibility with broken features and antiquated designs - bloated code, slower development, painful maintenance. In other words, the wonderfully talented and eager-to-improve-Maple developers at Maplesoft are slowed down tremendously from doing what they would like to do for the customers by bad decisions made sometimes 2 decades ago. [I have heard this directly from multiple developers]. This 'planned inconsistency' is the best they can do under the circumstances.

What Maple is doing is called eta-reduction. This is the rule that, in the lambda calculus, x->f(x) = f. However, this eta-reduction is implemented in maple in a fragile (as you note above) and ultimately annoying way. What you are asking is that you would prefer eta-expanded versions, especially if the input had explicit parameters. And this makes sense, because Maple is much stronger in manipulating functions containing expressions than expressions that denote (pointfree) functions. A function is pointfree when you do not need to name its parameter. The big problem is that people who implemented eta-reduction did so because they were really smart and had just independently re-discovered this feature of the lambda-calculus. So they did not know to look in the fast literature on this topic, which would have warned them of the weird side-effects you are noticing above. It is also worth noticing that this was much worse before Maple 6, where if you try your tests you'll get even more puzzling results. We fixed as much as we could at that time, but missed some cases.

Using the same R and f as above, change L to

L := proc(f::procedure, u::name, nn::integer)
    local i, y, F, uu;
    y := Vector(nn, j -> uu[j]);
    F := f(y);
    unapply(add(eval(u[i](y))*diff(F,uu[i]), i=1..nn), uu::Vector)
end;

then calling L(f, R, 4) will return uu::Vector -> uu[2]*(-1-uu[3]^2)-2*uu[4]*uu[1]*uu[3] as wanted.

Well, I own the Maple 3.3 guide, which was published in 1985, and it had a section on programming. The first separate book on Maple programming seems to have been published in 1996 [see Keith Geddes' page for details); that book has been continually updated since, and that's the book you are now reading.

Newton's method would be by far the simplest way to go, and if you have good starting points [which you do], then it will assuredly converge, and apparently quickly too. What you could consider doing is using code generation to hard-code a Newton's step instead of going through the usual indirection.

There's two things about Beta testing of any product [this is by no means specific to Maplesoft]: 1) different users have wildly different usage patterns. So depending on the size of the pool of beta testers, quite a few ``obvious'' bugs can slip right through because no one in that pool used those features at all. 2) not all bugs encountered during Beta get fixed - then, or even in the next release, or the next... what gets fixed depends on a prioritization done by various "project management" people. More generally, some "obvious" bugs are sometimes also there by design, and these are then much harder to get "fixed". The reason? Mainly that the developers are not actually users of the product themselves [or the few that are, their usage patterns is very far from typical], so they design what, in all good faith, they personally believe to be "useful", only to be shown spectacularly wrong later. Of course, since such things involve the ego of actual people, these kinds of wrong-by-design problems are very hard to get fixed, it takes enormous user pressure. I will say this again: this is standard at all software shops that make shrink-wrapped software, and is well documented in the software engineering literature. The solutions are also well documented: makers of shrink-wrapped software [that do not wish to go bankrupt] will always react to economic pressures (from its customers), and will usually react to negative publicity (that its customers might read).

First, it would be nice if you could upload a worksheet with all the equations, that way people here can experiment. Second, it would be good to know what the parameters are really like -- are they fully general, or are there "relations" between the parameters that hold? [Usually, in physical situations, this is the case]. These relations are often the key to getting a nice reasonable solution to a problem. If nothing else, it would be nice to know if all your parameters are real (or even positive!), as again that has a large impact on possible solutions. Finally, the best way to solve such systems is usually to first turn the sines and cosines into new symbols (say s1 and c1 for sin(theta1) and cos(theta1)), and add the equation s1^2+c1^1-1 to your system.

Another (new) phantom user, OgdQnCrEAzYShxYM apparently has 37 blog posts (of which I can find none). Seems mapleprimes.com is getting hacked!