@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

Do you mean that you want to use a concatenation of existing symbols from the current palettes, as a new symbol that can be used for both 1D plaintext input as well as typeset 2D Input (including with its own new entry say in the favorites-palette)?

acer

This is a good question.

See also this old post by John May on the topic of subexpression labelling using the mechanism that Carl cites in his Answer.

The thread of vv's Answer is also worthwhile.

acer

@mmcdara That error message likely came from an attempt to assign to L[n] or some other entry of the list.

L:=[seq(0,i=1..100)]:
L[55]:=x: # succeeds

LL:=[seq(0,i=1..101)]:
LL[55]:=x;
Error, assigning to a long list, please use Arrays

The reason the kernel does this is because lists are not really mutable objects, and one cannot assign into a list and have it use the same memory space as before. Instead. assigning into a list entry creates a new list object. It's set up so that the name to which your list is assigned (say, L) is then reassigned with the new list, and this makes it appear as if lists were mutable. But the new list must get created and the old list must be garbage collected, which can affect performance. For large lists to which entries are assigned over and over again the perfomance hit can be extreme. It's a bit awful (IMO) that the kernel allows list entry assignment even for small lists of length 100 or less, because it just fosters inefficient programming.

Basically, assigning into lists entries can be terrible for performance. As Bad Practice goes, it's right up there with repeated list/set augmentation, eg, L:=[op(L),new] .

In contrast, tables and rtables (the latter includes Array, Matrix, Vector) are mutable containers, and entries can be replaced "in place" without the container itself being made anew.

@farahnaz You need to assign to filename the correct location of the file. Change it to wherever it is on your machine. It will be different than where it is on my machine. Something like,

filename := "C:/blah/blah/blah/16.3.xlsx";

Use forward quotes in that string.

Don't forget to respond to my comments about the weird "X" data values, and clarify your intentions.