You should certainly read the help page ?RootOf Basically a RootOf represents an (algebraic) inversion. For example, RootOf(_Z^3-2) represents a cube-root of 2. But it can really represent the inversion of anything.

Note that what he has is diff(f(t),t)^(n+B), so that the order is one, but the degree is higher. So he has enough initial conditions (in theory). Now, it is quite possible that this ODE is singular at 0, so it is quite difficult for the numerical method to even get started.

Note that what he has is diff(f(t),t)^(n+B), so that the order is one, but the degree is higher. So he has enough initial conditions (in theory). Now, it is quite possible that this ODE is singular at 0, so it is quite difficult for the numerical method to even get started.

If you could supply values for El, EL, Eu, and KT, I would like to play around with the problem some more. There is not much chance to solve this symbolically though. Nevertheless, one might be able to get some symbolic-numeric approximant.

If you could supply values for El, EL, Eu, and KT, I would like to play around with the problem some more. There is not much chance to solve this symbolically though. Nevertheless, one might be able to get some symbolic-numeric approximant.

Your observation is correct - issues of numerical errors from Maple's internal algorithms are not explicitly documented (anywhere). This comes from Maple arising from the symbolic community, where answers are either right or wrong, never right up to a known Error! So while issues of numerics are taken very seriously by its developers (now and for the past many years), that has not reached deeply into the documented (yet!). Data analysis in Maple is a bit more finicky than it should be - especially when dealing with complex values. But the various Maple books are fairly good guides at explaining how to do it. Now, for some algorithms, there are information messages (see ?infolevel) that will output, amongst other things, the computation error. And as a last resort, you can look at the source! See my post on old timer techniques for details.

One can have endless fun if, instead of using the blank function (``) unevaluated, one instead gives it an actual value. Depending on the value, this breaks many different parts of Maple in all sorts of hilarious ways. The resulting error messages can really be a hoot.

One can have endless fun if, instead of using the blank function (``) unevaluated, one instead gives it an actual value. Depending on the value, this breaks many different parts of Maple in all sorts of hilarious ways. The resulting error messages can really be a hoot.

evalb can sometimes return 'unevaluated', where the if statement in the same situation would throw an error. Informally one can say that if the question was meaningful, then evalb and if will agree. Only when you are dealing with expressions that are dubiously meaningful like comparing complexes with < (where the tri-valued logic of evalb works differently than an if's two-valued interpretation), or when asking even less meaningful questions, like having a free variable in a boolean query (where evalb will return unevaluated and if will give an error). One could argue that Maple is very creative with the diversity of its GIGO behaviour! PS: Thanks for the clarification, I think MaplePrimes readers will appreciate it.

evalb can sometimes return 'unevaluated', where the if statement in the same situation would throw an error. Informally one can say that if the question was meaningful, then evalb and if will agree. Only when you are dealing with expressions that are dubiously meaningful like comparing complexes with < (where the tri-valued logic of evalb works differently than an if's two-valued interpretation), or when asking even less meaningful questions, like having a free variable in a boolean query (where evalb will return unevaluated and if will give an error). One could argue that Maple is very creative with the diversity of its GIGO behaviour! PS: Thanks for the clarification, I think MaplePrimes readers will appreciate it.

What Mariner says is true, but with more details about what you are doing, you could probably get a lot more help from the various Maple experts here. Optimizing Maple code is still a bit of an art form. However, because most of the Maple documentation out there optimizes various things (sometimes it is understandability, sometimes it is marketing-bang, etc) and rarely optimizes efficiency, especially memory efficiency, it is quite difficult to learn this art other than through long, laborious and painful trial and error. Or you could ask the (bruised) experts on MaplePrimes!

What Mariner says is true, but with more details about what you are doing, you could probably get a lot more help from the various Maple experts here. Optimizing Maple code is still a bit of an art form. However, because most of the Maple documentation out there optimizes various things (sometimes it is understandability, sometimes it is marketing-bang, etc) and rarely optimizes efficiency, especially memory efficiency, it is quite difficult to learn this art other than through long, laborious and painful trial and error. Or you could ask the (bruised) experts on MaplePrimes!

If you have a subscription to the ACM portal, then the official page for the paper contains a link. The paper does not seem to exist anywhere else on the Web.

This post itself will muck things up, but apparently the 'gold' Maple Rank is off-by-one? I got my 'silver' ranking when I reached 80 points, but now I have 200 and still silver. Of course, this post will give me 201, so that will likely change things.

gc() is an explicit call to the garbage collector. Since maple does implicit memory allocation and de-allocation, there are times where it is a good idea to explicitly call the garbage collector. But this mostly happens when one is trying to get good memory usage data, or in very complex computations where one knows a lot of memory can be reclaimed. I have been using Maple for 21 years now(!), and I still can't reliably predict its memory usage patterns, never mind when to explicitly call gc. I could tell you about memory usage patterns for older versions, but just enough things change (in the kernel) every new version of Maple that this knowledge becomes obsolete very quickly. And since such knowledge seems to take more than 1 year to properly 'gel', this is rather transitory information!