Hello Acer, Firstly thank you for all the time you spent looking into the problem. "When you speak of a "larger data set" do you mean simply more iterations, or Matrices larger than 2x2? If this is really not a pared down version of your program... ... I couldn't tell, about whether the code was producing what you really wanted. The Matrix p, for example, seems to stay the same at each iteration. Maybe it depends on whether you plan to change B and L." --> Yes. This is kind of a pared down version; by larger data set, i meant more iterations; at the same time i might also move to a bigger matrix. also p in this case is same because the Gamma was set to zero. Otherwise it would change the starting vector at every event point (what i am doing here really is that, i am trying to generate traces (inter arrival times, inter service times etc) for non-renewal (correlated) processes, with Gamma being the parameter that controls the correlation decay (lag); yes, changing Gamma will change L and will thereby effect pNew ). "But let's look at the objects more closely. The Matrix -B is diagonal, so MatrixExponential(-B,t) is just going to produce.... -->> Yes. This is a special B; B might as well have all non-zero elements (this case represents a special hyper-exponential case). And yes, i could take the matrix apart and sum them as a sum of two exponentials (infact; immediately after posting this thread that is what i did; i wrote the program in plain 'c' to generate the trace. It obviously runs very fast in c (for even a trace of 10million Arrivals, it would finish in a couple of minutes). But it would be for a renewal case (Gamma=0). That is the case when i would not have to invert the function at all (fsolve); I could sum them up as a set of exponential phases. So surely I will change the '.' to MatrixMatrixMultiply but i am not ready to do the element wise multplication. I will let maple do it. Again thank you for pointing out the sequence of function calls that were being executed. I also realize that my code will look much less prettier than before with all these function calls instead of "." (dots). Gosh, how much i wish maples compiler will recognise these optimizations and run an optimised code.

maybe you are right; but even after letting the Digits to fall back onto default (10 digits) it still is a memory hog. for now generating only 300,000 values and running on maple 8.0, would take about 5 hours i think (i always start before going home; so its a guess); at the end the program would be eating up about 1.2GB of paging space (very close to the system limits). But would love to be able to do it much faster and for a much larger data set.

i am having a similar problem with stack limits; the way i am able to see the stack size increasing is from the "Task Manager" in WinXP. look at the "PF Usage" in Performance tab. this might help. but it appears to me that somehow even inside a simple for loop some stuff is being put on a stack (even when there are no recursive calls; looks like a bug to me). the problem is worse in Maple 9 and 10; maple 8 is managing it better (will crash after some more time; but at least better than 9 and 10).