I did not say "avoid document mode", just that I don't use it as I do not personally find it useful. I would probably go further and say that any sufficiently advanced user of Maple will not use document mode either. But I will not be more categorical than that.

I did not say "avoid document mode", just that I don't use it as I do not personally find it useful. I would probably go further and say that any sufficiently advanced user of Maple will not use document mode either. But I will not be more categorical than that.

It is software to help you do all sorts of mathematics, university-level math. And it really does help you - this is what this site is for, to help people with Maple. It is a complex piece of software (no matter what the marketing says), so some community help comes in handy.

While you will find a lot of people here quite willing to help (and who love math!), you will find even more help for maple-specific questions.

Planck's constant is a physical constant which in particular means that it is only known as an approximation. So it is not possible to tell what it really is, since it can never be "fully" known. For an introduction, see either the wikipedia article or the mathworld page. Or you can even ask maple (type ?definition,transcendental, and voila!).

It appears that there is an apostrophe, as well as backquote and forward quote available on his keyboard! That would be the problem indeed. The person is experimenting (or trying to) with ' and `, and the results are as you see them.

It appears that there is an apostrophe, as well as backquote and forward quote available on his keyboard! That would be the problem indeed. The person is experimenting (or trying to) with ' and `, and the results are as you see them.

Some of the things inside Statistics are local variables of the respective modules, and you can't see their values unless you use kernelopts(opaquemodules=false). Modules being opaque by default is very good from a software engineering point of view, as you do want code to be as opaque as possible (information hiding and all that good stuff). But when you are debugging, all these things seriously get in the way. In this respect, Maple strikes a really nice balance.

You should read my blog post on old timer techniques. You can use printlevel or CodeTools[Profile]() to get results about absolutely everything (dynamic trace). This can be a lot of data. Or you can look at the code. You'll need to dig around some, but these were what I did: > with(Statistics): interface(verboseproc=3): kernelopts(opaquemodules=false): > showstat(Range); > showstat(Statistics:-Quantities:-GetValue); > showstat(Statistics:-Quantities:-GetValueTab[DescriptiveStatistics]); which was enough to show me all the overhead incurred. One can continue to dig too.

If you trace through what all Range does (for example), you'll see that it spends well over 90% of its time parsing its arguments, dispatching to the right routines (dynamically), setting up complicated options, before finally doing the computation. The other commands are likewise. Basically you are feeling the cost of implementing a very feature-full package (like Statistics) in a dynamically-typed, interpreted language like Maple, where the implementation is done using a lot of (clever!) dynamic dispatch techniques and generic programming ideas. MathCad is faster because it has fewer features, and those features are implemented in a compiled language. That means that, in the long run, Maple will gain more features faster than MathCad, but is likely to remain a factor of between 50 and 200 times slower on computations like the above. Unless of course those routines are re-implemented in the Maple kernel, at which time they will be competitive with MathCad's, but the development cost will be quite high (i.e. unlikely to happen soon, IMHO).

I used to be a big fan of that feature too, and sometimes still use it. Up until I discovered that there are a few Maple data-structures which do not have a well-defined textual representation, so that what was saved as text was only close to a proper representation rather than being a faithful representation. Those data-structures are easy to spot: they are the same ones which are difficult to cut-and-paste between different versions of Maple. Try to cut-and-paste from a version of Standard to a version of Classic and you'll see what I mean. Or to a text editor.

The old save, if given just one argument, will do just that - gather everything in the current namespace, and save it out. However, the reason this functionality is not recommended is that this can include huge portions of Maple's own library! [Maple's extensibility model makes it so that it is not easy at all to tell between user functions and library functions].

As many posters on other threads have already pointed out, Maple's documentation has serious problems regarding linking, especially for older pages. Newer pages tend to link to old ones, but old ones are rarely updated to point to newer ones (or at least it seems like that). This is definitely counter-productive regarding users being properly steered to newer features. As Roman pointed out, save has some features that LibraryTools:-Save might not have. The help pages are not clear on this.

save and read are the old way to do things... The modern way is to use similar facilities in the LibraryTools packages. Of course, LibraryTools:-Save is just a fancy interface to save, however it does do a lot more error checking, so that if something goes wrong, you have a chance to find out. When save does not work, if you're lucky you get an error message, and if you're a Maple guru, you might just be able to interpret what it means. [Ok, so you are one of those - but your audience isn't!]

That function might help, or others linked from it.