@mehdi jafari The data file I downloaded (NLIST.txt) has extra (blank) lines at the end that trip up ImportMatrix. Get rid of those and it works.

M.D.

This is of course a rhetorical question. Dirac's delta cannot be plootted directly as only its integral is defined.

You can evaluate and plot its Fourier transform (well, the real and/or imaginary part anyway). It gives a line spectrum unbounded in frequency (not unexpectedly so). If you transform back you may be able to get an approximation of your delta functions that in fact can be plotted.

Mac Dude.

You define the function like this:

f:=r_ -> Int(Int(Int(G(r_-r0_)-(x_-r0_)*rho(r_))));

however, you also need to specify the differential to integrate over (2nd argument of Int()).

Mac Dude

@Alejandro Jakubi Thanks; I had forgotten about assume creating local names.

I hope the OP reads Markiyan's and your comments as they allow her/him to complete checking the solution

M.D.

I ran your system and did not get anywhere, just an mserver process (the Maple compute engine) chewing up increasing amounts of memory (ca. 15 min when I killed it).

In cases like that I normally try to find partial solutions using a subset of the whole set of equations. These can be used to reduce the number of equations/variables. The "eliminate" command may help, although I usually just solve repeatedly, then substituting the solutions to get rid of variables. It is a bit tedious in your case but you'll find out where Maple chokes.

I don't typically try to solve such large systems. with smaller ones (3 to 4 eqns) it takes seconds at most.

Mac Dude

I ran your program up to the point where your post indicates an error (solve(sys1[][]...). No error occurred for me in Maple 15. The solutions are not particular meaningful but that is presumably a different issue.

Are you beginning each worksheet with restart; ?? If Maple acts funny, recalculating the whole sheet is the first line of defense; the restart flushes most of the previous garbage.

It would be nicer if you could upload worksheets to spare us copy-pasting line by line.

M.D.

It is not clear that your problem is posed in a way we can help; but here are some suggestions to maybe help clarify the issue:

At the very first: If this is part of research work, you should worry about it! Actually, rather than worrying, double/triple/quadruple check your results. Apply common sense. Put results back into the original eq. Etc.

As for Maple 12 vs Maple 15: It should be no surprise that you get different results (after all, Maple is evolving and you switch between 3 generations). It seems Maple 15 finds solutions that Maple 12 does not: this would be consistent with an upgrade of the relevant routines (solve in this case). The question you need to assess is: is one solution correct and the other wrong? You are indicating sign differences to another program: with eigenvalues of a 3 by 3 matrix I am not shocked about that: Eigenvalue equations have multiple solutions and it is possible that different programs pick different branches. Your understanding of the original problem should help you to pick the sign that is right (or you have multiple valid solutions). Do any of your solutions make sense?

Also note that different versions of Maple may present results (esp. multiple results that are stated as lists or sequences) in different order. This can trip you up when using, e.g., op(n,xpr) to pick a certain one.

You appear to do eigenvalues "by hand": what do you get from straight usage of Maple's eigenvalue/eigenvector routines in LinearAlgebra?

My own experience is that Maple actually makes few outright mistakes. However, there are many cases where Maple output may omit solutions I am looking for; or present a multitude of solutions and I get to decide which is physical (most of my problems are physics-related). And there are cases where Maple does not find a solution I know exists. And there are cases where Maple leads me to a deeper understanding as it shows solutions I did not know existed.

If you upload a worksheet, maybe we can have a look.

Mac Dude.

@Markiyan Hirnyk It may not be a surprise that ExponentialFit returns a higher rms deviation that DirectSearch or NonlinearFit. The linearization that ExponentialFit does will lead to a bias unless the underlying linear fit is done weighted with the weights properly calculated from initially given weights (even if those are all 1). The docs on ExponentialFit are mute on this subject, except the docs seem to say that user-supplied weights apply to the linearized data and not to the original data.

Mac Dude

@Christopher2222 

restart will not gc or deallocate Java memory, so no surprise that the Maple.exe process memory does not change.

Java has an incremental garbage collector that you can activate with -Xincgc. By default that is off. Maybe that would help (I have not tried that yet). You would put that switch on the same line as where the -Xmx is (and there don't seem to be any arguments to -Xincgc).

Your temporary freeze upon resizing is not a surprise. Is mostly an issue with 3-d graphs for me. It usually clears up with patience.

You can also add a stack-size increase. -Xss4m (or maybe 8m) will likely double or triple your Java stacksize which on general grounds I would assume should be a certain fraction of the heap (but I really have no deep knowledge here).

M.D.

@Alejandro Jakubi 

Right, and the options I have seen and now modified on my system are -Xmx (max heap) and -Xss (stack). I guess the issue for christopher is now where these actually are set in Windows (the file jre\bin\client\Xusage.txt you mention seems to be more like a help file than a file used by the system to set the parameters).

I have not had a chance to push this so I still don't know how much help it'll be.

M.D.

@mehdi jafari 

It is interface(imaginaryunit), at least in Maple 17.

M.D.

@MuriloLobo 

In my answer to your original question I gave you a pointer to the info you need to generate the Gaussian-distributed random numbers. Read it and then apply it. It is all there and not that difficult.

The only missing piece is the cut-off at the 95-percentile. The straightforward way would be to just discard any number generated that is outside of the window you want. I do not know what the effect on the randomness might be, but since it is a small percentage of the generated numbers you would discard it may not be too bad, unless your application is super-critical. I do not know whether Maple has a more exact way of treating cut-offs.

As Carl mentioned below, be sure you understand what you want as far as one-sided vs two-sided cut-off is concerned. This depends on your specific problem and cannot be answered in general.

M.D.

Edit: 2 New posts came in while I typed some some of this is a bit out of sequence

@Christopher2222 

As it turns out, kernelopts(limitjvmheap) is false by default, meaning that the 65MB Maple reports is not enforced. I suspect the limits in the launch.ini file >are< being enforced (on OS X the plist entry looks just like cmd-line switches when using Java, and those ARE enforced).

I checked some of this on my G5 installation of Maple 15 (32bit). First, the numbers in the plist file are the same as the numbers on my 64 bit install, which is a bit strange but... I doubled both the heap and the stacklimit, and things still run. The Maple15 process now reports a large virtual memeory size of > 2 GB (this is claimed to be the max. size the process can grab), so I think the change worked. Have not had time to push this, but a cursory check seemed to indicate Maple worked fine (but the Maple15 process never took more than about 300MB so did not push the limit).

So, I'd make sure limitjvmheap is false (default), double your allocations for both heap as well as stack size in launch.ini and see what happens. Should be fairly obvious.

M.D.

@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.