@Markiyan Hirnyk  That's not the RHS. 

Maple_numeric_speed_magic.mw

I would like to find a way to obtain a version of your expression in Maple 2016.1 which integrates numerically this fast. Likely it's size would be comparable. I have not yet found the magic simplification incantation which can easily be applied programmatically.

Maple_numeric_speed_special.mw

The timings are different, but not very different in a relative sense.

Could you state your target (relative) accuracy? Is it 1e-5, or finer, or would you be satisfied with even say, epsilon=1e-3 or 1e-4 (in which case probabilistic methods like CubaCuhre might be faster).

I'm not sure why you say that the evalf(Int(...)) syntax has changed in Maple 2016. I don't yet see any problem with that. Where there is some problem, however, is with the simplify(expr1,LaguerreL) and simplify(expr1,sqrt) in Maple 2016.1. I can try and figure out what's up with that, and how to better proceed. I notice that your were assigning results from both of those to expr1, so only one of them was being used anyway. Was that intentional, or a mistake?

@Traruh Synred From that error message you show it seems that you are using 2D Input mode. (If so then you should upload a document with the problematic 2D Input instead of trying to show it in your posting as plaintext...)

Anyway, get rid of that full colon that appears immediately after proc() . That errant colon ends the (empty) first statement in your procedure body, and that's not valid before the global declaration. That should solve your issue.

Nasser has updated his comparison page for performance of default (double-precision) float Matrix rank computation, now giving timings for 64bit Maple 2016.1(a?), Mathematica 11.0, and Matlab 2016a on Windows. The relative performance situation now appears to have reversed, with Maple 2016.1 and Matlab 2016a being significantly faster than Mathematica 11.0.

He also gives a link to this stackexchange item, in which he gives a table of the Intel MKL versions used by the three products. There are various references to updates to SVD performance in several Release Notes of MKL v11.x.x updates which may be found via web-search, but it's difficult to figure out which might be key here. (Likely it would be ones related to computing singular values only, and not the singular vectors.)

I would hazard the guess that Wolfram (WRI) can "fix" this by some suitable adjustment to which driver they call for this computation, and how, and that if all three products do it "right" then all three can continue to get the best, matching performance.

I notice also that there is a new MKL version, named 2017 (as opposed to 11.x.x). Those release notes, as well as older ones of v.11.x.x, quite often mention both algorithmic improvements as well as chipset-dependent improements (eg. for AVX2 enabled machines). The customer seems to be the true winner in this race.

@Bendesarts All three examples also work for me in my 64bit Windows 7 versions of Maple2016.1,  Build ID 1133417, whether I re-execute or not.

@Bendesarts Did you try re-executing the whole sheet? It works for me using Maple 2016.1a on 64bit Linux. (By the way I intended the latter two examples on the sheet as nicer for use in Maple 2016. See the comments.)

kernelopts(version);
   Maple 2016.1, X86 64 LINUX, Apr 22 2016, Build ID 1133417

@Carl Love Indeed I had imagined that handling the objective repeatedly (say, as some additional parameters changed while the objective continued to be formed in part by those main variables) would mean that by far the simplest solution would be to not assign to the main variables. I quite agree, making the assignments would be the awkward/wrong way to go, in that situation.

I'm hoping that a worksheet will be uploaded so that, in this likely scenario we could provide the full solution.

The Question indicates to me that the OP is not aware of any way to make use of the NLPSolve solution even once. So I've given such. If he needs to loop, and re-use those names in a running version of the objective, then indeed he should use the two-argument eval method and not use assign.

@tomleslie That thread is not related to this Question.

That whole thread was a bit weird, actually, as the only reason Admin privileges were needed was because the hdb file was unwisely placed in the lib subfolder of the actual Maple installation. Putting it into a toolbox folder (as I did in my attached answer here) is much better.

But in any case the two Questions are about two different things and the suggestions in the thread you cite will do nothing at all to aid here. It just muddied the waters by citing it at all.

@digerdiga If you call evalf(int(...)) instead of evalf(Int(...)) and the end-points are not floats (and if you didn't pass the option `numeric` to `int`) then it will first try to compute the integral symbolically, and that can be expensive. And if would do that for each invocation, thus even more expensive when looped. This is a common mistake in usage when someone is intending to do purely numeric integration.

The term you were originally looking for is re-entrant, rather than thread-safe, I suspect. And, yes, it is supposed to be.

@a_simsim You're most welcome. Please forgive me if I restate the following. The basic problem was that simply computing 

VEHQD( 1.0 );

outside of Explore was also not working. It's usually helpful to ensure that the explored thing works on its own outside of any Explore usage, with actual values supplied for the parameters.

@emendes Please note that on the first usage (which creates the toolbox folder and the .help file) the added help page will not be accessible upon help query. The GUI must be fully closed and relaunched from the desktop, and then try the help query.

Keep the location for the .help file specied by me (ie , the "toolbox" location). That's what makes it work automaticallt upon relaunch. Otherwise you have to put the .help file in the Maple installation's "lib" folder, or make a personal initialization file that augments libname.

(Perhaps someone else can confirm that "it works".)

What version of Maple are you using now?

acer

My 64bit Linux installations of Maple 2016.0 (Build ID 1113130), Maple 2016.1 (Build ID 1132667), and Maple 2016.1a (Build ID 1133417) each contain only libicuucmpl.so.56.1 (and its two associated symlinks).

Just to check I just reinstalled Maple 2016.0 to an entirely fresh new location, and then ran the 2016.1a upgrade installer obtaied from here. After the upgrade installation completes then running the commandline interface (CLI aka TTY interface) of that goes ok for me, and there kernelopts(version) reports Build ID 1133417. But for that installation I also see only libicuucmpl.so.56.1 and its two expected symlinksin its bin.X86_64_LINUX subdirectory.

So I don't quite see how your Maple 2016.1a installation could have libicuucmpl.so.49.1.1 get into it. I note that the 64bit Linux version of Maple 2015.2 had that particular binary object file. Is it possible that you somehow selected the wrong installation for upgrade?

I am running Ubuntu 14.04.4 LTS but I don't quite see how that would affect what the installer puts in place. ( I suppose that it's possible...)

If you are absolutely sure that you ran the 64bit Linux Maple 2016.1a upgrade installer against a Maple 2016.x installation location, and still see that wrong binary then I suggest you contact Technical Support.

acer