Mac Dude

1122 Reputation

13 Badges

7 years, 233 days

MaplePrimes Activity

These are replies submitted by Mac Dude

@edahl Another option worth investigating is the maplev mode for Emacs, by Joe Riel (who is no stranger to this forum). You will need to use emacs, obviously, but it may be worth it. Joe keeps maplev up-to-date for Maple from V to present. maplev does keyword coloring, indentations, will help you sorting out the various end do, end proc etc. closures, and many more things. I believe you can also run Maple from within emacs through it although I am not doing that.

To make this work you create your code as a file with a .mpl extension. Then you "read()" it into Maple.

Just my $0.02.


@Carl Love Thanks for the correction. I now use your code above (thanks!) & reran the example. Qualitatively the results are quite similar; probably because I ran the whole For loop in between MU and DeltaMU.

I am now looking at the Programming Guide to figure out what it is I have. Most of them as as I said before, BINARY, which off-hand does not seem to be too helpful.

Still diggin'


@Carl Love and acer: Ok, I tried kernelopts(memusage). Indeed it produces output, but I am not much the wiser for it.

The code allocated about 390 MB per the indicator at the bottom of the sheet. If I add all the third entries from the list of lists I get about a quarter of the allocation (95 MB vs 390 MB). The biggest piece with about 67 MB is called BINARY. Which is fine except that I don't really know what this is. It is not floats; I get about 350kB of FLOATs which seems ok. I get about 21000 HASH objects, which seems strange.

I then tried Profile on a specific procedure (one which I suspect maybe at fault). The output is

BooSynch:-ALU:-BoosterFRamp := proc(t)
local t__loc, dppdt, momRamp, corrRamp, fRamp;
     |Calls Seconds  Words|
PROC | 7058   2.540 17580262|
   1 | 7058   0.082 317283| fRamp := `if`(assigned(BooSynch:-ALU:-Fc),BooSynch:-f__Bi-BooSynch:-alpha__p*BooSynch:-f__Bi*(momRamp+corrRamp),BooSynch:-f__Bi-BooSynch:-alpha__p*BooSynch:-f__Bi*momRamp);
   2 | 7058   0.038     30| if assigned(BooSynch:-ALU:-t__Start) then
   3 | 7041   0.031 209427|     t__loc := `if`(0 < BooSynch:-ALU:-time_to_inj_act,t-BooSynch:-ALU:-time_to_inj_act-BooSynch:-ALU:-t__Start,t-BooSynch:-ALU:-time_to_inj-BooSynch:-ALU:-t__Start);
   4 | 7041   0.015  28164|     dppdt := BooSynch:-dpp__e/BooSynch:-t1;
   5 | 7041   1.770 12513390|     momRamp := 1/2*dppdt*BooSynch:-t1*piecewise(t__loc < 0,0,0 <= t__loc and t__loc <= BooSynch:-t1,1-cos(t__loc/BooSynch:-t1*Pi),BooSynch:-t1 < t__loc,2);
   6 | 7041   0.522 3982698|     corrRamp := BooSynch:-ALU:-Fc*piecewise(t__loc < 0,0,0 <= t__loc and t__loc <= BooSynch:-t1,1/2-1/2*cos(2*t__loc/BooSynch:-t1*Pi),BooSynch:-t1 < t__loc,0);
   7 | 7041   0.080 529270|     fRamp := `if`(assigned(BooSynch:-ALU:-Fc),BooSynch:-f__Bi-BooSynch:-alpha__p*BooSynch:-f__Bi*(momRamp+corrRamp),BooSynch:-f__Bi-BooSynch:-alpha__p*BooSynch:-f__Bi*momRamp)
   8 |   17   0.000      0|     fRamp := BooSynch:-f__Bi
                            end if;
   9 | 7058   0.002      0| return fRamp

The number of Calls seems high; there are only 200 direct calls from the loop but I can see that there are a number of indirect calls in each pass. The number of seconds (& I assume the first one is the total time) means this is not where the code spends its time (this run took several minutes). The number of "Words" is puzzling: does this refer to allocated storage? In 64-bit words?? 17 MWords would be a lot; I have no clue where that would be done.

Is this stuff documentd somewhere? The help file barely shows the output and has no real explanation (unless I am so dense that I do not understand the obvious).

Thanks anyway, making some progress but not there yet.


@torabi Oh, so you want to do this numerically.

How do you expect to get a numeric solution when you only spec. your initial values as finite?

To have any chance you will need to put in actual values.

