@Christopher2222 

Ok, there is your clue: I bet you that mserver.exe is the Maple kernel and maple.exe is the GUI (Java) process (because of the naming equivalence to that on OS X). So your culprit is the GUI, not the kernel. That is why you do not see any effect from gc(), because it won't do anything to the GUI process.

Try running the same analysis without plotting anything (maybe save your spectrum to disk & look at it with another program, or something like that). I'll bet you will have much less of an issue.

My prediction: Either Maple goes away from using a Java-based GUI (hard to believe), or you find a way to increase the memory for the Java process (and I still don't know whether or how that is possible), or you go to a 64 bit system, or you are stuck.

It is sad that software developers stick to Java as a means to write a GUI. I really am not an expert in this (and I am certainly not an expert in Java), but I have yet to see a Java-based GUI I really like; most of them suck to varying degree because of their sluggishness. This seems to be true even for relatively trivial ones (and the Maple GUI is actually not so trivial).

M.D.

Edited: You piqued my interest enough that I went snooping around in the Maple files. On OS X, Maple is a so-called application bundle and one of the things it has is a file with properties (called  plist file).

Sure enough, in Maple's Info.plist I find a string called VMOptions that specifies the max. memory allocation the GUI gets (-Xmx500m i.e. 0.5 GB for me) and the max. stacksize (-Xss2m i.e. 2 MB for me). This is Maple17 in a 64bit environment, 32bit limits are likely smaller.

If you find out where that sort of info is stored on your Windows system you may be able to increase the limits and get better GUI performance (until you eat up all memory and lock-up you system :-), then you back off).

Once I get home I'll check my older systems. Maybe I can fix some of the nagging issues I have had in this regard on these.

@Markiyan Hirnyk 

You may well be correct.

Anyway, the real question (for me) is slightly different: the OP asks a question that we answered. His only reply is a different question, one that presumably he could have answered himself out of the manual given the pointers we gave him. So, was his original problem solved & is he moving on, or is this some kind of test of the proficiency of those giving advise on MaplePrimes :-).

M.D.

@MuriloLobo 

To produce random numbers with a certain pdf you need the pdf. If all you have is the cumulative df then you need to look at differentiating it to get the pdf.

This, however, is less of a Maple question but more of a question for a statistician.

M.D.

@ecterrab 

I turned the geometricdifferentiation off and the particular example works fine. But there is other funky business going on. Consider the new example I have posted below. It is a (simple) derivation of the wave equation from Maxwell's eq. With geomdiff false, I get the weird differentials as in the posted sheet. With geomdiff true, I get the expected result just like in the older version I run in Maple 15. Note that the last line ends up at the wanted result in either case.

I suppose I can use the "better approach" you describe above and leave geomdiff true, but it seems to me the result with geomdiff false is odd.

M.D.

geomdiff.mw

@ecterrab 

Excellent, many thanks.

M.D.

@ThomasE 

Define "same". Pie charts are possible. The text in the slices you can put in using plots:-textplot. The arrow I don't know. The 3-d appearance I don't know either; it may have been added in later versions (but the manual will tell you).

So, if you want it to look identical pixel by pixel: probably not. If you want to convey information in the same manner (i.e. a pie chart), yes.

M.D.

@MuriloLobo 

Had a quick look. The program tries to readin a data set we don't have.

The offending line indeed gave me an "invalid sequence" error... until I fixed the comma again at which point it dutifully complained about S1 not being a module (it nowhere defined).

The dangling comma and missing S1 (and other variables) indicate you are be missing a piece or pieces of the code. As it is, it will not run. I suggest you go back to wherever you got the code from and get the missing pieces.

M.D.

