Search on this for a post on 'save' by roman_pearce from a few days ago, he explains it well.

Depending on the theory of physics you subscribe to, there are different answers to your questions! First, it has been definitely established that the speed of light varies with the media that it travels in. So it is not 'constant'. On the other hand, if you look at the "expanded" (dynamic, kinetic) energy equation in relativity, I think you'll be able to derive the answer to your question: the kinetic energy of a particle of mass m[0] is m[0]/sqrt(1-(v/c)^2).

Doesn't that strike anyone as a real problem that it is the human who needs to be trained around a piece of software's idiosyncracies, rather than the other way around?

Doesn't that strike anyone as a real problem that it is the human who needs to be trained around a piece of software's idiosyncracies, rather than the other way around?

First, the tty version will not complain as much about incomplete lines, so this may be an issue. Another "problem" is that \ is 'escape' in maple strings, so that on Windows paths need to look like read "C:\\Program Files\\Maple 11\\TestProc.mpl"; [but the above should work].

First, the tty version will not complain as much about incomplete lines, so this may be an issue. Another "problem" is that \ is 'escape' in maple strings, so that on Windows paths need to look like read "C:\\Program Files\\Maple 11\\TestProc.mpl"; [but the above should work].

At the command-line: cmaple < BesselJ.mpl cmaple BesselJ.mpl cmaple -i BesselJ.mpl These all do slightly different things, each with their uses.

At the command-line: cmaple < BesselJ.mpl cmaple BesselJ.mpl cmaple -i BesselJ.mpl These all do slightly different things, each with their uses.

I completely agree with you that for distribution of fancy documents that contain (one shot) embedded code, the document blocks are quite nice. I just would not ever develop them that way! I would put together such a document after I was sure that the code was working well. Of course, for code with a bigger scope (like a package), this is not a good distribution method.

I completely agree with you that for distribution of fancy documents that contain (one shot) embedded code, the document blocks are quite nice. I just would not ever develop them that way! I would put together such a document after I was sure that the code was working well. Of course, for code with a bigger scope (like a package), this is not a good distribution method.

Maple code is stored in ASCII files ending with .mpl. These are edited with an editor like emacs or vim (or SubEdit or ...). The tty version is then used to verify that the code is syntactically correct. Mint is also used for further sanity checking. This code is then saved in a library (see LibraryTools). [Actually, more steps are done too, which are all straightforward Software Engineering, but the exact details of which are a competitive advantage of Maplesoft over its rivals.] The GUI is used for interactive exploration of ideas -- at which it excels. Some of these ideas might be around new code. The library where the code is stored is placed in 'libname', and then Maple auto-magically takes care of loading it in as you use it. Those techniques are used because: 1) they are foolproof, 2) they scale. The GUIs (both of them) are great for "problem exploration", and even for (on screen) "document preparation". However they should not be mistaken for development environments.

Maple code is stored in ASCII files ending with .mpl. These are edited with an editor like emacs or vim (or SubEdit or ...). The tty version is then used to verify that the code is syntactically correct. Mint is also used for further sanity checking. This code is then saved in a library (see LibraryTools). [Actually, more steps are done too, which are all straightforward Software Engineering, but the exact details of which are a competitive advantage of Maplesoft over its rivals.] The GUI is used for interactive exploration of ideas -- at which it excels. Some of these ideas might be around new code. The library where the code is stored is placed in 'libname', and then Maple auto-magically takes care of loading it in as you use it. Those techniques are used because: 1) they are foolproof, 2) they scale. The GUIs (both of them) are great for "problem exploration", and even for (on screen) "document preparation". However they should not be mistaken for development environments.

I was under the impression that you used evalf to ``verify'' the solutions, and got a small imaginary part. Sorry if I misunderstood. Yes, symbolically simplifying such an expression, say after you have applied evalc to one where the imaginary part is (symbolically) zero is very difficult.

I was under the impression that you used evalf to ``verify'' the solutions, and got a small imaginary part. Sorry if I misunderstood. Yes, symbolically simplifying such an expression, say after you have applied evalc to one where the imaginary part is (symbolically) zero is very difficult.

It is a well-known phenomenon that the usual closed-forms for roots of polynomials, even when the roots are exactly real, give complex parts which exactly cancel. But this cancellation is numerically very unstable, so pure numerical evaluation give (usually small) imaginary parts. There are known formulas that do not have this problem, but they don't agree with what is "in the standard textbooks", so users complain about that too [this was tried, and reverted].