I tried to see if a general symbolic solution exists, and Maple returns a solution with new variables and a reduced de. Unfortuntely I don't have time to see if this can be pursued further, but the solution will be quite complicated in any case.

So, find values for your conditions & plug them in to allow for numeric solution.



It sounds like you really have an initial-value problem. I would use dsolve to get the general solution first. Then you eval your u(r) and the differential expression at r=0; you may equate them to u0 and du0 or whatever you call your initial values. Presumably you have a 2nd-order system so you will have two constants which Maple will call _C1 and _C2. You can then solve these two equations for your initial conditions, which gives you the expressions for _C1 and _C2 in terms of the initial values.

To be more specific we'd have to see your DE. Mere condition that your initial values be finite may not be enough to find the particular solution. If you have a pole at r=0 you may end up with both _C1 and _C2 having to be 0 and the trivial solution.


@Pascal4QM Thanks for the link to Joe Riel's elisp debugger. However, the thread is from 2012. I wonder whether Joe could chime in here as to whether that code is still being maintained.

Mapke's debugger is a bit rough around the edges. In most cases I avoid the debugger and just sprinkle print() statements in my code until I get it to run as intended. For large monolithic procs and loops that crap out after some number of cycles I have at times stored intermediate results in tables to be read later.

I should check out Joe's debugger. I like and use his maplev.el code editor a lot.

Thanks again,


@Carl Love indeed.


Because you never give it the actual d.e. ...?


So this is Fortran, from "Numerical Recipes", a well known compendium of algorithms, and from a relatively old version ofthe book. As copied it is syntactically incorrect since the print in the book uses  typesetting to distinguish comments and also labels which are not part of the code.

Is there any reason not to use Maple's internal random generators? The RandomTools package has several to choose from; there are RandomVector and RadomMatrix in the LinearAlgebra package as well.

Reimplementing the Numerical Recipes generator in Maple is likely quite possible, but expect it to be slow. I would not do this.


I certainly wish Maplesoft to be around for a lot longer; Maple having become a rather indispensable tool for me in my work.

But some water needs to be poured into the wine:

Maplesoft has emphasized and taken pride in its STEM-education related work for a long time. How come, then, that my Raspberry Pi has "that other System" installed rather than Maple?? Given the not so small power of the Pi 3; if I were a student nowadays I'd get a Pi 3 and that would be that. And why would I switch to Maple later? (Full disclosure: I did just that; but the initial prompt was a free [to my dept] site license and a rather inane licensing policy of "that other company", added with at the time only a small amount of work invested with the other system).

How come one of my erstwhile students was told he could not move his student license of Maple to his new computer, making him switch to "that other system" which he gets for free (from his university)? Customer and Maple user lost; probably forever. Probably not the only case.

Market forces are real, and I sometimes wonder, given Maple's relative obscurity in at least my field (physics and particle accelerators), how long it can survive unless it makes it attractive (irresistible) to keep using it.

Still, thriving for 30 years is not a small feat in these days, so my congratulations and thanks go out to the Maple team. Please stay around.

Mac Dude


All of your exponentials are imaginary, so they are vectors rotating in the complex plane.

I'd try plotting the absolute of the expression to see if in fact it has a 0. If you see one you may be able to home in with fsolve.

You can always throw the abs of your expression at solve, but I doubt it will succeed; and I particularly doubt the result will be meaningful.

BTW: complex 0 is 0+0*I. That is why you need the absolute value.


You need to tell us your platform (op. system, version).


@Preben Alsholm Thanks for checking.

I wonder whether this may be a Mac issue. I am running on OS X 10.11 El Capitan.


You have at least one typo: b1*BeselJ should be b1*BesselJ.



By far the best reference I found is the one you use (the Programming Guide). It really has the info you need when working with Modules, procs etc., as you appear to (and I am doing extensively as well). Together with the Intro and Reference you are about as covered as you can get, IMO. I am not aware of any material besides Maplesofts that covers the programming aspect. Which actually is a shame as Maple is a very powerful programming language that does have a bit of a learning curve.

Then, as you have learned, stay away from 2-d input unless you have a project where typesetting is essential. I have written a lecture script in Maple, and that was done in 2-d for obvious reasons. But even then, I wrote those sections that posed difficulties (in Maple) in 1-d first, debugged them and then transcribed into 2-d. Time consuming, but at least it did not drive me insane.

acer has given you the underlying explanation of the behaviour you saw. This specific limit of 2-d was new to me; so I learned something here as well.


1 2 3 4 5 6 7 Last Page 3 of 37