@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

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

Are you given E? Is it symmetric?

Could you attach all the data to a Comment on this Question?

acer

I would like to extend a welcome to Carl. 

There is a great deal worth reading in his responses and posts on the USENET groups comp.soft-sys.math.maple and sci.math.symbolic [1, 2], back before Mapleprimes existed.

acer

I would like to extend a welcome to Carl. 

There is a great deal worth reading in his responses and posts on the USENET groups comp.soft-sys.math.maple and sci.math.symbolic [1, 2], back before Mapleprimes existed.

acer

Using ':-epsilon'=1e-5 I got the following plot,

acer

Using ':-epsilon'=1e-5 I got the following plot,

acer

@Markiyan Hirnyk Indeed, once a 2D Math input containing atomic identifiers has been converted to 1D then using the context-menu to convert it back to 2D input doesn't get a nicely typeset piece of input. The same seems to go for entering the TypeMK explicitly while in 2D input mode. It seems that atomic identifiers cannot be successfully round-trip converted typeset 2D->1D->typset 2D using the context menus.

On a wild guess, I also tried it for input `#msup(mi("a"),mn("2"),msemantics="atomic")` but again no luck.

But I was not talking about that. I was referring only to the case of right-clicking on a 2D typeset bit of 2D Math input which had previously been toggled as atomic identifier. What you gave was a bit of TypeMK which was not typeset. I suppose one may sensibly distinguish between input which is typeset 2D Math and input which is TypeMK code notation that can represent it.

@Markiyan Hirnyk Indeed, once a 2D Math input containing atomic identifiers has been converted to 1D then using the context-menu to convert it back to 2D input doesn't get a nicely typeset piece of input. The same seems to go for entering the TypeMK explicitly while in 2D input mode. It seems that atomic identifiers cannot be successfully round-trip converted typeset 2D->1D->typset 2D using the context menus.

On a wild guess, I also tried it for input `#msup(mi("a"),mn("2"),msemantics="atomic")` but again no luck.

But I was not talking about that. I was referring only to the case of right-clicking on a 2D typeset bit of 2D Math input which had previously been toggled as atomic identifier. What you gave was a bit of TypeMK which was not typeset. I suppose one may sensibly distinguish between input which is typeset 2D Math and input which is TypeMK code notation that can represent it.