@Guoqiang Du You have to consider what you are doing here. If you replace n1+n2 with 1; then in fact you can no longer use n1 and n2 independently. n1 then IS 1-n2. Or, likewise, n2 IS 1-n1. If you use n1 and n2 independently after the substitution of n1+n2 by 1 and they do not add to 1; you are being inconsistent and you are making a mistake.

You can consider freezing the expressions if the n1 and n2 in your case are very complicated and you want to maintain the structure:

subs(subexpr=freeze(subexpr),expression); # use algsubs if subs does not work

.

.

.

thaw(expression);# to unfreeze all frozen expressions.

M.D.

I take your indication that "with(yourPackage)" works and some procs in the package work as sign that the option package statement is there and the .mla file is where Maple can find it.

The with() statement returns the list of exports from the package; are the procs that don't work in there? If not then they are not exported and you need to include them in the sequence of exported names. If so, then try to print the proc to see what parameters you need to supply.

If this does not help, please upload the package.

M.D.

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