The code snippet you posted is incomplete. S1 is not defined (it could be a part of a library package in which case you would have a "with(some package)" command at the top of your sheet. The last comma needs to be a semicolon.

In your snippet, seq is asked to create a sequence of equations. I am not sure that works; I have never tried that. If you want booleans (true or false) try wrapping evalb() around the equation.

Also, most of your variables are undefined so we cannot run your code to see why it fails.

Mac Dude.

@sarra 

After fixing some more minor mistakes (missing ";", missing comment flags, that Maple does flag) I get an output:

I suspect this may not be what you want. The infinities appear to arise form the GenerateMatrix commant. Note that you can use the side panel to inspect your variables for troubleshooting & checking on intermediate results.

Updated sheet attached.

M.D.

sarra.mw

@itsme 

I did not mean to be harsh, and Maple's help is a decent distance away from being perfect esp. when it comes to looking up more obscure features. But order and Order actually happen to be documented under those names; I think order may even be linked from the series page.

You >can< unprotect and then clobber these (I think, not tried) but that seems like an unwise move.

M.D.

@itsme 

The concept of "order" as in "calculation to first order" is intimately bound to series expansion. Mathematically, except in trivial cases a series expansion is what you have to do. It decomposes the expression by order and lets you truncate where you want, by calculating the derivatives and finding their coefficients. If you rely on "truncation by inspection", you run the risk of calculating to mixed order and lose the benefit of e.g. linearizing your problem. In worse cases you get an erroneous result. Maple's series command avoids problems like that and is the one to use for the general case. There may well be cases where substitution is appropriate, but only you can determine whether that is what your specific problem calls for, Maple cannot.

$0.02

M.D.

PS: order and Order are already taken in Maple and protected. RTFM.

I would argue that series >is< the built-in command. As acer pointed out, the replacement commands or rules may miss some 2nd-order terms. Simplify with siderels may do other things to your expression that you may or may not want. And, although not the case in your example, there could be terms beyond 2nd order that replacement rules would almost certainly miss. If you want terms up to a certain order, series seems the way to go. Has rarely failed me.

M.D.

@Carl Love 

Carl & Alejandro, both many thanks. I don't think I'd have figured this on my own. Can't run my worksheet right now, but I do understand the issue.

As for useInt not working: that turned out to be operator error. Been staring for too long at this.

M.D.

@Alejandro Jakubi 

Well, maybe one answer would be to use the Application center more often. I do not know the old Share Library so I cannot compare, but at least in the Application Center I can find things. Since you mentioned Fourier series: there is apparently a package by Moiseev that includes Fourier series (amongst others), and there is even a sheet by Lopez that explains some aspects of the use of the package. (I realize you used this as an example, and this may not do what you need). Ongoing maintenance is a problem even the large open source projects don't get right: lots of older packages linger and get stale. If the creator loses interest it's pretty much just tough luck.

I like the idea of something like Sage; but at this point I have invested quite a bit in Maple, it does what I need (mostly), and I have little inclination to try another one. Maple has a lot of programming constructs I really like and use (modules, records, all the semi-oop stuff) that I don't want to let go of. I highly doubt Sage has anywhere near the polish Maple has. (And yes, in daily work just trying to get something done efficiently, and trying to get e.g. publication-quality graphs done, polish counts. Even Maple has a ways to go in that department.)

(Note to self: I should consider packaging one of my programs for submittal to the Application center. It may have some appeal for others, and since its routines by now have been validated one may let it lose on the public.)

Cheers,

Mac Dude.

@Markiyan Hirnyk 

Markiyan, this was unfortunately (as far as examples are concerned) about a year ago so I do not have the broken version around anymore. What I do remember is that a part of the issue was that I had large Arrays declared as "datatype=anything". This means that Maple was not forced to numerically evaluate an expression (unless you use evalf), and at least in my case dutifully kept working in the symbolic domain. So, once I found that out I littered my code with evalf() statements until I smartened up to this datatype issue, after whch things became much better.

As far as timing was concerned, I just ran scenarios with different no. of iterations & wrote the times down. Since I allocated the arrays based on the max. number of iterations there was a component in the time per iteration that depended on the max. # of iterations.

This was, incidentally, a code converted from Mma, which was part of the issue. Mma's structure is sufficiently different from Maple's that the conversion was a lot more involved than expected.

This is probably not quite what you wanted, but I am not able to post a useful example.

Mac Dude.