@acer Any chance this (Routine to pull-in the CODATA constants) could be made available e.g. in the Application Center?

My reason for asking is twofold. First, as mentioned the data in Maple are not up-to-date. Second, unfortunately the ScientificConstants package tries to be too smart and expresses some constants as an expression involving others. This breaks when a new system of units is defined (a bug). But it is also wrong (even if it would work): the CODATA adjustment does this much better than Maplesoft could possibly do it and one should just use the CODATA numbers except in very, very special cases. Third, the numbers will eventually change.

It seems to me it should be trivial for Maplesoft to do something similar for each update of Maple.

M. D.

@acer Thanks for checking & confirming my observations.

It is actually kind-of sad having such an elementary thing go wrong. I believe I can work around this (by redefining m[e]), but I am not at all happy about this discovery. It means the ScientificConstants Package cannot be trusted. While I understand and accept that software is not perfect; this one I consider quite bad. Also unnecessary and probably fairly easy to fix (unless the whole package is really nadly done).

I'll probably put in an SCR, but it feels that Maplesoft is not particularly responsive to remarks from their customers.

:-(

M.D.

@acer Thanks for checking & confirming my observations.

It is actually kind-of sad having such an elementary thing go wrong. I believe I can work around this (by redefining m[e]), but I am not at all happy about this discovery. It means the ScientificConstants Package cannot be trusted. While I understand and accept that software is not perfect; this one I consider quite bad. Also unnecessary and probably fairly easy to fix (unless the whole package is really nadly done).

I'll probably put in an SCR, but it feels that Maplesoft is not particularly responsive to remarks from their customers.

:-(

M.D.

@abbeykabir To mind comes print(), and if you want a really well formatted output lining up neatly you may need printf which uses standard C formats. If you run these in a loop I think you may get the output at each iteration. 

If the iteration takes a long time you could use FileTools to print to a file.

All of these commands are documented and I encourage you to peruse the help facility.

M. D.

@abbeykabir To mind comes print(), and if you want a really well formatted output lining up neatly you may need printf which uses standard C formats. If you run these in a loop I think you may get the output at each iteration. 

If the iteration takes a long time you could use FileTools to print to a file.

All of these commands are documented and I encourage you to peruse the help facility.

M. D.

So the trick appears to be to enter the composite unit MeV*s into the AdSystem command (about the only variation I did not try). BTW, the multiplication sign has to be outside of uneval quotes.

The test works; I get hbar in the right units.

However, all is not well. Trying to evaluate the electron mass, where I want m*c^2 in MeV, I run into this interesting result:

m:=GetValue(Constant('m[e]'))*GetUnit(Constant('m[e]'));

c:=GetValue(Constant('c'))*GetUnit(Constant('c'));

simplify(m*c^2);

Hmm, heavy little buggers, these electrons, aren't they... :-) Well, no!

Digging a little I find that m[e] is a derived constant, and while the derivation adjusts the numerical value it appears to lose track of the unit: where it says "kg" it should be "MeV*s^2/m^2". And then I get for m[e]*c^2 the numerical value I want (0.511) but the unit [J] is wrong. it should be MeV.

Have I run into a bug here? I double checked Maple 15 and Maple 17: same result in both.
I played around adding the MeV to the list in AddSystem. That does convert the unit from Joule to MeV but the value (3.2E12 MeV) is still wrong.

The "context" I still do not fully understand (I got all that from the docs). It appears that the same unit can have different meanings (sure enough) and context is used to keep track of them. I am not sure this applies to me since I do not change any values or meanings of units.

M. D.

So the trick appears to be to enter the composite unit MeV*s into the AdSystem command (about the only variation I did not try). BTW, the multiplication sign has to be outside of uneval quotes.

The test works; I get hbar in the right units.

However, all is not well. Trying to evaluate the electron mass, where I want m*c^2 in MeV, I run into this interesting result:

m:=GetValue(Constant('m[e]'))*GetUnit(Constant('m[e]'));

c:=GetValue(Constant('c'))*GetUnit(Constant('c'));

simplify(m*c^2);

Hmm, heavy little buggers, these electrons, aren't they... :-) Well, no!

Digging a little I find that m[e] is a derived constant, and while the derivation adjusts the numerical value it appears to lose track of the unit: where it says "kg" it should be "MeV*s^2/m^2". And then I get for m[e]*c^2 the numerical value I want (0.511) but the unit [J] is wrong. it should be MeV.

Have I run into a bug here? I double checked Maple 15 and Maple 17: same result in both.
I played around adding the MeV to the list in AddSystem. That does convert the unit from Joule to MeV but the value (3.2E12 MeV) is still wrong.

The "context" I still do not fully understand (I got all that from the docs). It appears that the same unit can have different meanings (sure enough) and context is used to keep track of them. I am not sure this applies to me since I do not change any values or meanings of units.

M. D.

@ecterrab Hi Edgardo,

Just a quick reply as I am buried in unrelated work this week. I'd be delighted if I could draw on your expertise as I am designing the course. As I think I mentioned, the actual course will be next summer, so no need to panic yet, but I also won't be able to focus exclusively on it (far from it, actually) so I want to get going now as I know I'll be struggling at times with both Maple and the subject (in the sense of how to present it best).

Thanks much, we'll be in touch

M. D.

Ah, I did not realize showstat was of use here. So it appears that PhysicsVectors is what I think they call a structured type.

Thanks,

M.D.

Ah, I did not realize showstat was of use here. So it appears that PhysicsVectors is what I think they call a structured type.

Thanks,

M.D.

@ecterrab Yes, one may argue that (...these topics are outside the sphere of the Physics package). I meant to allow for that in the 2nd paragraph of my 2nd reply.

Re-reading your description (the worksheet), I think we may be approaching the subject from a somewhat different angle. You appear to be asking: how can we make this tool (CAS) better and even more powerful and more natural to use, implicating that then usage will increase. I am somewhat more hung up on why the power that is already there isn't used more, and my implicit answer is that it is the inherent complexity of the tool. I really do not have enough experience to decide who is closer to the truth, but given the relative maturity of CAS these days one does wonder why they have not reached the penetration of, say, MatLab (which I find in much broader use in my field of accelerator work than either Maple or Mma).

Going over this thread again, however, my first comment still resonates with me and seems to hit the spot as closely as I am able to.

In the meantime I have started to "play around" with my old course script and tried to "Maple-ize" a short piece. After a couple of hours of work I am still convinced I am going in the right direction with this and, I might add, I did use the Physics package to good advantage. And, lots of climbing on that learning curve again...

M.D.

After a cursory look at the enclosed Maple worksheet, I consider the answer to "Polemic question #1" to be a touch dishonest. I do not doubt for a second that there exist examples where a CAS (Maple or other) shines and leaves a C++, C or even Fortran program in the dust. In general production use, fat chance! Esp. since I do not usually have the time to wring out every last second or even minute from an algorithm. But in reality, it usually does not matter anyway. Hardware is fast and if my problems are of a sufficiently large scale then I can either reprogram from a CAS result or use one of the connection Toolboxes most CAS have. It is claims like this that I consider genuinely unhelpful as people will find out the reality & get ticked.

"Polemic question #2": Why, are the two (book vs CAS) mutually exclusive?? Me, I have my Abramowitz-Stegun and I also have my Maple, and I love them both.

So I do not think the presentation got it quite right, having too much of an either-or slant. I do however agree fully with  the last two statements in the post ("Genuine learning... and Inspiration..."). And I do believe CAS can help with these.

M.D.

@ecterrab 

I'd like to see more examples that push the limits of Maple, i.e. don't work in a straightforward manner. Example: Applying simplify() to a polynomial thus demonstrating how it works is fine, but what about applying it to an expression it fails on and then showing how one can coerce it, or use other functions, to get where one wants to go. I can't come up with a good one right now but 'primes has a number of questions of this ilk. Other example: I ran into applyRule's ability to get into an endless loop and needed to ask here to learn what was going on. Things like that can really frustrate esp. a novice. So I am always looking for ways to formulate a problem in a way amenable to solving it with Maple.

The above applies to teaching Maple as opposed to teaching physics or math. The issue is not clean, however, as the line between explaining Maple and explaining physics or math concepts is blurry. E.G. if I want to teach physics using Maple, I probably want to stay with relatively clean examples so students do not get distracted by technical Maple issues. If I want to teach solving physics problems with Maple, however, I need to go deeper into Maple's idiosyncrasies, lest I frustrate my students.

Mac Dude

Edit: Just now a question (Why doesn't the following simple code work with implicit procedure?) showed up that exemplifies the issue: someone tripped over premature evaluation in a plot command. Certainly an advanced subject and not necessarily well covered.

Yeah, but note that, on Masc OS X, plotsetup(help) returnx X11 as a possible device even though the Mac version of Maple has no X11 drivers...

M.D.

As I actually am a physicist this topic is of great interest to me. Without having this thought through I see two questions here:

1. What prevents physicists from using CAS in their daily work (inasmuch as it involves analytic mathematical work)?

2. What prevents physicists engaged in teaching from using CAS in their lectures.

In both cases, the learning curve is actually quite steep, requiring some real investment in time before there is pay-off. It gets easier if you are the theoretical type who works on mathematical (as opposed to numerical) problems every day. And I know many of those who do use CAS on a regular basis. Those of us who do this less often will find themselves struggling to do seemingly trivial things like casting expressions into certain forms just because they either forgot the specific commands or have not yet learned them. At one time I literally threw in the towel (with Mma at the time) and only in the last couple of years have I gotten back to using CAS, now using Maple. I personally would like to see more up-to-date books that deal with advanced concepts and techniques (not the introductory stuff); as far as I know there are not many around and if they exist they tend to be quite dated. Obviously, others learn differently.

I do think worked examples like the ones in the workbook you provide are useful and should be a real help to those planning a course and wanting to use Maple. Providing the facility to use text-book notation seems useful in an educational context. For actual work this is not so obvious to me. Having e.g. to use palettes and drag-drop to build up expressions becomes a drag quickly (pun intended); most professionals will prefer using the keyboard at least once they are over the initial hump (I certainly do).

I shall be watching this and study your sheet as I will actually be teaching again next year and really want to do this with Maple. Teaching needs to get away from it staid mechanism of the instructor dishing it out and the students taking it. I am looking forward to being able to engage the students in some exploratory work & get away from "chalk-board physics" (how's that for being naive :-) ). In my own experience, visualization and being able to run a few scenarios quickly helps in understanding a system in a tangible way and in guiding the mathematical development or derivations necessary to arrive at a general solution. I guess implicitly I assume that most students learn in a similar way.

Mac Dude