As I am sure you have observed, in Maple 11, converting to piecewise on e does not work anymore (even when using the assumptions you gave). It can convert to piecewise based on s though. Let's assume that your piecewise above is called 'p'. Then one gets that convert(p, piecewise, r) assuming r>0; and convert(p, piecewise, r) assuming r<=0; both produce very small answers, which perhaps was what you were looking for? Unfortunately, for multivariate non-linear piecewise expressions, I do not know of any recipe. It seems that experimentation is where the state of the art is at!

Rewriting the Worksheet and XMLTools packages should not be that difficult (XML is fairly straightforward after all, and the worksheet DTD isn't too monstrous), but Typesetting is another beast altogether. Typesetting is an incredibly difficult task -- hey, it took Don Knuth a full 3 years of intense study and work to get to TeX, and he's got a Turing award. The various pretty-printers in Maple took roughly 7 years before they stabilized to something decent (and some are older than that but did not get the attention they deserved), and Typesetting is much younger than that.

At least 3 components have names: the interface, the kernel and the library. [There are tons more if you start counting each external library as separate, as well as the toolboxes, the calculator, the Reader thingy, etc]. Anyways, kernelopts(version) gives you the kernel version, the About box gives you the version of the interface (GUI), which is also what interface(version) gives you. And the new one is simply version(), which prints the version of all 3 [kernel, interface and library]. And, even though this is not documented, it appears that if you have any toolboxes installed, version() will print out that information too! The library version is apparently stored in the (undocumented) global variable _libraryversion.

Quick response now, I can turn this suggestion into code later, if someone else doesn't beat me to it. Basically, you need to first make sure you convert your expression into something linear in a set of independent bases. So if you will have a lot of irrationals, you need to convert to RootOf and normalize, to get rid of linear relations. Then you can safely replace every RootOf that's left with a fresh symbol (I would use subsindets for the latter task).

Quick response now, I can turn this suggestion into code later, if someone else doesn't beat me to it. Basically, you need to first make sure you convert your expression into something linear in a set of independent bases. So if you will have a lot of irrationals, you need to convert to RootOf and normalize, to get rid of linear relations. Then you can safely replace every RootOf that's left with a fresh symbol (I would use subsindets for the latter task).

If there is an external C routine for computing just this (as you show), then I trust that there is smarts in there. I know who wrote that code, and I would be willing to bet real money that the existence of this external routine implies smarts. For comparison: Labview 8 page on iCDF, Matlab's Statistics Toolbox, and the R quick reference card all have explicit names for these inverse functions (although R does mention quantile too). I also found a most horrible page that details how to do the same in SPSS. The page colours are awful, but note how long the explanation is, because the system is all pointy-clicky? But that's just because I looked in the wrong place, for example another document (p.6) gives the list of SPSS commands for inverse CDF - which also have individual names. Basically it seems that Maple is in the minority here, and other Statistics software provides direct names for these functions (however they up being implemented).

If there is an external C routine for computing just this (as you show), then I trust that there is smarts in there. I know who wrote that code, and I would be willing to bet real money that the existence of this external routine implies smarts. For comparison: Labview 8 page on iCDF, Matlab's Statistics Toolbox, and the R quick reference card all have explicit names for these inverse functions (although R does mention quantile too). I also found a most horrible page that details how to do the same in SPSS. The page colours are awful, but note how long the explanation is, because the system is all pointy-clicky? But that's just because I looked in the wrong place, for example another document (p.6) gives the list of SPSS commands for inverse CDF - which also have individual names. Basically it seems that Maple is in the minority here, and other Statistics software provides direct names for these functions (however they up being implemented).

How very silly of me to interchange those two arguments -- thanks for noticing. I guess I should stop for tonight, as I appear to be off my game!

How very silly of me to interchange those two arguments -- thanks for noticing. I guess I should stop for tonight, as I appear to be off my game!

Thank you, I really would not have thought of looking at Quantile for that functionality. And I might not be the only one. I wonder if Quantile has some built-in smarts to invert some CDFs, or if it simply plugs away using fsolve? Certainly many CDFs are extremely difficult to invert (numerically), so that specialized version would be both much faster and much more accurate.

Thank you, I really would not have thought of looking at Quantile for that functionality. And I might not be the only one. I wonder if Quantile has some built-in smarts to invert some CDFs, or if it simply plugs away using fsolve? Certainly many CDFs are extremely difficult to invert (numerically), so that specialized version would be both much faster and much more accurate.

There should definitely be an option to take limits over the integers. This occurs very often in real applications, which should really be the only concern of whether functionality is provided or not. Now, as far as I know, there are currently very few techniques known for computing such limits. But that just means that it is an open research problem -- and that there might be lots of techniques that work quite well, if only someone were to sit down and start seriously thinking about the problem. That being said, I won't be the one researching this. I have my hands rather full trying to do ``analysis'' by computer, and it is something which I think I understand fairly well. I do not understand things that are more akin to number theory (i.e. techniques to compute limits over the integers that are not just obvious retracts of techniques over the reals).

There should definitely be an option to take limits over the integers. This occurs very often in real applications, which should really be the only concern of whether functionality is provided or not. Now, as far as I know, there are currently very few techniques known for computing such limits. But that just means that it is an open research problem -- and that there might be lots of techniques that work quite well, if only someone were to sit down and start seriously thinking about the problem. That being said, I won't be the one researching this. I have my hands rather full trying to do ``analysis'' by computer, and it is something which I think I understand fairly well. I do not understand things that are more akin to number theory (i.e. techniques to compute limits over the integers that are not just obvious retracts of techniques over the reals).

From the various posts before, I was starting to wonder if I had goofed on this one. Luckily, I had not! We are instead in the presence of a hack (oft repeated in many pieces of Maple code, often with a different list of operators) to hard-code in a few known Maple functions which should behave as the lambda calculus says they should -- ie that bound names should not be visible outside the expression. For example, 2-argument eval (as well as Eval) are missing from the list hard-coded in assuming.

From the various posts before, I was starting to wonder if I had goofed on this one. Luckily, I had not! We are instead in the presence of a hack (oft repeated in many pieces of Maple code, often with a different list of operators) to hard-code in a few known Maple functions which should behave as the lambda calculus says they should -- ie that bound names should not be visible outside the expression. For example, 2-argument eval (as well as Eval) are missing from the list hard-coded in assuming.