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

Hmm, interesting construct. I would have tried "../Code_principal/" first, but don't know whether this actually works, even on Mac OS X.

Mac Dude.

Hmm, interesting construct. I would have tried "../Code_principal/" first, but don't know whether this actually works, even on Mac OS X.

Mac Dude.

@Carl Love Thanks for checking & testing against restart. I just submitted an SCR.

M.D.

Bad move. Apparently about 1/3 Mac users stick to 10.6.8. It also seems unwarrented as presumably the push to news OS comes in part form wanting to use things like OpenCL, which 10.6 does support.

Unlikely I will get to Maple 18 anytime soon. Unlikely my friends will. My 10.6 machines work well; no need to dump them or upgrade what works. And no need to get into the iOS-ification that started with 10.7.

Why??

Mac Dude.

@Axel

Hi, I really appreciate your taking the time to look at this in more detail.

I was on travel across the US the last 3 days & my attempt to give you a little more background failed (hotel-network crap-out). You are certainly right in pointing out the ill-conditionedness of the problem. In fact, by now I am quite sure I have to do a better job at nailing down a reasonable interval for the integration. In essence all the parameters except for Zo vary; i.e. 4. The numbers are a bit weird as the beams I am modellig are bunched, looking like steam-rolled cigars: long, flat and very narrow in the vertical (the Sig.. values in the sheet are the sizes & divergences). These plow through each other; the overlap gives a measure of the event rate in a detector. I use meter and radians as units whereas the dimensions are micrometer and micro-radian; that is where the very small numbers come from which then, by division, lead to the 10^10 like results. Maybe I have to rethink that (but I got fed-up tripping over unit conversions).

Your logarithmic approach may make it possible for me to get a measure of the range I really need to integrate over. I'll need to study your sheet a little more to make sure I fully understand it but I get the overall idea. In test cases I have had good experience with integration over +/- 0.01 in z (which makes sense given the length scale in z of the problem [a few mm]). In fact I was able to run 500 cycles of the full problem (much more involved than the test case I posted) in a reasonable 10 min or so. Ultimately I want to let it run for a couple of 1000 cycles (maybe 20 min of time of the real physical system I am modelling). Fortunately, with this running in a closed feedback loop a failing of the integrator becomes obvious fairly quickly (run-away) as I have seen.

I did uncover another Maple "feature": I managed to parallelize the integrations since there are 4 integrations/cycle in the real application (with related and similar but not identical functions) using Threads:-Task:-Start. In Maple 15, that actually works (with apparently correct results) & gains maybe a 50% speed-up for two integrals/cycle. In Maple 17, it works also, but after that the next "restart" hangs the Maple kernel. A sad, reproducible regression.

Thanks again,

M.D.

@Axel

Hi, I really appreciate your taking the time to look at this in more detail.

I was on travel across the US the last 3 days & my attempt to give you a little more background failed (hotel-network crap-out). You are certainly right in pointing out the ill-conditionedness of the problem. In fact, by now I am quite sure I have to do a better job at nailing down a reasonable interval for the integration. In essence all the parameters except for Zo vary; i.e. 4. The numbers are a bit weird as the beams I am modellig are bunched, looking like steam-rolled cigars: long, flat and very narrow in the vertical (the Sig.. values in the sheet are the sizes & divergences). These plow through each other; the overlap gives a measure of the event rate in a detector. I use meter and radians as units whereas the dimensions are micrometer and micro-radian; that is where the very small numbers come from which then, by division, lead to the 10^10 like results. Maybe I have to rethink that (but I got fed-up tripping over unit conversions).

Your logarithmic approach may make it possible for me to get a measure of the range I really need to integrate over. I'll need to study your sheet a little more to make sure I fully understand it but I get the overall idea. In test cases I have had good experience with integration over +/- 0.01 in z (which makes sense given the length scale in z of the problem [a few mm]). In fact I was able to run 500 cycles of the full problem (much more involved than the test case I posted) in a reasonable 10 min or so. Ultimately I want to let it run for a couple of 1000 cycles (maybe 20 min of time of the real physical system I am modelling). Fortunately, with this running in a closed feedback loop a failing of the integrator becomes obvious fairly quickly (run-away) as I have seen.

I did uncover another Maple "feature": I managed to parallelize the integrations since there are 4 integrations/cycle in the real application (with related and similar but not identical functions) using Threads:-Task:-Start. In Maple 15, that actually works (with apparently correct results) & gains maybe a 50% speed-up for two integrals/cycle. In Maple 17, it works also, but after that the next "restart" hangs the Maple kernel. A sad, reproducible regression.

Thanks again,

M.D.

@Axel Vogt Re-casting the integrand in a different form is an idea I like & will explore. The reason I need to run thousands is because this is a part of a simulation for a feedback mechanism. That mechamism maximizes the integrand by varying certain ones of the other parameters. On top; there are actually 3 such relations, each one optimizing a different parameter. The integrals represent the "plant" in the feedback system; in real life these will be colliding particle beams. I did  once run it for 2000 periods (corresponding to about 10 min of time for the real process) which ended up taking a whole weekend. Not acceptable if one wants to be able to tune the whole feedback process. This is not college homework.

Anyway, thanks much for looking into this & giving me some ideas to pursue.

Mac Dude

@Axel Vogt Re-casting the integrand in a different form is an idea I like & will explore. The reason I need to run thousands is because this is a part of a simulation for a feedback mechanism. That mechamism maximizes the integrand by varying certain ones of the other parameters. On top; there are actually 3 such relations, each one optimizing a different parameter. The integrals represent the "plant" in the feedback system; in real life these will be colliding particle beams. I did  once run it for 2000 periods (corresponding to about 10 min of time for the real process) which ended up taking a whole weekend. Not acceptable if one wants to be able to tune the whole feedback process. This is not college homework.

Anyway, thanks much for looking into this & giving me some ideas to pursue.

Mac Dude

Axel, you are absolutely correct. However, the length of the non-zero part along z changes with the parameters given, which in the real application can change a bit. Integration from -1..1 would be safe for all parameters I encounter but the integral does not always get eval'd right over that range (by _d01akc). Integration over -0.01..0.01 seems to always work but may lead to errors for certain parameter combinations.

But what really puzzles me is the increase in time of _Sinc. Also, it is sort-of annoying that _d01amc (which should integrate over the whole axis) fails for this one.

Thanks,

M.D.

Axel, you are absolutely correct. However, the length of the non-zero part along z changes with the parameters given, which in the real application can change a bit. Integration from -1..1 would be safe for all parameters I encounter but the integral does not always get eval'd right over that range (by _d01akc). Integration over -0.01..0.01 seems to always work but may lead to errors for certain parameter combinations.

But what really puzzles me is the increase in time of _Sinc. Also, it is sort-of annoying that _d01amc (which should integrate over the whole axis) fails for this one.

Thanks,

M.D.

What exactly is your problem here? The code you posted produces a graph with 4 curves. They are disjoint because that's what they are. You can play around with log plotting if you want them closer together.

Mac Dude