Some time (but not today!), I would like to post some measurements on efficiency that show something that few people really understand about Maple, and that is the effect of memory allocation on run times.
Clearly, wild allocations take time (to do and to collect), and that shows up in the posts above. In fact, I am quite sure that the actual assignment to a list is exactly as fast as that to a vector, and that the apparent slowness of the list version is all due to memory (ab)use.
But much more subtle is the fact that if you run a normal (symbolic) maple command that takes >1 second
1) in a clean environment
2) in an environment where all sorts of unrelated computations have been done [say where memory alloc is now 100 Megs],
then that same command will be measurably slower in case 2. In fact, by increasing the amount of unrelevant other computations (to augment memory alloc, as well as memory fragmentation), this gets more and more pronounced.
One word of warning: the effect will be different if one causes memory to be allocated in large chunks versus small chunks.
Potential conclusion: don't use Maple for extended periods of time without doing save+quit+restart, else your "working environment" will ever so gradually get slower and slower.
This is, by far, one of the stupidest features of (recent) Maple. It encourages bad habits, and it is by definition not scalable.
And yet, it is used in the Maple library, only to bite unsuspecting users at odd times. Any use of it should spit out reams of impossible-to-turn-off warnings.
This is, by far, one of the stupidest features of (recent) Maple. It encourages bad habits, and it is by definition not scalable.
And yet, it is used in the Maple library, only to bite unsuspecting users at odd times. Any use of it should spit out reams of impossible-to-turn-off warnings.
'while' is part of the core language, and has been there since 1980. The basic descriptions are over 20 years old, and no one has really complained, so this probably has not hit anyone's radar. You are right that the description is very 80s computer-science style.
Take a look first at ?infolevel (which brings up the userinfo page, it's in there). If the developers have put in enough messages in dsolve (there are indeed quite a lot), then you'll get a fair amount of information.
If that is not sufficient, then you can get all the gory details through 'printlevel', but that is likely to be serious overkill (?printlevel for details).
If you post your exact problem, there are many of us here who can decipher dsolve well enough to tell you how it's done.
In the following worksheet
Download 130_MP_MatrixQuestions.mwsView file details
you can experiment easily with various sizes of n and get the inverse. For n=5 the pattern of entries is already quite obvious! You ought to be able to formulate a conjecture from that, and then I would think that a proof by induction would be relatively straightforward.
As far as I know, there are no computer algebra systems out there which have any tools at all for "symbolic" matrices [ie matrices whose dimensions depend on a symbol, and whose entries are formulas].
In the following worksheet
Download 130_MP_MatrixQuestions.mwsView file details
you can experiment easily with various sizes of n and get the inverse. For n=5 the pattern of entries is already quite obvious! You ought to be able to formulate a conjecture from that, and then I would think that a proof by induction would be relatively straightforward.
As far as I know, there are no computer algebra systems out there which have any tools at all for "symbolic" matrices [ie matrices whose dimensions depend on a symbol, and whose entries are formulas].
Your InnerProc, in old enough Maple (say Maple V Release 2), would have been global by default. It was extremely controversial (at the time) to have syntactically visible assignments in a procedure turned automatically into a local.
This ``feature'' had two side-effects, one good, one bad: one is that you had fewer global variables around, the other being that people could now be sloppy and not have to declare their variables.
A compromise was reached to issue a warning when Maple 'adjusted' the semantics of your variables for you.
Your InnerProc, in old enough Maple (say Maple V Release 2), would have been global by default. It was extremely controversial (at the time) to have syntactically visible assignments in a procedure turned automatically into a local.
This ``feature'' had two side-effects, one good, one bad: one is that you had fewer global variables around, the other being that people could now be sloppy and not have to declare their variables.
A compromise was reached to issue a warning when Maple 'adjusted' the semantics of your variables for you.
It is understandable that Classic falls behind in features, but I am disappointed that cmaple is also left behind. I know of a lot of people who do very serious computations with Maple, computations that take days, and can produce huge amounts of output, including hundreds of plots. It is not possible to use any GUI to do that, as the human labour would be enormous. So it has to be done in 'batch', something Maple excels at. But now you're saying that if I try to do real 'serious' work, I lose in quality? Somehow, that does not seem right!
It is understandable that Classic falls behind in features, but I am disappointed that cmaple is also left behind. I know of a lot of people who do very serious computations with Maple, computations that take days, and can produce huge amounts of output, including hundreds of plots. It is not possible to use any GUI to do that, as the human labour would be enormous. So it has to be done in 'batch', something Maple excels at. But now you're saying that if I try to do real 'serious' work, I lose in quality? Somehow, that does not seem right!
There is a 'copy' command which you would expect does that... but it only works for some structures. I could not find a routine in the library to do this, so here goes:
copy_record := proc(r)
Record(seq(v=r[v], v in [exports(r)]));
end;
and now
rec2 := copy_record(rec1);
works as you expect.
There is a 'copy' command which you would expect does that... but it only works for some structures. I could not find a routine in the library to do this, so here goes:
copy_record := proc(r)
Record(seq(v=r[v], v in [exports(r)]));
end;
and now
rec2 := copy_record(rec1);
works as you expect.
> h := hypergeom([1,3],[2],x):
> simplify(h);
x - 2
- ----------
2
2 (x - 1)
[I realize the above is not a polynomial, but the Euler transform does introduce that denominator]
Note that is often a really bad idea to 'encode' an integer as a float. It tends to hide singular cases (ones where the condition number is essentially infinity).
Floats and 'exact' numbers are extremely different, and Maple treats them so. This distinction is usually not made in most undergraduate classes, and that's a pity, because it makes using a system where this fundamental mathematical fact is front-and-center rather surprising.
