The main limit is how much memory you have, and how much patience you have. Maple does have internal limits (for example you can set Digits past 268435448 on a 32 bit machine). However it is rare to have a machine (and an OS) which can actually handle memory allocation of that size.
For factorial, basically the hard limit is n! < 10^268435448, which translates to n ~ 37591796. But you will run out of memory and patience long long before that.
combinat may not always compute things optimally. You are frequently best off getting a symbolic representation of the number you are interested in, and if that number is huge, compute its logarithm instead of the number directly. Or even log log.
Note that, in this case, it was most likely the OS that caused things to go bad, not Maple per se. Some well-behaved OSes can deal with applications asking for massive amounts of memory, others will cause the application to crash.
The sum you give is divergent (Pi > 3, so Pi-3>0 and sum(a/x,x=1..infinity) diverges for all a>0 ).
Maple is very (very!) good at computations. It is of no help for ``proofs''.
The tools to solve your problem are buried under fancy names. See
?Ore_algebra and ?Groebner
With Ore_algebra and Groebner, you can 'triangularize' of any Weyl algebra (which is what you have). A GB computation for first-order linear systems is isomorphic to Gaussian Elimination. These tools work on the operators directly, as you ask. If you have problems figuring out how to use them, ask again, I will help you (a little later, when I have more time).
Also related are
?MatrixPolynomialAlgebra
?OreTools
Sort-of. One can certainly see map(f, -) as composition of (build @ apply(f) @ unfold) where unfold "takes apart" any compound data-structure, apply is your usual function application, and build is the data-structure constructor for the original data-structure.
Fancy explanation 1: map is the unique categorical function (ie Functor) which takes an F-algebra over sort 'a' to an F-algebra over sort 'b' via any function of type a->b.
Example 1: a 'list' is an F-algebra. mapping over a list means to apply to each element.
Example 2: any term algebra is an F-algebra. mapping over it means to apply to each inner operand (ie what maple does on terms that looks like MyData(x,y,z) ).
Fancy explanation 2: Given a type constructor T and a function a->b, then map is the unique (non-trivial) signature
map :: (a->b) -> T a -> T b
Example 3: if T is the identity, then map = apply
Example 4: if T a constructs the family of function (a -> c) then map = composition.
(Examples 1 and 2 can be translated to this too)
This high degree of polymorphism of 'map' is why it is so useful. This is called "parametric polymorphism", and has been a mainstay of functional languages (like ML and Haskell, but born out of their untyped cousins Lisp and Scheme), and has recently been added to Java and C#.
You should take a good look at ?LibraryTools. Or the one-stop-shop, the 'march' command.
Note: with will only work if the .lib file actually contains a package with the same name, otherwise it will throw an error. with is a 'convenience' feature only, it really "does" nothing -- except to severely polute the name-space.
assuming is a nice syntactic shorthand for a (local) assumption. The help page on assume details the kinds of assumptions you can make.
is is basically a little theorem prover which, under the given assumptions (either global or local), will return true/false/FAIL if it can prove that theorem to be true, find a counter-example, can't decide (respectively).
evalb (which is what, under the hood, 'if' uses) will decide if an expression is identically true or false, using just Maple's own evaluation mechanism, ie much weaker that 'is'.
Be careful though: 'is' is very powerful, which translates to sometimes being quite slow. One always has to pay somewhere, somehow, for extra power. Interactively, it is usually ``fast enough'', but used in the inner loop of a program, it can make a huge difference.
For one, see
my first answer. Second, it also depends on what you want to do with the boundary conditions.
People have asked for this feature before, but not that many. The computer algebra system
Magma can do that.
This is what Maplesoft designed it for. It should fit what you are doing completely. If you browse this site, you'll see that some of the old-timers don't like it (myself included) -- but that's because what they try to do with maple is 'different' than the task that document mode was designed for. It was designed for the use you describe!
If you encounter difficulties, ask - you'll get lots of answers here. If you encounter bugs, complain - you are in the target-market, so that if Maplesoft is going to be convinced by anyone of problems in document mode, you're it.
This one is tricky!
Note how in the first few lines, it calls evalf('BesselJ'(...))? Well, that calls `evalf/BesselJ` (which exists). But `evalf/BJ2` doesn't! So you can't blindly replace every occurance of BesselJ with BJ2, you have to figure out the intended semantics and make a choice.
Second, if you do that, you will run into another issue: BesselJ pre-loads some values into its remember table, so that BJ2(0,0) would not work. Use interface(verboseproc=3) instead of 2 to get that written out as well. A lot of code in Maple will not work properly if it is separated from its remember table entries.
That Testzero change will:
1) make your 'version' of maple quite a bit more powerful at times
2) make it a fair bit slower, in ways that will be quite difficult to trace
Your _Envsignum0 change may actually break some routines in mysterious ways. In theory, it shouldn't, but in practice, it probably does. It would be an interesting experiment (for someone at Maplesoft who has access to the full test suite) to run this as an experiment and see what happens.
Your gcfreq setting will speed up ~80% of the computations, but slow dow ~ 5%, and leave the rest unchanged. That 5% is hard to pin down.
evalf(Int(sin(x),x=0..4)) is plenty fast. Ok, so for really small, trivial integrals, numerical software is faster. But who cares, really?
For somewhat difficult integrals, maple will first try fast numerical methods, before falling back to hybrid symbolic-numeric methods that beat the #$%#$% out of the competition.
evalhf(sin(.25)) having 'more' precision than evalf(sin(.25)) only looks true. I know for sure that all digits returned by evalf are correct (when evaluating a single function), while evalhf is more prone to numerical issues. [The difference can be explained, but it is rather arcane].
If you want speed, consider using Maple's compile functionality, or its CodeGeneration facilities. If you need even more speed on a particular problem of interest where it really matters, ask. There are a host of techniques involving some symbolic steps, some code generation steps, and some numerical steps which, taken together, can really make things fast. There were some nice papers in the 2005 Maple Conference proceedings on this issue.
Maple also uses GMP internally, so there would be 2 different version of GMP linked-in to your application, and that is definitely likely to create problems if the maple version and the GMP version do not match. Now, there may be other problems as well, but I would investigate that first.
This is a complex enough problem that you really ought to contact Maplesoft's technical support (support@maplesoft.com) directly.
Maple can do this much more nicely with vectors:
vectorC:=Vector[row](4,symbol=c);
vectorE:=Vector[column](4,i->e[i-1]);
solve( vectorC . vectorE, e[1]);
I will let someone else answer the pointy-clicky part of your question.
In Maple syntax, you can enter this as
piecewise(x<2, x^2-5, x<5, -3*x-7, abs(x-2))
