It might be of interest to you that Maple 16's garbage collector can return collected memory to the OS. In Maple 15 and earlier, that would only happen upon restart. In other words, in Maple 16 kernelopts(bytesalloc) can decrease, without restart.

The garbage collector in Maple 16 is new. It needs a few tweaks, but overall it seems like a Good Thing. For example, there is a measurable speedup between M15 and M16 on some of those comparative performance tests that you recently posted about, and I believe that the new memory management system is due part credit. Those tests do things like floating-point linear algebra on Matrices up to size 2000, iterated several times, all in the same session.

acer

It might be of interest to you that Maple 16's garbage collector can return collected memory to the OS. In Maple 15 and earlier, that would only happen upon restart. In other words, in Maple 16 kernelopts(bytesalloc) can decrease, without restart.

The garbage collector in Maple 16 is new. It needs a few tweaks, but overall it seems like a Good Thing. For example, there is a measurable speedup between M15 and M16 on some of those comparative performance tests that you recently posted about, and I believe that the new memory management system is due part credit. Those tests do things like floating-point linear algebra on Matrices up to size 2000, iterated several times, all in the same session.

acer

@Adri van der Meer Sorry, perhaps I didn't notice that V was constructed by reading along columns of M. So naturally you would want to reconstruct it by laying down entries from Vector V in the same way.

Is this a fix-up, to lay down the Matrix, columnwise, from given Vector V with that interpretation?

Gr:=(m,n,W) -> Matrix(m,n,
                     (i,j)->`if`(i>j, 0,
                                 W[((j-1)*(j)/2)-`if`(j>m,
                                                     (j-m-1)*(j-m)/2, 0)+i])):

I would guess that a do-loop could be faster than such an indexing function due to the hit from calling `if`(i>j,...) on all entries (because with nested loops the upper value for the inner loop's index can be a function of the outer loop's index). And indeed, your procedure performs faster.

@Adri van der Meer Sorry, perhaps I didn't notice that V was constructed by reading along columns of M. So naturally you would want to reconstruct it by laying down entries from Vector V in the same way.

Is this a fix-up, to lay down the Matrix, columnwise, from given Vector V with that interpretation?

Gr:=(m,n,W) -> Matrix(m,n,
                     (i,j)->`if`(i>j, 0,
                                 W[((j-1)*(j)/2)-`if`(j>m,
                                                     (j-m-1)*(j-m)/2, 0)+i])):

I would guess that a do-loop could be faster than such an indexing function due to the hit from calling `if`(i>j,...) on all entries (because with nested loops the upper value for the inner loop's index can be a function of the outer loop's index). And indeed, your procedure performs faster.

@jjrohal As mentioned, you might also consider using Vectors instead of lists.

restart:
<1|2> + <3|4>*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

Vector[row]([1,2]) + Vector[row]([3,4])*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

ee := [1,2] + [3,4]*(x-1)^2:

evalindets(ee,list,convert,Vector[row]);

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

@jjrohal As mentioned, you might also consider using Vectors instead of lists.

restart:
<1|2> + <3|4>*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

Vector[row]([1,2]) + Vector[row]([3,4])*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

ee := [1,2] + [3,4]*(x-1)^2:

evalindets(ee,list,convert,Vector[row]);

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

@Christopher2222 There is this rebuttal to that Wolfram article (linked from here fwiw).

@Alejandro Jakubi Yes, you are quite right that this is much less likely to work than, say, mixing 32bit Classic with 64bit kernel of the same major release. And new or change DAG ids is just the sort of rare change that can make it fail.

I tried to take the tone that it would be interesting to see what results the Asker might have, and that my curiosity there was more my motivator. I wasn't trying to advocate than anyone take this approach on the grounds that it is expected to resolve problems. Apologies, if I didn't make that clear enough.

Of course one would naturally expect that the Classic GUI actually shipped with a major release should be the best and most stable Classic instance to work with that release. There is a slim chance that it may not be, and if so then I think that it's worthwhile to find out. Are the Asker's crashes due entirely to problems introduced into some change in Classic's binary executable (or mclient.dll)? Or are they due to problems communicating with the kernel (eg. new DAG issues, etc)? 

I have been seeing some sudden, random crashes in the Maple 16.01 Standard GUI, doing nothing but repeating many times some simple plots of short amounts of data read from file. I have not been able to construct any way to reproduce this problem on demand, but when it happens all session data is lost. There is a (small) possibility that the problems lies with interface-kernel communication or memory management. Maybe it's related to this Classic problem,... and more likely it is not.

@Alejandro Jakubi Yes, you are quite right that this is much less likely to work than, say, mixing 32bit Classic with 64bit kernel of the same major release. And new or change DAG ids is just the sort of rare change that can make it fail.

I tried to take the tone that it would be interesting to see what results the Asker might have, and that my curiosity there was more my motivator. I wasn't trying to advocate than anyone take this approach on the grounds that it is expected to resolve problems. Apologies, if I didn't make that clear enough.

Of course one would naturally expect that the Classic GUI actually shipped with a major release should be the best and most stable Classic instance to work with that release. There is a slim chance that it may not be, and if so then I think that it's worthwhile to find out. Are the Asker's crashes due entirely to problems introduced into some change in Classic's binary executable (or mclient.dll)? Or are they due to problems communicating with the kernel (eg. new DAG issues, etc)? 

I have been seeing some sudden, random crashes in the Maple 16.01 Standard GUI, doing nothing but repeating many times some simple plots of short amounts of data read from file. I have not been able to construct any way to reproduce this problem on demand, but when it happens all session data is lost. There is a (small) possibility that the problems lies with interface-kernel communication or memory management. Maybe it's related to this Classic problem,... and more likely it is not.

@Adri van der Meer The custom do-loop can be faster, but just for fun,

G:=(m,n,W) -> Matrix(m,n,(i,j)->`if`(i>j,0,W[(i-1)*n-((i-1)*(i)/2)+j])):

G(4,6,V);

@Adri van der Meer The custom do-loop can be faster, but just for fun,

G:=(m,n,W) -> Matrix(m,n,(i,j)->`if`(i>j,0,W[(i-1)*n-((i-1)*(i)/2)+j])):

G(4,6,V);

@Christopher2222 There is an external call to compiled code, performed during execution of your code fragment. What that compiled code does, and how, is not really visible. It could well be that it is simply hard-coded and compiled to not do what you are after, in Maple 12-14. Or perhaps it couldn't work, or wasn't finished, in those old versions.

I don't see how one could change what action is attempted by the compiled function `dictCreate` of dynamic library `mstring.dll`.

restart:
kernelopts(opaquemodules=false):
StringTools:-defun(convert(dictCreate,'string'),
                   "mstring",(':-mtsafe') = false);

          proc()
          option call_external, 
            define_external(mstring_dictCreate, MAPLE, LIB = "mstring.dll");
            call_external(0, 475471680, true, false, args)
          end proc;

It worked for me, with or without separate execution groups, in Maple 13.02. See attached worksheet.

mmm.mw

You've shown a pair of round brackets around all the commands. I didn't have that in what I posted. What's their purpose?

It worked for me, with or without separate execution groups, in Maple 13.02. See attached worksheet.

mmm.mw

You've shown a pair of round brackets around all the commands. I didn't have that in what I posted. What's their purpose?

It seems my guess was right. fsolve is trying to nail down the 10th digit accurately (for default Digits=10 as the environment). So unless it can compute the expression (involving a numeric integral) at least that accurately then it may get into some trouble. And it may also hit a known issue where evalf/int goes "away" while trying to find discontinuities of the integrand in expression form and when no quadrature method is forced. Using the integrand in operator form is going to confuse fsolve which has overzealous checks for mixed operator/expression cases, so that  leaves forcing the quadrature method.

conclusion: tighten the accuracy of the numeric integral, so fsolve has a chance to meeting its own (somewhat inflexible) accuracy requirement, and force the quadrature method to make it faster.

restart:

F := Int(sqrt((2.138+0.3e-2*exp((4.2^2-z^2)/d^2))^2-2.141^2), z=0 .. 4.2,
         digits=15, epsilon=1e-12, method=_d01ajc) = .5:

fsolve(F,d=2..6);

                          3.957142936

If you obtained that Int() call as the result of something else then you might have to do some `op` work to shoehorn in those extra options.

acer